34 ms·

Why Google thinks you should drop everything you do and pick up Dart

47 points by WoodenChair 12y ago

scotty79 12y ago
What's the killer feature of dart? I went through some docs and couldn't see anything JavaScript doesn't already have or is soon to have.
- CmonDev 12y ago
  Proper OOP and type checking. Fighting to finally make the web open. Open to new languages, technologies and innovation. All we have now is legacy stuff like JS and HTML. I hope NaCl will also start dominating at some point. Freedom of choice of tools is important.
  - pjmlp 12y ago
    Apps will free us.
- pjmlp 12y ago
  If Google had done this right with the other vendors, it would have been the second coming of Smalltalk in a way. As the developer experience is somehow similar. As it is, it is just another language that transpiles to JavaScript.
- chewxy 12y ago
  Optional typing is pretty interesting, IMO. I'm not sure if that is a killer feature for programmers who are used to JS dev tho
- yulaow 12y ago
  It will be supported only on chrome while any other browser will ignore it. It remember me of Jscript or Vbscript, what a vibrant future /s
  - marcell 12y ago
    Looking at the slides, I don't think this is accurate. You can compile Dart into Javascript, which will run on non-Chrome browsers. The advantage is that (1) on Chrome, you get better performance, and (2) you get a nicer language that Javascript.
    - yulaow 12y ago
      And now I have to support (and debug) two languages only because on a single browser one can perform slightly better, while the rest of the resources and frameworks for web clients are all written in javascript. No thanks
      - WoodenChair 12y ago
        Why would you be supporting two languages? You can choose to write your app in JavaScript (that's not going away and that's one language) or you can choose to write your app in Dart (also just one language) which will run as Dart on the Dart VM and compiled-you-don't-touch-it JavaScript everywhere else. Sounds like FUD to me.
        yulaow 12y ago
        Because if I choose dart I have still to deal with the derived javascript code implementation I must use to run in other browser that are not chrome and, as described by the post close to this, often that js is so broken it cause big bugs on firefox for example, and to understand and repair those you have to know js.
        WoodenChair 12y ago
        I would take what kevingadd says with a grain of salt. He's the author of a .NET -> JS compiler (arguably a competitor to Dart) and the experience he cites below is pretty different from what I've had and my colleagues have had. I don't mean that as character assassination - he's obviously a very talented developer - but rather as a point of contrast. Frankly, you would not want to be touching the compiled JavaScript from Dart - it's not meant to be changed. I agree that if it's that broken, then you should certainly not use the platform. So you should just be writing in JavaScript or just be writing in Dart.
- WoodenChair 12y ago
  There's not just one killer feature. Here's a few strong features that add up: - optional static type annotations - advanced object-oriented features (mixins, advanced constructors, etc) - rich built-in libraries - pub package manager - 2X V8 performance w/ the Dart VM - integrated tooling - exceptions - generics - operator overloading... I could go on, but basically I'm not sure what language you were looking at because Dart has a lot that plain vanilla JavaScript does not (although can have with extensions). It also doesn't inherit all of those flaws JavaScript got from being designed in a time crunch (10 days is really not enough time to design a language). If I had to pick one though, it would probably be the fact that Dart is a platform (rich language, libraries, tools, and package manager) rather than hodge podge of frameworks on top of a lightweight language.
  - ajizzle 12y ago
    If it compiles down to javascript then it does have the same flaws as javascript. 2x performance of v8 is bullshit, and "rich built-in libraries" and "integrated tooling" are just marketing drabble. If you understand what they actually mean please explain or gtfo.
    - WoodenChair 12y ago
      Sure, I'll explain each one. Performance - Dart has its own VM which runs independently (on the server, or in special builds of Chrome, but soon to be mainline Chrome). So it's not just a language that trans-compiles to JavaScript, it's also a language with its own independent high performance VM that you can use on the server today and the browser tomorrow (hopefully). By the way the Dart VM was written by the same guys that created V8 - generally considered to be one of the highest performance JavaScript VMs - so I think we can believe them when they say it's higher performing. Rich Built-in Libraries - Just take a look here: https://api.dartlang.org/ https://api.dartlang.org/ There's everything from a reflections API to a WebGL library. There's JavaScript interop libraries, concurrency libraries, and the equivalent of jQuery built-in. That's just scratching the surface. Integrated Tooling - Dart has its own package manager (pub) which is quite nice as well as its own IDE (Dart Editor) which comes with a debugger, profiler, and all the niceties you'd expect (code completion, deployment help, etc). It's also a new language (less than a year since 1.0) backed by a big company so these things are only going to continue to improve.
