As far as I remember, Dart’s reception wasn’t particularly positive. The criticisms fell into roughly two categories:
- The language is boring, uninspired and too Java-like.
- 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 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.
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.
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:
- Code modularization and module loading.
- OO programming (a good prototype story, or classes).
- APIs required to do your day to day work (e.g. not having to reinvent DOM quirk handling every time).
- Not vital, but a way to handle dependencies (package manager) would be great.
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.
- Has built-in support for modules.
- Has single-inheritance classes for OO.
- Has a fairly extensive library of things you commonly need, so there’s no need to reinvent the wheel every time.
- 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.
But all of this only really helps if Dart takes off…
Update: I posted a follow-up.