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 thatVM 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 helpssolve.

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.

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 <script> include me in your page” model.

Your control implementation will likely need to do DOM manipulation. How you do that in a portable way? The solution in many cases has been jQuery, but do you really want to add a 40k dependency to your control, just to make DOM manipulation easier?

When I heard about TJ Holowaychuk’s Component I thought: “Yay! Finally a solution that tackles this problem!” Until I realized that it too basically asks you to buy into an ecosystem of tools: its own module system, its own package manager and build tool. Jam is another approach that also standardizes on a module system (require.js), and supplies a package manager and build to simplifies things.

Either way, you’re still buying into a particular ecosystem, and for our use case I really don’t want to do that.

It appears there’s no right way to do this. If there is, and I’m missing it, please let me know.

Why does this problem exist at all? I believe the reason is there are a few core things missing from Javascript on the web right now. Interestingly, Javascript is low-level and flexible enough to implement these missing parts by hand. The problem is: there’s a million ways of implementing them. As a result, there are a million Javascript frameworks, and front-end web development has become crazily fragmented. You’re either a jQuery guy, an ExtJS guy, a MooTools guy or a plain-old-vanilla-I-will-write-everything-from-scratch guy.

If I develop a component, I don’t want to be any of these guys.

I think that, today, a serious platform has to have a single, consistent solution for a few basic things:

  1. Code modularization and module loading.
  2. OO programming (a good prototype story, or classes).
  3. APIs required to do your day to day work (e.g. not having to reinvent DOM quirk handling every time).
  4. Not vital, but a way to handle dependencies (package manager) would be great.

Guess what — not purely coincidentally — the web implementation of Javascript doesn’t offer any of these things natively. You could argue that it does have a clear OO story (prototypes!), but in practice that’s largely ignored. It’s not like there aren’t any solutions up for grabs, the problem is there are too many. Standardization is required. I don’t even care which choices are made for any of these. Just decide. Anything.

Freedom to implement all these things in whatever way you like is conceptually appealing, but if you want to build cross-framework components, today’s web is a frickin’ nightmare.

Which brings me back to Dart.

You will be shocked to hear Dart scores much higher on my platform test than Javascript, it almost looks like they knew about Javascript’s problems.


  1. Has built-in support for modules.
  2. Has single-inheritance classes for OO.
  3. Has a fairly extensive library of things you commonly need, so there’s no need to reinvent the wheel every time.
  4. Has a declarative way of specifying project dependencies and a package manager to manage them.

In addition, the Dart people are pushing an early implementation of the W3C Web Components standards, dubbed Dart Web Components, providing you with a way to create modular components with some cool features like reactive UI programming.

All of these things make me extremely happy as a guy who just wants to build a web component without buying in to a big-ass framework or a dozen third-party dependencies.

When you enter the Dart world, a lot of choices are made for you. And I have come to believe that’s a good thing. It’s good for a platform to say: welcome to our world, here’s what we provide you with, these are the best practices, these are our coding standards, this is what you have to do to be a good platform citizen — now live happily and prosper.

Client-side Javascript development today is way too fragmented and it will take years to fix, if it happens at all. While Dart is often accused of fragmenting the web (probably rightly so), it does seem to provide what’s required to prevent web development fragmentation within the Dart space.

But all of this only really helps if Dart takes off…

Update: I posted a follow-up.