- skrebbel 12y ago
  It's tool support and unsurprising semantics. Few other web frontend languages have that. TypeScript comes close with the tool support, but it doesn't have the unsurprising semantics, and all in all it's a lot more limited, because it's designed to be a near-superset of JavaScript. I'd be using Dart already if it was simpler to integrate with existing JS libraries. That's the part TypeScript got way better. Tool support must be one of the most underrated language features these days. The enormity of blog posts about desiging your ruby code for "greppability" is just scary - I just want my tool to generate a call hierarchy for me, thank you. Dart has this covered.
- mpweiher 12y ago
  Semantically, Dart is pretty much Smalltalk, so it's actually a useful, reasonably well-thought-out language with sane semantics. A bit of a shame about the syntax... It even has doesNotUnderstand:, so it's quite extensible. The optional typing is neat: you can have a type error and the program won't just compile, it will continue to run! There's a video of Gilad demonstrating this in a live coding environment: he changes the type of a variable that's a number to String and apart from the compiler now complaining, nothing changes. The isolates concept also seems well-thought out, with separate heaps and the only interaction via messaging. Nothing breathtakingly new, but I think they picked up the right thing and implemented it well. The fact that the semantics are sane means the compiler can create faster code than JS with fewer heroics (if it isn't compiled via JS).
tomjen3 12y ago
Anybody have a link to the slides? I don't really want to waste time watching a video to see what they are up to.
- WoodenChair 12y ago
  https://docs.google.com/presentation/d/1EWLLgsl-m4OCRcvgf2BixnLCLNTAGLfxWhYI0M5j19c/edit#slide=id.g177d510c8_0342 https://docs.google.com/presentation/d/1EWLLgsl-m4OCRcvgf2Bi...
ajizzle 12y ago
Another self-righteous blue haired web developer complaining that he doesn't get enough geek respect in the current state of the web.
deleted 12y ago
[deleted]
Soyuz 12y ago
Anybody used Dart for serious web development?
- WoodenChair 12y ago
  Here are people who do: https://www.dartlang.org/community/who-uses-dart.html https://www.dartlang.org/community/who-uses-dart.html
- stesch 12y ago
  I evaluated it. Didn't work in Firefox 31 Beta. Reported the bug. Was fixed in Dart around the time when Firefox 32 RC got released. Please remember to recompile all your apps you deployed with Dart < 1.6. There are still some Firefox users out there. (Majority in Germany uses Firefox.)
- frik 12y ago
  Notch (creator of Minecraft) uses it for some smaller WebGL games: http://blog.tojicode.com/2013/12/notch-webgl-dart-and-ramping-up-quickly.html http://blog.tojicode.com/2013/12/notch-webgl-dart-and-rampin... and on HN https://news.ycombinator.com/item?id=6841557 https://news.ycombinator.com/item?id=6841557
- woven 12y ago
  Way before 1.0 existed (and using an early version of Polymer called WebUI) we built a first version of our app, e.g. http://woven.co/miamitech http://woven.co/miamitech, which is a fairly complex client and server side application. (The slowness is due to our poor pgsql data design.) I'm now building a more focused version with the latest SDK and Polymer, the beginnings of which are at http://mycommunity.org http://mycommunity.org. For me it's simple: Google is arguably the greatest champion of the open web and probably does more to advance modern web development than most anyone else. V8 was a game changer, and enabled Node. The same folks behind V8 are building, in essence, a better Node. Modern web development with JavaScript is exciting, and there are so many great libraries and resources out there, but there is also much to be desired such as more structure, a saner language and a strong suite of core libraries that play well together. In my experience, Dart is what they say it is: a more structured approach to modern web app development.
