Dart: Web Fragmentation vs. Web Development Fragmentation

Remember Dart — that language that Google is developing to replace Javascript? Frankly, I haven’t given it much thought the past year. When I heard it being pitched as a “web scripting language that we can make run really fast” about a year ago by Lars Bak, I kind of dismissed it. I don’t find the ability to execute programs in a language very quickly a particularly important property of a programming language, nor do I believe that VM implementers make for very good language designers. Of course, there was more to Dart than the ability to execute fast, but I didn’t care much about that at the time.

As far as I remember, Dart’s reception wasn’t particularly positive. The criticisms fell into roughly two categories:

  1. The language is boring, uninspired and too Java-like.
  2. No browser but Chrome will ever support it, so it’s bound to fail.
  3. Google is fragmenting the web by offering an alternative to Javascript, it’s VBScript all over again.

I don’t think (1) is such a bad thing, but that’s a discussion for another day. I think (2) is a legitimate concern, unless you find the compiles-to-Javascript option acceptable long-term. But what I really like to talk about is (3).

Fragmentation is in fact the reason why I revisited Dart a few days ago, but it’s not the kind of web fragmentation that the critics of Dart are referring to. Ironically, it’s a kind of fragmentation that Dart helps solve.

Let me give some context.

At LogicBlox we do stuff with data — we’re a database company. Data has to be presented to the user, and if you don’t want look ridiculous with your Java Swing UI, the obvious solution is building web apps.

A common way representing data is a data grid:

(↑ Interesting-looking data grid screenshot I pulled from Google Images.)

In various applications built for our customers we’ve used off-the-shelf grid components, for instance the grid from ExtJS. The problem with these components that they usually come with a whole family-in-law: if you decide to go with ExtJS’ grid, you basically have to buy into ExtJS as a whole. You’re not going to build your web application with, say, Ember and then pull in another huge chunk of the ExtJS library, just to render a grid.

This is a serious problem for us. A data grid is core to what we do. We would like to have a grid component that’s rock solid, scalable and we can plug into any web app we like, whatever happens to be the hot new framework of the day. We’re not ready to “bless” one web framework that all our applications should be built with. Basically, we’d like to build zero-dependency web components.

I expect that at some point we will implement our own grid component, the question is: how?

ExtJS’s grid gets a lot of its implementation from the ExtJS framework. There’s a fairly solid foundation in ExtJS that implements various kinds of data sources, does lay-outing of components etc. That’s convenient, you wouldn’t want to reimplement that in every component you build.

I tackled a similar problem a few years back when I developed persistence.js(an ORM mapper for Javascript). While I personally only planned to use it in conjunction with jQuery at the time, I appreciated that other people make other life decisions, and I didn’t want to exclude them because of that — I’m not a framework-cist. I had to jump quite some hoops to build this library in a zero-dependency way. As a result, the library contains quite some code that most frameworks will also offer — like its own simple inheritance mechanism and asynchronous sequential and parallel versions of for-each, as well as the ability to work both on the client and server using node.js. It was a pretty bad development experience to get it done, and it didn’t even have to use the DOM.

Modularization is another obvious problem. Persistence.js over time got too big to reasonably fit a single JavaScript file, and had some optional components, such as its syncing support. So, it needed modularization. Javascript has no built-in module system (yet). There’s dozens of module systems out there, such as require.js, but to be optimally portable, you don’t really want to buy into any particular one. Do you let people include multiple JavaScript files in their HTML header? Do have the user do a build with their particular preferences? If so, what tool chain do you use to do this building? If you choose to go this route, it is still not a good fit for projects that use a system like require.js, because it has its own scoping mechanism that don’t natively fit with this “just `

• Programming