Blue Sky On Mars » JavaScript

Bespin and jQuery

Kevin Dangoor — Tue, 25 May 2010 16:21:37 +0000

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:

Bespin is a programming environment that you can include in your web applications that you create
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.

JSConf 2010 Day 1

Kevin Dangoor — Sat, 17 Apr 2010 13:30:25 +0000

I missed ScurvyConf entirely, much to my dismay. I got on the plane on time, but then they said they needed to swap out a computer. And then they swapped it out again. And then they gave up, hauled everyone off the plane, had us trudge across the airport and then loaded us up on another plane. I finally arrived at the hotel close to midnight, which is a drag given that I got up at 6:30am.

I started out on Track B. By the way, the notes below are mostly not going to be my opinions, but generally just what the speakers are saying. Sorry if this is a bit raw and unedited…

Chris Williams: How did I do JSConf?

Chris reported spending 200 hours to get JSConf going last year and 120 this year. He pointed out that conference tickets don’t sell out until they sell out… people need to feel like they’re going to be missing out on something and then they’ll sign up. JSConf 2009 was nearly canceled because of lack of interest and then they said “tickets have sold out” and instantly had a waiting list.

There was some additional discussion abiout how JavaScript needs a good website for the language. John Resig pointed out that MDC really has a lot of great information that is not Firefox-specific and is all available under a CC license. There was general agreement that MDC is a great resource, and Chris also mentioned it would be cool if there was a tool that cross-referenced between the JavaScript libraries (eg. $() in jQuery translates to dojo.query, etc…)

Chris is a fun speaker, and he gave us a great view of what goes into planning a conference.

Brian Mitchell: JavaScript’s Twin (Lua)

From a language perspective, Lua and JavaScript are so similar that there’s a temptation to just use JavaScript. But, there are times when Lua is a better choice.

LuaJIT, on some tests, is way faster than v8. It also has very good memory usage characteristics.

“Tables” in Lua are used for both array types and hash types. They’re very well optimized so that they perform like arrays when you use them like arrays. Warning: indexes start at 1.

Local variables need to be declared. Trailing semicolons are optional. Lua uses “end” rather than braces.

Lua has coroutines which makes asynchronous programming look a lot more synchronous.

Dion Almaer and Matt McNulty: web fragmentation on mobile

There’s a proliferation of internet-connected devices that all have SDKs, so it’s hard for developers to figure out how they’re going to support platforms. But, we’ve been there before. Back in the early 80s, you had to decide which computer you’d develop for, and that was it. Then came Windows, but there were still other platforms around… after that came the web, which enabled lots of new companies to grow up building software that could work on any number of devices.

Dion showed Quake II running in a browser using nothing other than HTML5 features. A lot of this is because of the huge speed increases in JavaScript.

There are a bunch of solutions for packaging up web applications for use on different devices. Titanium, Prism, Fluid, Palm’s webOS SDK, etc. all provide ways to provide native-like experiences using nothing other than web technology. jqTouch lets you use normal jQuery-style development for touch-based platforms.

When developing for mobile, these days you have a decision to make about your UI: do you want it to look native to the platform, or do you want to make an immersive experience that is tailored to your app. If you create a UI that is just there to serve your app, that could run nearly unchanged from platform to platform.

Palm’s mojo gives you a nice component model for HTML-based apps. Web apps have a low level model in some ways, compared to GUI components that you get in native platforms.

Matt McNulty announced that Ares is going 1.0 on Monday. Ares is Palm’s browser-based developer environment for webOS. 1.0 adds component APIs you can drag and drop, undo/redo, and a bunch of other features. Matt demoed Ares, and it’s really slick. Ares lets you preview the app in the browser (without the device services, obviously). It also lets you install to the device to see the actual app running.

Ares doesn’t work in IE, and no one really cares. Shockingly few people care about an offline version.

Matt also showed off mojo running in the browser. He had the native Palm mail app running in a normal browser window, which is cool indeed. Webkit browsers are no problem, but they’ve done some monkeypatching to make bits work on Firefox.

Francisco Tomalsky: Socratic documentation tool

We need to rethink how we do docs. Docs in source code are annoying because you have to scroll through them when using the code, you can’t localize them, you need specialized tools that may not yet exist for your language, it’s hard to include rich media (even when videos might make sense), and it increases the already large workload for committers.

Socratic uses the information in TextMate bundles to build up a DOM of your source. Once you do that, you have a query language that’s not unlike jQuery for querying that DOM and pulling out all of the matches.

The other piece is a wiki based on git (rather than docs in your comments). The wiki git repo tracks the branches of your code, so someone can get the docs for a specific version of your project. Socratic also has support for GitHub issues.