ntoshev 12y ago
"Google" does not think that, a cofounder of the Dart project does.
- WoodenChair 12y ago
  It's the official name of the talk.
  - thomasahle 12y ago
    He seems to be from Mozilla..
    - kevingadd 12y ago
      Literally his first slide says that he works for Google on Dart. What is this nonsense?
bsaul 12y ago
this talk didn't talk about server-side dart. does this mean the project is refocusing on client code ? also another question : does anyone here using angulardart can talk about how much static type anotation helps ? i'm thinking of future<t> instead of $q and directive writing ( which i always found a bit confusing, so maybe types help).
- WoodenChair 12y ago
  In regards to your question about server-side Dart, it seems that the space is just beginning to mature. A couple frameworks have solidified a fan base such as: http://redstonedart.org http://redstonedart.org https://github.com/lvivski/start https://github.com/lvivski/start There's also a Dart specific hosting service that's in beta: http://www.dartvoid.com http://www.dartvoid.com And there's been some success running Dart on Google Compute Engine through App Engine Managed VM (not sure if this is out of beta).
lars_francke 12y ago
I am mostly a Java developer. I guess I could write syntactically correct JavaScript but it's a bit alien to me. As is the whole tooling landscape of JavaScript (Grunt, Node, Angular, Backbone, etc.). I'd like to do a few personal projects with server-side scripting and I need to learn a new language and ecosystem for it. From what I've seen I'd rather learn Dart because it is more familiar to me. What's been stopping me from doing that is missing integration and/or documentation in asset compilation toolchains for example in Play (i.e. no sbt-web plugin).
- WoodenChair 12y ago
  Dart is often found to be very familiar by Java developers. In fact, on the mailing list, it is sometimes criticized for being too Java like. Java developers who feel disaffected by JavaScript are certainly a large niche that Dart appeals to.
- javajosh 12y ago
  You might try Adobe's editor, Brackets. It does a very good job at psudeo-intellisense, can even infer argument types, and has lots of nice plugins for working with JavaScript - including features that let you see the body of a function under the cursor, or the JSDoc (the equiv of JavaDoc). There is a JSHint plugin (linting is the closest JS gets to compilation). And of course the Theseus debugger, which is quite good. I think its neat that the editor is built on browser tech (Github's Atom is built like that, too). Client side development is, ironically, somewhat more complex because of the lack of module standard. You'll almost certainly want to use require() in the browser, but that won't work without taking extra, confusing steps. 'Browserify' pre-processes your JavaScript, generating a single large bundle, but that introduces complexity both at build- and run-time. And that doesn't even address the ongoing saga of the lack of a module standard for the browser. By contrast, writing simple programs or servers in Node is vastly more enjoyable than in Java.
shurcooL 12y ago
I wish they'd invest in Go for the frontend. If a project like GopherJS can get as far [1] as it is now with just 1 person working on it for a few months, imagine if it had more support. And then you could use a language as nice as Go for both frontend and backend. [1] https://github.com/gopherjs/gopherjs#what-is-supported https://github.com/gopherjs/gopherjs#what-is-supported
- dingdingdang 12y ago
  Yes, I totally echo this sentiment - Javascript has the traction and the stability to be a good transpiler target. That Google is actively trying to push both Dart and Go simply makes no sense for me, especially since Dart is supposedly (as far as I can tell with half a degree in googling) aimed at frontend work more-so than Go but at the same time seems to come with even more complex language structure than Go..
