Bespin and jQuery

May 25, 2010 16:21 · 1323 words · 7 minute read

Yesterday, we announced that the Bespin server is going to be rebuilt from the ground up in node.js with a decentralized model in mind. I’ve seen a lot of positive reaction to that, which is great because I think it’s an important step forward for Bespin. We also mentioned on bespin-core that we have changed from SproutCore, which we adopted during the “reboot” of the Bespin client side code, to jQuery. A handful of people have suggested that we should just build our own “framework”. Our decision to use jQuery came after much deliberation, so I thought I’d go into a little detail about that since this question has now come up many times.

What is Bespin?

It’s hard to say if something is a good choice for Bespin without actually being clear about what Bespin is. Bespin is a customizable programming environment for web applications. There are at least two correct ways to interpret that sentence:
  1. Bespin is a programming environment that you can include in your web applications that you create
  2. Bespin is a programming environment for creating web applications
Early in Bespin’s life, people were embedding the editor in their own applications, but this wasn’t well supported. We made a decision to make that a well-supported use of our project and that change has major ramifications for the project.

Frameworks vs. Libraries

The best description of the difference between a framework and a library that I’ve seen is:
  • A library  is something you call from your code
  • A framework is something that calls your code
Note that this definition says nothing about the size (libraries could certainly be bigger than frameworks, and vice versa). This definition also makes no judgments about which is better or whether the code is loosely coupled or tightly coupled.
Frameworks can make building an application really fast. They do a great job of reducing the amount of code you need to write, as long as your application fits the framework’s design and intended applications well. The farther you stray from the path, the more resistance you’ll get as you try to add new things.
SproutCore is a framework. It attaches event handlers to the page and delegates those events to views that you create. Further, it has a powerful declarative binding/observation system that it updates automatically as part of a runloop that it maintains. It’s really quite a powerful GUI toolkit that runs entirely in your browser.
For Bespin “the application” (the software that runs at bespin.mozillalabs.com), SproutCore seemed like it would be a good fit because what we were doing was more like a desktop app than a website. On the other hand, for Bespin “the customizable, embeddable editor”, the tools we want and need are not such a great fit for a framework. Bespin needs to fit in well with what people are already doing on their pages.

Why use a library at all?

OK, so Bespin and frameworks are not a good match. But there are plenty of libraries out there (jQuery, YUI, Prototype, Mootools, Dojo, Closure, and even MochiKit about which I’ve written extensively in the past) Why not just build our own set of utilities, especially since Bespin exclusively targets modern browsers?
We wrestled a bit with that very question. Even with modern browsers, some conveniences are still handy. Here’s a simple case I can point to: addClass. A function that will add a CSS class to a DOM node. We all need to do that at times, but it’s not yet a method offered by the DOM, nor is it in any proposed standard that I’ve seen.
I believe that every JavaScript library offers addClass. Their APIs vary, but it’s in there somewhere. We could create our own library with our own version of addClass. But that has disadvantages:
  • we have to write it/test it ourselves or copy it from somewhere
  • we have to maintain it
  • for people extending Bespin, there’s that much more surface area that they need to learn
  • we need to write docs for it
  • we can’t use fancier things people create (overlays, trees, etc.) without porting them
  • if people already have a library on their page, our utilities will add additional size
There are probably other disadvantages as well. The only advantages I see to rolling our own are:
  • we get exactly the functionality we need and no more
  • we maintain our own release schedule for it
We are considering a “best of both worlds” approach as well, if we feel like slimming down Bespin Embedded “Drop In” (the prepackaged single .js file) even further: we take just the functionality we’re interested in from a library (jQuery) and create our own mini library that uses the exact same API. Our modules/build tooling can make it transparent to switch between the mini library, the full library and one that is already on the page.

Why jQuery?

As I mentioned earlier, when it comes to utilities the libraries all offer a very similar collection of functions. We don’t want to use a library that “leaks” onto the page, either through the creation of globals or the extension of built-in prototypes. That still leaves a number of choices. We evaluated some, but ultimately decided on jQuery because:
  • It’s very popular, which increases the chance that it’s already on the page (and decreases the size of Bespin)
  • many people are already familiar with it
  • there’s lots of good documentation available
  • there are many decent open source plugins that people can use when extending Bespin
It’s worth noting that these are not technical reasons to use jQuery, and these largely only matter because jQuery is popular and Bespin is intended to be used on other peoples’ pages. The choice of jQuery for Bespin is not a technical choice. We certainly like jQuery, but we like the other libraries as well.

Not just jQuery

One more important point: Bespin Embedded is still designed to be easily built into a self-contained .js file. The current code in our repository puts only one name on the page (bespin) and everything else is hidden away conveniently inside of there. The next release of Bespin Embedded will be less than half the size of the previous release, even with jQuery bundled in. So, Bespin will be a good addition to your application, regardless of which JavaScript library you might use for the rest of your code.

Summary

Bespin has had unusual and competing requirements along the way and as we’ve zeroed in on exactly what Bespin is and will become, we’ve changed our infrastructure to match the needs of the project. We’re really excited about how far we’ve come since “rebooting” the project and are looking forward to these next few releases that lead up to a “1.0” of the Bespin project.

Additional Commentary

John-David Dalton commented via a gist.

He points out that unless we are using a compatible jQuery, people who already have jQuery on the page will not have any size advantage. Of course, if we have our own library no one will gain a size advantage.

With respect to Bespin users being able to use whatever library they wish without porting additional widgets, we (the Bespin team) want to be able to use things like trees and such without having to port them to our own library. Bespin users do remain free to use whatever they wish without porting anything.

Finally, regarding “fourth time’s a charm”, I’ll just note that the 0.8 version number of the next release of Bespin is actually significant. The client APIs are settling.

Thanks for the comment, jdalton!

ClassList API in HTML5

I was happy to hear from Thomas Bassetto that addClass has indeed been rendered redundant by HTML5’s ClassList API which looks great. element.classList is available today in Firefox 3.6 and, according to the Mozilla Hacks article, WebKit is planning to also support the API. The current version of Chrome does not have it yet.