The project is not done (actually looks like it’s just getting started, based on the quick demo he gave) and Francisco is inviting people to help. He thinks that a great doc tool in CommonJS JavaScript will get a bunch of people using CommonJS servers.

Francisco then followed up with a demo of the latest Cappuccino release. He mentioned that it is now completely CommonJS-based. You no longer need Ruby at all to work with Cappuccino’s tooling. Also new is a CPTableView that was contributed by an outside contributor. He demoed using IB to create a table view and used nib2cib to convert for Cappuccino’s use.

CommonJS: the First Year

Kevin Dangoor — Fri, 29 Jan 2010 14:53:34 +0000

A year ago today, I posted “What Server Side JavaScript Needs”, inviting people to come and turn JavaScript into a competitive platform for applications on the server. Quite a few people answered the call. While the focus of the group has been on JavaScript in non-browser contexts, we’re ultimately shooting for as much of a standard that can cross between server, browser, GUI and command line applications as possible. That’s why we changed the name to CommonJS in the second half of the year. Ironically, most of my own personal use of CommonJS so far has been in the browser. I’ll come back to the personal perspective, though.

The Original Goals

As laid out in my original blog post, we were seeking to create:

A module system,
A cross-interpreter standard library,
A few standard interfaces,
A package system, and
A package repository

Note that the idea here is that this group creates specs, which will have multiple implementations.

The goal is to have these things working across as many operating systems and interpreters as possible. There are three major operating systems (Windows, Mac, Linux) and four major interpreters (SpiderMonkey, Rhino, v8, JavaScriptCore). Plus there’s “the browser”, which is a unique environment unto itself. That’s a fair bit of surface area to cover.

Oddly, I think the one of those eight “platforms” with the poorest implementation support is Windows. Most of the CommonJS developers are using Macs or Linux machines, so I’m not sure how much time has really been spent on Windows. I would imagine that JavaScriptCore on Windows is probably the least supported combination.

The good news, however, is that there are projects using all of those JavaScript interpreters and platform compatibility issues will ultimately be ironed out.

CommonJS and the ECMAScript Standard

The CommonJS group is a grassroots effort, and not some formal standards body. In some ways, however, it works like a standards body in that the people working on the standard are also implementing the standard-in-progress and using it to build real applications.

We have no control over the ECMAScript language, which is managed by the TC39 working group. However, there are a few people involved in CommonJS who are part of TC39, and I have firsthand knowledge of others who are keeping an eye on how things are going with CommonJS.

The CommonJS standard-in-progress is designed to work on a subset of ECMAScript 5 that can be made to work on today’s ECMAScript 3 interpreters. ECMAScript 3 is the standard that is running in all of the browsers. In other words, in a CommonJS application you can count on Array.prototype.forEach to be implemented. Obviously, applications can do whatever they want (array destructuring? knock yourself out, but your app will only work on SpiderMonkey and Rhino).

One certainty about CommonJS is that inventing new language syntax is out of scope.

The Module System

The CommonJS group has been remarkably good at avoiding bikeshedding. While there is discussion about names of things, there isn’t heated discussion about it. People are far more interested in issues of functionality and ease-of-use. This is a very good thing, and it allowed us to get modules out of the way early on.

Of course, the lack of bikeshedding doesn’t mean that everyone agrees on things. The CommonJS module system has its controversial aspects, but I think it does well given the constraints:

must work with ES3 syntax (destructuring could actually be useful, but we’re not going to do it)
modules should have self-contained namespaces and be explicit about data the want to export
it should be possible to make modules tamper-proof, though this is not a requirement
using a module should be competitive with using modules in languages like Python and Ruby

TC39 had considered adding modules to ECMAScript 4 and there are module proposals on the table for ECMAScript Harmony that would add some syntax to JavaScript that would look similar to CommonJS modules. Here’s a short module to give you an idea of what CommonJS modules look like:

var sillymath = require("extramath/silly");

exports.addTwo = function(num) {
    return sillymath.add(num, 2);
};

Personally, I find this to be reasonably concise with a nice level of explicitness. Some syntax sugar would be good, and I hope we get that in ES-Harmony. But, this syntax works fine today.

Of course, this syntax is not without controversy. The biggest controversy has been that require() is synchronous – the “extramath/silly” module has to be available as the module above is loaded. However, there are a couple of reasonable ways to deal with this problem and I am happily working with CommonJS modules in the browser which is the environment that is least tolerant to synchronous loading.

Controversy or not, this basic module system was ratified last winter and has been implemented on all target environments of CommonJS.

Discussion is ongoing for a tie-in to the module standard: the module transport standard. Without additional help from the browser or some additional scaffolding running in the page, the module syntax above doesn’t work via a