dingdingdang 12y ago
"Why Google thinks you should drop everything you do and pick up Go" .. no wait.. compute error.
A1kmm 12y ago
I actually see the Google-backed web technologies as a net negative. The general pattern is that 1) the community starts to develop good tools that work well in all browsers 2) Google comes along with a technologically inferior solution that they developed in-house. They present it as being ostensibly completely free and open source, but it is designed in a way that means it will be faster in Chrome and hard for other browsers to support as well due to different architectural decisions. 3) Google markets the solution well through its large and well connected employee and fan base, and so the Google technology gets much more adoption than the earlier and technically better alternative. Presumably they do all this in an attempt to make the web unusable through any browser except Chrome, so they can over the long term replace the open web with the 'Google web' that they control. For example, compare Ember and Angular; Ember's architecture records the dependencies between values, and only updates what needs to be updated when an upstream dependency changes, while Angular has to recompute everything on every 'digest' cycle. When it comes to writing directives in a complex Angular application, you often to set a numerical priority field to the just the right number to get things to happen in proper order - leading to spaghetti code that is hard to reason about and fragile to extend. I think Dart is even worse when compared to better emerging options like ghcjs (which compiles Haskell to JavaScript) and Elm; these alternatives have more powerful type systems that make common patterns like reactive programming and generic programming much easier and safer. Control structures that are built into Dart (e.g. the 'async' feature) can be treated as just one instance of a general type class (e.g. Monad) with ghcjs. I think everything considered, these highly promoted and usually highly adopted but technically inferior Google front-end technologies are actually a net negative for the web.
- abritishguy 12y ago
  I agree that ember is better than angular but there is no reason why angular should run faster in chrome so it is not really relevant to your first point. In fact apart from Dart I can't think of any web technology that Google is promoting to developers that will be faster in chrome.
voidr 12y ago
This to me feels a lot like GWT: making it easier for Java developers to write client side code. It was marketed as faster, however in reality it's slower on everything except a special build of Chrome. It supposed to make us more productive, however all it does is that it makes churning out code easier at the expense of debugging. Sourcemaps are here to solve these issues, however since Dart is not a purely transpiled language, I don't really see that working out. In my opinion Dart is an excellent research project, but it ultimately fails at fixing anything that makes client side web development hard.

47 points by WoodenChair 12y ago

What's the killer feature of dart? I went through some docs and couldn't see anything JavaScript doesn't already have or is soon to have.

CmonDev 12y ago
Proper OOP and type checking. Fighting to finally make the web open. Open to new languages, technologies and innovation. All we have now is legacy stuff like JS and HTML. I hope NaCl will also start dominating at some point. Freedom of choice of tools is important.
- pjmlp 12y ago
  Apps will free us.
pjmlp 12y ago
If Google had done this right with the other vendors, it would have been the second coming of Smalltalk in a way. As the developer experience is somehow similar. As it is, it is just another language that transpiles to JavaScript.
chewxy 12y ago
Optional typing is pretty interesting, IMO. I'm not sure if that is a killer feature for programmers who are used to JS dev tho
yulaow 12y ago
It will be supported only on chrome while any other browser will ignore it. It remember me of Jscript or Vbscript, what a vibrant future /s
- marcell 12y ago
  Looking at the slides, I don't think this is accurate. You can compile Dart into Javascript, which will run on non-Chrome browsers. The advantage is that (1) on Chrome, you get better performance, and (2) you get a nicer language that Javascript.
  - yulaow 12y ago
    And now I have to support (and debug) two languages only because on a single browser one can perform slightly better, while the rest of the resources and frameworks for web clients are all written in javascript. No thanks
    - WoodenChair 12y ago
      Why would you be supporting two languages? You can choose to write your app in JavaScript (that's not going away and that's one language) or you can choose to write your app in Dart (also just one language) which will run as Dart on the Dart VM and compiled-you-don't-touch-it JavaScript everywhere else. Sounds like FUD to me.
      - yulaow 12y ago
        Because if I choose dart I have still to deal with the derived javascript code implementation I must use to run in other browser that are not chrome and, as described by the post close to this, often that js is so broken it cause big bugs on firefox for example, and to understand and repair those you have to know js.
        WoodenChair 12y ago
        I would take what kevingadd says with a grain of salt. He's the author of a .NET -> JS compiler (arguably a competitor to Dart) and the experience he cites below is pretty different from what I've had and my colleagues have had. I don't mean that as character assassination - he's obviously a very talented developer - but rather as a point of contrast. Frankly, you would not want to be touching the compiled JavaScript from Dart - it's not meant to be changed. I agree that if it's that broken, then you should certainly not use the platform. So you should just be writing in JavaScript or just be writing in Dart.
