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