Dart: Web Fragmentation vs. Web Development Fragmentation
By Zef Hemel
- 4 minutes read - 792 wordsRemember 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 `