WoodenChair 12y ago
There's not just one killer feature. Here's a few strong features that add up: - optional static type annotations - advanced object-oriented features (mixins, advanced constructors, etc) - rich built-in libraries - pub package manager - 2X V8 performance w/ the Dart VM - integrated tooling - exceptions - generics - operator overloading... I could go on, but basically I'm not sure what language you were looking at because Dart has a lot that plain vanilla JavaScript does not (although can have with extensions). It also doesn't inherit all of those flaws JavaScript got from being designed in a time crunch (10 days is really not enough time to design a language). If I had to pick one though, it would probably be the fact that Dart is a platform (rich language, libraries, tools, and package manager) rather than hodge podge of frameworks on top of a lightweight language.
- ajizzle 12y ago
  If it compiles down to javascript then it does have the same flaws as javascript. 2x performance of v8 is bullshit, and "rich built-in libraries" and "integrated tooling" are just marketing drabble. If you understand what they actually mean please explain or gtfo.
  - WoodenChair 12y ago
    Sure, I'll explain each one. Performance - Dart has its own VM which runs independently (on the server, or in special builds of Chrome, but soon to be mainline Chrome). So it's not just a language that trans-compiles to JavaScript, it's also a language with its own independent high performance VM that you can use on the server today and the browser tomorrow (hopefully). By the way the Dart VM was written by the same guys that created V8 - generally considered to be one of the highest performance JavaScript VMs - so I think we can believe them when they say it's higher performing. Rich Built-in Libraries - Just take a look here: https://api.dartlang.org/ https://api.dartlang.org/ There's everything from a reflections API to a WebGL library. There's JavaScript interop libraries, concurrency libraries, and the equivalent of jQuery built-in. That's just scratching the surface. Integrated Tooling - Dart has its own package manager (pub) which is quite nice as well as its own IDE (Dart Editor) which comes with a debugger, profiler, and all the niceties you'd expect (code completion, deployment help, etc). It's also a new language (less than a year since 1.0) backed by a big company so these things are only going to continue to improve.
skrebbel 12y ago
It's tool support and unsurprising semantics. Few other web frontend languages have that. TypeScript comes close with the tool support, but it doesn't have the unsurprising semantics, and all in all it's a lot more limited, because it's designed to be a near-superset of JavaScript. I'd be using Dart already if it was simpler to integrate with existing JS libraries. That's the part TypeScript got way better. Tool support must be one of the most underrated language features these days. The enormity of blog posts about desiging your ruby code for "greppability" is just scary - I just want my tool to generate a call hierarchy for me, thank you. Dart has this covered.
mpweiher 12y ago
Semantically, Dart is pretty much Smalltalk, so it's actually a useful, reasonably well-thought-out language with sane semantics. A bit of a shame about the syntax... It even has doesNotUnderstand:, so it's quite extensible. The optional typing is neat: you can have a type error and the program won't just compile, it will continue to run! There's a video of Gilad demonstrating this in a live coding environment: he changes the type of a variable that's a number to String and apart from the compiler now complaining, nothing changes. The isolates concept also seems well-thought out, with separate heaps and the only interaction via messaging. Nothing breathtakingly new, but I think they picked up the right thing and implemented it well. The fact that the semantics are sane means the compiler can create faster code than JS with fewer heroics (if it isn't compiled via JS).

tomjen3 12y ago

Anybody have a link to the slides? I don't really want to waste time watching a video to see what they are up to.

