All that Boilerplate

Sorry, kind of a ramble today, as I’m still knee-deep in a little add-on project.

One of the biggest problems in programming a computer is boilerplate.  That’s the code you have to write to write the code you want or need to write.

Think of it this way.  If you want to build a dog house, but you don’t have access to modern hardware stores, then you first have to go and get the actual materials from nature.  Software tends to be that way, even when it’s being built with tools that should make things easier.

So, today I have been working on a little add-on for Firefox, expired by the news: Slashdot: Most People Have Never Heard of CTRL+F.

The concept was simple enough, to build a little add-on that builds an index of the words on a page, and lets the user search by clicking them.

I have a lot of experience building traditional add-ons, so I decided to use the Add-on SDK (Mozilla: Add-on SDK). It looks promising, but like anything it takes some getting used to.  Like anything, you spend most of your time figuring out which way is up, and the other minute to get the functionality in place.

It’s always painful, though. It should be so simple, if I can compute the result I want in less than a minute in Firebug’s console or the Web Console, etc., then why should it take several hours to learn what’s needed to do it via the SDK?

I think there’s a few reasons. Foremost, a console already has a well-defined interface. You put text in, and guess what you get back? More text. No mouse, no graphics. WYSIWYG, but for real for once.

Another big reason is that you supply the knowledge. If you know how the current console environment looks, the namespace and all, then you can make the console work. If not, maybe you can eke out what’s what via completion and some other poking, but it’s far more difficult. With the SDK, they supply the knowledge via a new environment that’s unfamiliar. It’s got to be different, because they’re planning for it to work with electrolysis (=e10s), which is the renovation that will make Firefox truly multi-process.

Contrasting this experience (which is yet to be completed; I’ll give a link here when it’s done) with another, that of toying with Rhythmbox 3.0 plugins recently, it’s no worse. New stuff doesn’t have the best documentation or a bounty of work to inspect in lieu of docs. Best practices are still being determined, and often no one has done something close enough to your idea to give you immediate traction.

That’s really what it’s all about. Boilerplate is like an oil slick on the road. You can’t get moving, because you’re sliding around trying to get a grip about what has to be done before you can actually get somewhere.

Back to the code, because I want to actually see if I can get this thing to work.