The Jetpack Debate

I’ve generally found Jetpack to be pretty cool. It’s easier to develop and I’m fairly familiar with both “traditional” extension development and jQuery so it seems natural to me. However I generally agree with Daniel Glazman’s blog post on Jetpack. I’ll even agree that closures can make code more difficult to read, though I think I’ve mostly adapted to it at this point.

Jetpack reminds me more of building JS “widgets” than extensions. I’m not sure I see the advantage of moving away from XUL which really isn’t “hard” for 98% of things (though XUL <wizard/> has admittedly made me say WTF a few times) to HTML unless some sort of portability were gained, but that doesn’t seem very likely at least right now. I haven’t seen any indication of intent either. XUL has the advantage of making good UI seemingly easy while HTML really doesn’t, though I’ll admit HTML5 is changing that.

The biggest problem I see with Jetpack is that too much of it is designed around existing needs. The problem with this process is that it’s always playing catch-up. The best extensions are disruptive and do things nobody ever thought of, or even thought possible. Looking at the Jetpack JEP list I see pagemods and toolbar. The kicker is these are “implementing” and “planning” respectively right now.

Things like jetpack.slideBar, and especially jetpack.lib.twitter make me feel a bit concerned. Why? Because they encourage too much conformity, and too many twitter client Jetpacks.

When developers are given such a sterile environment that’s intended to promote experience and stability it ends up inadvertently creating monotony and stalling innovation. If you want proof look at the iPhone. There are indeed some great apps and I say that as an iPhone user myself, but for each great application there are 1,000 that aren’t worth the price (which is often free). Many are just cookie cutter apps with a companies logo on them. Google used one undocumented API for a feature Apple didn’t think of providing a documented API for, and it was news worthy. While Jetpack distribution isn’t limited in the same way that iPhone apps are with the App Store the design questions still remain.

To quote Adblock Plus author Wladimir Palant:

…Jetpack has to support Adblock Plus, not the other way around. As it is now, Jetpack isn’t suitable for complicated extensions.

That’s the wrong order.

Geek Reading: High Performance Web Sites

So I decided to do a little book shopping a few weeks ago and one thing I purchased was High Performance Web Sites: Essential Knowledge for Front-End Engineers (affiliate link). At its core is essentially a 14 step guide to making faster websites. I don’t think any of the steps are new or innovative, so anyone looking for something groundbreaking will be sorely disappointed. I don’t think the target audience has that expectation though. It’s still a rather practical book for any developer who spends a lot of time on the front-end of things.

It gives many great examples on how to implement, as well as suggestions based on what some of the biggest sites on the web are doing (including Yahoo, the authors employer). I found it pretty helpful because it saves hours worth of research on what other sites are doing to improve their performance. For that reason alone it’s a worthwhile book to checkout. For each rule there’s enough discussion to help you decide if you can implement an improvement on your own site or not. Most sites are limited by their legacy systems such as cms, processes (including human) and audience in what they can actually do. Unless you’ve got a serious budget, you likely fail rule #2 (use a CDN) right off the bat. Regardless there’s likely a few tips you can take advantage of. It’s also a very fast book to get through.

Most steps are pretty quick to implement provided they are feasible in your situation. Overall one of the best “make it better” tech books I’ve seen regarding web development. One of the few that actually appeared worth purchasing (and I did). The majority of the tips require a somewhat tech savvy approach to web development, the book isn’t oriented much towards web designers (with the notable exception of reducing the # of requests by using CSS and better use of images) or casual webmasters. It’s important for those who understand the importance of HTTP headers, but could use some help deciding on best practices, and those who want to know how the small things can add up.

Interestingly enough, I learned about the book by trying the YSlow extension which essentially evaluates a page against the rules suggested in the book. Interesting from a marketing perspective I guess. Overall this blog evaluates ok (about as well as it ever will considering I’m not putting it on a CDN anytime soon). Though I guess I could add some expires headers in a few places.

Email Image Protection

Many people think that making an image out of an email is a good way to protect it from being harvested by spam bots. It’s now possible to convert it from an image to email link via a Firefox extension. Guess what, an email harvester can do this just as well. What’s a better solution against email harvesters? Don’t put any trace of an email address online, use a form. Yes you could distort the image a bit to make it more difficult, but using a CAPTCHA as an email isn’t going to make you any friends. JavaScript can also be done, but no reason why it can’t be interpreted (though that may be more difficult in some cases, since a JS engine isn’t the easiest thing to work with, and implementing anything less can easily be defeated by throwing some extra JS in there. Some discussion on the Firefox Extension implementation can also be found on Gerv’s blog where he proposed the idea.