WoodenChair 12y ago
https://docs.google.com/presentation/d/1EWLLgsl-m4OCRcvgf2BixnLCLNTAGLfxWhYI0M5j19c/edit#slide=id.g177d510c8_0342 https://docs.google.com/presentation/d/1EWLLgsl-m4OCRcvgf2Bi...

ajizzle 12y ago

Another self-righteous blue haired web developer complaining that he doesn't get enough geek respect in the current state of the web.

deleted 12y ago

[deleted]

Soyuz 12y ago

Anybody used Dart for serious web development?

WoodenChair 12y ago
Here are people who do: https://www.dartlang.org/community/who-uses-dart.html https://www.dartlang.org/community/who-uses-dart.html
stesch 12y ago
I evaluated it. Didn't work in Firefox 31 Beta. Reported the bug. Was fixed in Dart around the time when Firefox 32 RC got released. Please remember to recompile all your apps you deployed with Dart < 1.6. There are still some Firefox users out there. (Majority in Germany uses Firefox.)
frik 12y ago
Notch (creator of Minecraft) uses it for some smaller WebGL games: http://blog.tojicode.com/2013/12/notch-webgl-dart-and-ramping-up-quickly.html http://blog.tojicode.com/2013/12/notch-webgl-dart-and-rampin... and on HN https://news.ycombinator.com/item?id=6841557 https://news.ycombinator.com/item?id=6841557
woven 12y ago
Way before 1.0 existed (and using an early version of Polymer called WebUI) we built a first version of our app, e.g. http://woven.co/miamitech http://woven.co/miamitech, which is a fairly complex client and server side application. (The slowness is due to our poor pgsql data design.) I'm now building a more focused version with the latest SDK and Polymer, the beginnings of which are at http://mycommunity.org http://mycommunity.org. For me it's simple: Google is arguably the greatest champion of the open web and probably does more to advance modern web development than most anyone else. V8 was a game changer, and enabled Node. The same folks behind V8 are building, in essence, a better Node. Modern web development with JavaScript is exciting, and there are so many great libraries and resources out there, but there is also much to be desired such as more structure, a saner language and a strong suite of core libraries that play well together. In my experience, Dart is what they say it is: a more structured approach to modern web app development.

ntoshev 12y ago

"Google" does not think that, a cofounder of the Dart project does.

WoodenChair 12y ago
It's the official name of the talk.
- thomasahle 12y ago
  He seems to be from Mozilla..
  - kevingadd 12y ago
    Literally his first slide says that he works for Google on Dart. What is this nonsense?

bsaul 12y ago

this talk didn't talk about server-side dart. does this mean the project is refocusing on client code ? also another question : does anyone here using angulardart can talk about how much static type anotation helps ? i'm thinking of future<t> instead of $q and directive writing ( which i always found a bit confusing, so maybe types help).

WoodenChair 12y ago
In regards to your question about server-side Dart, it seems that the space is just beginning to mature. A couple frameworks have solidified a fan base such as: http://redstonedart.org http://redstonedart.org https://github.com/lvivski/start https://github.com/lvivski/start There's also a Dart specific hosting service that's in beta: http://www.dartvoid.com http://www.dartvoid.com And there's been some success running Dart on Google Compute Engine through App Engine Managed VM (not sure if this is out of beta).

lars_francke 12y ago

I am mostly a Java developer. I guess I could write syntactically correct JavaScript but it's a bit alien to me. As is the whole tooling landscape of JavaScript (Grunt, Node, Angular, Backbone, etc.). I'd like to do a few personal projects with server-side scripting and I need to learn a new language and ecosystem for it. From what I've seen I'd rather learn Dart because it is more familiar to me. What's been stopping me from doing that is missing integration and/or documentation in asset compilation toolchains for example in Play (i.e. no sbt-web plugin).

