Dart: Web Fragmentation vs. Web Development Fragmentation | Hacker News Reader

Dart: Web Fragmentation vs. Web Development Fragmentation

zef.me

17 pointsspankalee5 comments

I think the biggest difference between Dart and any other JavaScript Framework abstraction is the amount of resources and investment behind Dart. Google has it's best Language minds behind Dart's VM implementation, its JS transpilation, language semantics and APIs.

This is reflected in the rich tooling that already exists around it, include the smart IDE (Dart Editor) which can even infer intelli-sense from string literals inside queries e.g. el.queryAll("INPUT"), rich debugging from both the IDE and inside Dartium (when running native Dart) or inside Chrome with source maps and a rich and consistent library that smooths over DOM quirks.

But the best thing I like about Dart is the language, it's a C#/small-talk inspired language with C/JS-like syntax and Erlang-style Actors/concurrency-model. The combination of optional typing, type inferencing, implicit interfaces and convention-based visibility has been the biggest productivity boost for me. It lets me finally have a succinct dynamic language with enough structure that the IDE can provide warnings and intelli-sense while I type. Implicit interfaces means I no longer have to create future-proofing Interfaces and its '_' prefixing for library-only visibility makes it effortless to write APIs.

I know that Dart itself is a big framework & ecosystem that you have to buy into, so in a way it's similar to solutions we see in JS, but there's something to be said for making the more audacious and ambitious solution.

You need a critical mass of developers, and the solutions to each of the smaller fragmentation problems (inheritance, modules, async patterns and utilities, DOM consistency, core libraries, UI components) might need to rely on each other. I think Dart has a chance at a better overall solution because it tackles this all at once.

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

  > ...

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

I don't understand why it's ok to pick one 'world' but not the other (though I personally disliked ExtJS too).

You're right, or at least not incorrect :) If JavaScript started off with a module system, a decent core library, Promises, Classes, etc., a lot of this pain would have been avoided. But of course, part of it's beauty was that it was so simple. As these things become standardized in JS, hopefully the incompatible add-ons will fade away, but it'll take years.

Dart has an advantage of a clean slate, which is why it's "ok" in a sense - once you've decided to use Dart you also get decision/opinions on a lot more.

Exactly. It is not acceptable to buy into a large Javascript framework, but it is acceptable to buy into a whole different language? I fail to see the validity of this argument...

So what if one needs to use a Javascript library? Does one wait for the community to implement the wrapper around it? Does one implement the wrapper oneself?

Typescript on the other hand, seems to be more in line with the author's purposes, with one additional - and imo crucial - benefit: Javascript is valid Typescript (i.e. no need to change existing code, or wrap around libraries).

Reply on news.ycombinator.com