I've now tried my hand at writing plug-ins for Safari, Chrome and Firefox (using JetPack). I haven't tried this sort of thing before, but I really like where this kind of thing is going. The chorus of focus placed on HTML, CSS and JavaScript really make developing plug-ins for these web browser very simple.
My Plug-in
First off, a caveat. I'm not doing anything complex. All I wanted to do was automatically inject a bit of JavaScript on certain pages. It's a very short script that only took about 2 hours to write, test, and debug. A lot of the frameworks for developing plug-ins provide a wonderfully broad set of features to support a wide array of plug ins. Plug-ins that try and add UI-features, leverage browser-specific abilities, or do anything that can't be generalized to all web browsers would probably be a bit more difficult.
Safari
This was my first attempt. It's my current default browser (I rotate what my default browser is every few months) so it was the first one I wanted my plug in to work with.
The documentation was an amazing help. It pretty clearly explained how to get what I wanted done, done. Safari's extension builder provided a clean UI to configure and install my web app, even if it didn't do a great job explaining what all the options were (the documentation filled that gap).
While I would say Safari was the most user-friendly browser to develop for, there were a few highly technical glitches that might deter beginners. First, I had to deal with signing up for the Safari Developer Program, getting an Apple-signed cert that lets me install custom plug-ins, then installing that cert on my dev machine. I can see how this makes it "secure", but it was busy work I had to do before I could really get to work. It was annoying.
Additionally, when I was finished, hosting and auto-updating my plug-in was another highly technical pain point. Apple doesn't provide hosting for Safari plug-ins, so you've got to find your own way to distribute them. Additionally, you can specify a URL for Safari to check for updates, but oddly enough that URL doesn't go to the latest version of your plug-in. It goes to a very specific XML file that lists version numbers and locations for a bunch of plug ins. Again, it works, but making me manually edit and host an XML file isn't quite as streamlined as editing config options with the built in Extension Builder. It's just not very Apple-y.
Chrome
A lot of the concepts used by Chrome extensions are the same. Just specify HTML, CSS, JavaScript, and you're good to go. A good number of the configuration options are the same as well.
Unfortunately, Chrome lacks the slick tools that Safari has. Rather than a nice UI for editing config, I had to manually edit a manifest file. To their credit, the manifest was just pure JSON, so it wasn't that bad to use, and immensely better than that XML pList stuff I had to do for Safari's auto-update feature.
I also didn't have to do any nasty cert management. I just told Chrome to use the folder with my plugin and it worked.
Everything else was pretty much a breeze. Chrome provides hosting for your plug in, and you can auto-update from there. The biggest drawback was that hosting anything in the Chrome Web Store costs $5, but that's a one-time fee. And, unlike Apple's registration process, I didn't have to do that if I just wanted to toy with an extension on my computer.
However, there was a sharp moment of confusion when I uploaded my extension to the Chrome Web Store. The form explicitly asked for a zip file of my extension. When you package up a chrome extension, it zips it up and adds a .crx file extension to the end of it. But that's not good enough for the Chrome Web Store: you need to unpack it, then zip it up, then submit it. Why they made me take these extra useless steps boggles my mind.
Firefox
Last (and least) there's Firefox. I generally like Firefox as a browser, but trying to develop a plug-in for Firefox made me appreciate how much work has gone into all the other Firefox plug-ins that I use today.
At first I wanted to make a plug-in for Firefox 3.6. I started reading docs. There were XUL and NPAPI and ugh, who knows what other custom languages and technologies for me to learn. This was not going to be fun.
Then I found Jetpack. I thought it was a feature coming with Firefox 4 to make developing plug ins as easy as it was in Chrome and Safari. Turns out, it's a utility to generate all that XUL and Firefox-specific goblety-gook out of the standard HTML, CSS & JavaScript.
Well, actually, just HTML & Javascript. There's no CSS support. I had to translate my CSS to text and write some custom JavaScript code to inject it. And it turns out the JavaScript support is quite limited. You really don't have the same power that you have with developing plug-ins for other browsers.
But it's a beta. It's severely behind its competitors, but it's showing signs that it's on the right track. And once I figured out the pile of default folders and files needed to properly create a Firefox plugin, I was well on my way to being done. All the gripes I had about it had already been entered into some feature-tracking product on their site, and it's really just a matter of time until that gets it sorted out.
Conclusion
I didn't touch IE or Opera. Mainly because (a) I think it can't possibly be easy to develop for and (b) I don't use it enough on a regular basis, respectively.
But overall, plug in/extension development is on the right track. It's pretty easy to get simple cross-browser features running in different browsers. Large chunks of code were re-used for the majority of these plug-ins. And a lot of the pain was just the first-time setup cost of doing plugin development.
I'd definitely do this again, if I thought of something else I wanted to change the browser to do. :)
No comments:
Post a Comment