WoodenChair 12y ago
Dart is often found to be very familiar by Java developers. In fact, on the mailing list, it is sometimes criticized for being too Java like. Java developers who feel disaffected by JavaScript are certainly a large niche that Dart appeals to.
javajosh 12y ago
You might try Adobe's editor, Brackets. It does a very good job at psudeo-intellisense, can even infer argument types, and has lots of nice plugins for working with JavaScript - including features that let you see the body of a function under the cursor, or the JSDoc (the equiv of JavaDoc). There is a JSHint plugin (linting is the closest JS gets to compilation). And of course the Theseus debugger, which is quite good. I think its neat that the editor is built on browser tech (Github's Atom is built like that, too). Client side development is, ironically, somewhat more complex because of the lack of module standard. You'll almost certainly want to use require() in the browser, but that won't work without taking extra, confusing steps. 'Browserify' pre-processes your JavaScript, generating a single large bundle, but that introduces complexity both at build- and run-time. And that doesn't even address the ongoing saga of the lack of a module standard for the browser. By contrast, writing simple programs or servers in Node is vastly more enjoyable than in Java.

shurcooL 12y ago

I wish they'd invest in Go for the frontend. If a project like GopherJS can get as far [1] as it is now with just 1 person working on it for a few months, imagine if it had more support. And then you could use a language as nice as Go for both frontend and backend. [1] https://github.com/gopherjs/gopherjs#what-is-supported https://github.com/gopherjs/gopherjs#what-is-supported

dingdingdang 12y ago
Yes, I totally echo this sentiment - Javascript has the traction and the stability to be a good transpiler target. That Google is actively trying to push both Dart and Go simply makes no sense for me, especially since Dart is supposedly (as far as I can tell with half a degree in googling) aimed at frontend work more-so than Go but at the same time seems to come with even more complex language structure than Go..

dingdingdang 12y ago

"Why Google thinks you should drop everything you do and pick up Go" .. no wait.. compute error.

A1kmm 12y ago

I actually see the Google-backed web technologies as a net negative. The general pattern is that 1) the community starts to develop good tools that work well in all browsers 2) Google comes along with a technologically inferior solution that they developed in-house. They present it as being ostensibly completely free and open source, but it is designed in a way that means it will be faster in Chrome and hard for other browsers to support as well due to different architectural decisions. 3) Google markets the solution well through its large and well connected employee and fan base, and so the Google technology gets much more adoption than the earlier and technically better alternative. Presumably they do all this in an attempt to make the web unusable through any browser except Chrome, so they can over the long term replace the open web with the 'Google web' that they control. For example, compare Ember and Angular; Ember's architecture records the dependencies between values, and only updates what needs to be updated when an upstream dependency changes, while Angular has to recompute everything on every 'digest' cycle. When it comes to writing directives in a complex Angular application, you often to set a numerical priority field to the just the right number to get things to happen in proper order - leading to spaghetti code that is hard to reason about and fragile to extend. I think Dart is even worse when compared to better emerging options like ghcjs (which compiles Haskell to JavaScript) and Elm; these alternatives have more powerful type systems that make common patterns like reactive programming and generic programming much easier and safer. Control structures that are built into Dart (e.g. the 'async' feature) can be treated as just one instance of a general type class (e.g. Monad) with ghcjs. I think everything considered, these highly promoted and usually highly adopted but technically inferior Google front-end technologies are actually a net negative for the web.

abritishguy 12y ago
I agree that ember is better than angular but there is no reason why angular should run faster in chrome so it is not really relevant to your first point. In fact apart from Dart I can't think of any web technology that Google is promoting to developers that will be faster in chrome.

voidr 12y ago

This to me feels a lot like GWT: making it easier for Java developers to write client side code. It was marketed as faster, however in reality it's slower on everything except a special build of Chrome. It supposed to make us more productive, however all it does is that it makes churning out code easier at the expense of debugging. Sourcemaps are here to solve these issues, however since Dart is not a purely transpiled language, I don't really see that working out. In my opinion Dart is an excellent research project, but it ultimately fails at fixing anything that makes client side web development hard.