3 ms·

The wider adoption of Dart is a pipe dream, and the fact that it will remain confined to Chrome is a very good thing. The web community should reject this, or w

by jeswin 12y ago

The wider adoption of Dart is a pipe dream, and the fact that it will remain confined to Chrome is a very good thing. The web community should reject this, or we'll soon have only one browser and one true master of the internet. - No other browser can practically implement or support Dart. If they do their implementation will be slower than Google's, and will get classified as inferior. Google has in abundance the time and money to build and fix bugs, which Mozilla and Opera may not have in the near future. - Google's engineering could have gotten JS much farther along, but from what I have read on Twitter the V8 team has been shuffled around and the focus of innovation on Chrome is Dart. - See how Chrome trails Firefox in ES6 here: http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ (Thankfully, arrow functions are landing soon). There is no other way this would be played out, and the plan from the outset must have been to push Dart forcefully using Google's distribution capability on the web and on devices. I am waiting for Servo to launch to become a full-time Mozilla cheerleader again, once again after Internet Explorer's heydays.

WoodenChair 12y ago
I'm not sure exactly what I said that you're replying to (or if you're just replying to my Dart boosterism more generally) but what you seem to be addressing are political issues (who controls the Web, where resources are allocated) and not technical issues. Considering that Dart is open source, standardized by the same international body as JavaScript (ECMA), and compiles to JavaScript I think the argument against it would be weightier if it was made on technical merits. But I agree that it would be dangerous for one company to control the web - but like you said it's a pipe dream that Dart will gain wider adoption - so why worry yourself by writing all that about it? You can't say it will never gain wider adoption and then also be worried about it gaining wider adoption at the same time. So either it has merit and will gain adoption and we should be worried about it, or it doesn't have merit and there's nothing to worry about.
- jeswin 12y ago
  Dart will never be adopted outside Chrome, but there is plenty to worry about already. - Google can push Dart the same way MS did with ActiveX - C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years? - The relegation of JS innovation to second place behind Dart is a cause of concern. HTML and JS are the basic foundations of our web.
  - mythz 12y ago
    > Dart will never be adopted outside Chrome This is an incorrect. Dart2JS is an implementation of the Dart specification that transpiles to JS and is supported by every modern browser. Dart also has great support for Source Maps letting you debug (JS Transpiled) Dart code in other browsers via source maps. The Dart team expect Dart2JS will be the primary way of running Dart which is why they've designed the language so that it transpiles well to JavaScript as a primary objective - i.e. they've often rejected language features which can't be implemented efficiently in JS (e.g. non-local returns). It's also not clear if Opera (by virtue of Blink) will adopt Dart once it lands into Chromium/Blink. > Google can push Dart the same way MS did with ActiveX ActiveX is a proprietary binary blob that has nothing in common with Dart. Dart is entirely Open Source, runs on all modern browsers and integrates cleanly with the DOM (i.e. like JS). > C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years? Only the language is a standard which Mono's compiler and runtime has excellent support for. The biggest problem Mono faces is that they've had to re-implement the massive .NET Framework class libraries themselves. This is not an issue with Dart because they entire platform (VM, Class Libraries, Tools, Analyzer, etc) is Open Source, so the same implementation can be used everywhere as-is.
    - jeswin 12y ago
      > Dart will never be adopted outside Chrome This is exactly where it becomes an issue. You get to a situation where apps running on Chrome are faster, and the other browsers are slower. Why would anyone run a slower JS implementation of an app, when Chrome gives them wings? > Google can push Dart the same way MS did with ActiveX A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag. > Only the language is a standard which Mono's compiler and runtime has excellent support for. Not true. As an example, for a long time Mono's GC was much slower than .Net's. The lessons from the 90s and early 2000's were very clear. We need to learn from them.
      - mythz 12y ago
        > This is exactly where it becomes an issue. You get to a situation where apps running on Chrome are faster, and the other browsers are slower. So? JavaScript apps already run faster with in Browsers with faster JS VMs or for different users on faster hardware and different devices e.g. Smart Phones vs iPads vs TVs vs Desktops. Safari in iOS had a much faster JS implementation than Android or even the WebView in iOS apps, this doesn't make slower devices useless or stop users from viewing websites in different apps than Safari or even stop other browser vendors from developing alternative browsers for iOS. Having a faster implementation doesn't make every other device or browser useless. > Why would anyone run a slower JS implementation of an app, when Chrome gives them wings? Why should the web be shackled to the limitations of JavaScript? This same reasoning could apply when V8 was first released which was 100x faster than other JS engines at the time. This just made every browser vendor care deeply and invest more in JavaScript performance. This is the same as impl-driven defacto standards like Canvas and WebGL, new experiences open up more categories and encourage other vendors to follow suit - A rising tide lifts all boats. The core Dart Team is driven by trying to improve the web as best they can, just as they've done with V8 they want all their work to be freely used and used to encourage new innovations on the web. > A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag. Not true. A valid implementation of a language spec precisely means that source code in that language can be run on any implementation, just like existing Java code could run on Android's Dalvik and ART VMs. When a language has a specification it makes it easier to create different implementations (http://en.wikipedia.org/wiki/List_of_Java_virtual_machines http://en.wikipedia.org/wiki/List_of_Java_virtual_machines). It's also possible when a language doesn't have a specification as seen with Ruby VMs (https://github.com/cogitator/ruby-implementations/wiki/List-of-Ruby-implementations https://github.com/cogitator/ruby-implementations/wiki/List-...) but it's much easier to implement when there's an unambiguous spec to follow. Also because Dart (like V8_ is both open source and embeddable, no-one needs to reimplement it, they can embed it as-is or port it. > You need the people who are embedded in the evolution of the platform, or you are always going to lag. The developers of Node, didn't have to work on V8 team to embed V8, neither does anything else that embeds, compiles or ports V8. > Not true. As an example, for a long time Mono's GC was much slower than .Net's. You're contradicting yourself and disproving your own point. A GC is not in the language specification, it's an implementation detail which the Mono team had to re-implement themselves precisely because it wasn't Open Source. None of this applies with the Dart platform or team whom are developing a truly open platform and embeddable VM who are actively encouraging other users and vendors to adopt. > The lessons from the 90s and early 2000's were very clear. We need to learn from them. It seems at least they're not as clear to you - none of your comparisons are valid, nor have you cited the ones that were.
mythz 12y ago
> No other browser can practically implement or support Dart. They don't have to, they can use the Open Source DartVM as-is, in-fact this is what Google encourages, just like how node was able to use V8 JavaScript engine - which they've said is an example of new use cases that's possible when you create a high-performance VM. > Google's engineering could have gotten JS much farther along Lars Bak and Kasper Lund on the Dart VM are the same guys on the V8 team, who were also on the world-leading JVM Hotspot compiler that was derived from the Strongtalk VM (the fastest implementation of Smalltalk) that they created. They believe performance of JavaScript is reaching its peak and is unlikely to see another 2x improvement, JS VM's are also extremely complex as JavaScript is extremely hard to optimize. By contrast Dart is a much simpler and predictable language designed for both productivity and performance and because it was designed in-hand with the VM engineers, language features are designed in a way that performs well.
- shadowmint 12y ago
  Which means exactly nothing if youre compiling dart to a javascript runtime, which is currently its only viable deployment target.

by jeswin 12y ago

WoodenChair 12y ago

I'm not sure exactly what I said that you're replying to (or if you're just replying to my Dart boosterism more generally) but what you seem to be addressing are political issues (who controls the Web, where resources are allocated) and not technical issues. Considering that Dart is open source, standardized by the same international body as JavaScript (ECMA), and compiles to JavaScript I think the argument against it would be weightier if it was made on technical merits. But I agree that it would be dangerous for one company to control the web - but like you said it's a pipe dream that Dart will gain wider adoption - so why worry yourself by writing all that about it? You can't say it will never gain wider adoption and then also be worried about it gaining wider adoption at the same time. So either it has merit and will gain adoption and we should be worried about it, or it doesn't have merit and there's nothing to worry about.

jeswin 12y ago
Dart will never be adopted outside Chrome, but there is plenty to worry about already. - Google can push Dart the same way MS did with ActiveX - C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years? - The relegation of JS innovation to second place behind Dart is a cause of concern. HTML and JS are the basic foundations of our web.
- mythz 12y ago
  > Dart will never be adopted outside Chrome This is an incorrect. Dart2JS is an implementation of the Dart specification that transpiles to JS and is supported by every modern browser. Dart also has great support for Source Maps letting you debug (JS Transpiled) Dart code in other browsers via source maps. The Dart team expect Dart2JS will be the primary way of running Dart which is why they've designed the language so that it transpiles well to JavaScript as a primary objective - i.e. they've often rejected language features which can't be implemented efficiently in JS (e.g. non-local returns). It's also not clear if Opera (by virtue of Blink) will adopt Dart once it lands into Chromium/Blink. > Google can push Dart the same way MS did with ActiveX ActiveX is a proprietary binary blob that has nothing in common with Dart. Dart is entirely Open Source, runs on all modern browsers and integrates cleanly with the DOM (i.e. like JS). > C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years? Only the language is a standard which Mono's compiler and runtime has excellent support for. The biggest problem Mono faces is that they've had to re-implement the massive .NET Framework class libraries themselves. This is not an issue with Dart because they entire platform (VM, Class Libraries, Tools, Analyzer, etc) is Open Source, so the same implementation can be used everywhere as-is.
  - jeswin 12y ago
    > Dart will never be adopted outside Chrome This is exactly where it becomes an issue. You get to a situation where apps running on Chrome are faster, and the other browsers are slower. Why would anyone run a slower JS implementation of an app, when Chrome gives them wings? > Google can push Dart the same way MS did with ActiveX A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag. > Only the language is a standard which Mono's compiler and runtime has excellent support for. Not true. As an example, for a long time Mono's GC was much slower than .Net's. The lessons from the 90s and early 2000's were very clear. We need to learn from them.
    - mythz 12y ago
      > This is exactly where it becomes an issue. You get to a situation where apps running on Chrome are faster, and the other browsers are slower. So? JavaScript apps already run faster with in Browsers with faster JS VMs or for different users on faster hardware and different devices e.g. Smart Phones vs iPads vs TVs vs Desktops. Safari in iOS had a much faster JS implementation than Android or even the WebView in iOS apps, this doesn't make slower devices useless or stop users from viewing websites in different apps than Safari or even stop other browser vendors from developing alternative browsers for iOS. Having a faster implementation doesn't make every other device or browser useless. > Why would anyone run a slower JS implementation of an app, when Chrome gives them wings? Why should the web be shackled to the limitations of JavaScript? This same reasoning could apply when V8 was first released which was 100x faster than other JS engines at the time. This just made every browser vendor care deeply and invest more in JavaScript performance. This is the same as impl-driven defacto standards like Canvas and WebGL, new experiences open up more categories and encourage other vendors to follow suit - A rising tide lifts all boats. The core Dart Team is driven by trying to improve the web as best they can, just as they've done with V8 they want all their work to be freely used and used to encourage new innovations on the web. > A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag. Not true. A valid implementation of a language spec precisely means that source code in that language can be run on any implementation, just like existing Java code could run on Android's Dalvik and ART VMs. When a language has a specification it makes it easier to create different implementations (http://en.wikipedia.org/wiki/List_of_Java_virtual_machines http://en.wikipedia.org/wiki/List_of_Java_virtual_machines). It's also possible when a language doesn't have a specification as seen with Ruby VMs (https://github.com/cogitator/ruby-implementations/wiki/List-of-Ruby-implementations https://github.com/cogitator/ruby-implementations/wiki/List-...) but it's much easier to implement when there's an unambiguous spec to follow. Also because Dart (like V8_ is both open source and embeddable, no-one needs to reimplement it, they can embed it as-is or port it. > You need the people who are embedded in the evolution of the platform, or you are always going to lag. The developers of Node, didn't have to work on V8 team to embed V8, neither does anything else that embeds, compiles or ports V8. > Not true. As an example, for a long time Mono's GC was much slower than .Net's. You're contradicting yourself and disproving your own point. A GC is not in the language specification, it's an implementation detail which the Mono team had to re-implement themselves precisely because it wasn't Open Source. None of this applies with the Dart platform or team whom are developing a truly open platform and embeddable VM who are actively encouraging other users and vendors to adopt. > The lessons from the 90s and early 2000's were very clear. We need to learn from them. It seems at least they're not as clear to you - none of your comparisons are valid, nor have you cited the ones that were.

mythz 12y ago

> No other browser can practically implement or support Dart. They don't have to, they can use the Open Source DartVM as-is, in-fact this is what Google encourages, just like how node was able to use V8 JavaScript engine - which they've said is an example of new use cases that's possible when you create a high-performance VM. > Google's engineering could have gotten JS much farther along Lars Bak and Kasper Lund on the Dart VM are the same guys on the V8 team, who were also on the world-leading JVM Hotspot compiler that was derived from the Strongtalk VM (the fastest implementation of Smalltalk) that they created. They believe performance of JavaScript is reaching its peak and is unlikely to see another 2x improvement, JS VM's are also extremely complex as JavaScript is extremely hard to optimize. By contrast Dart is a much simpler and predictable language designed for both productivity and performance and because it was designed in-hand with the VM engineers, language features are designed in a way that performs well.

shadowmint 12y ago
Which means exactly nothing if youre compiling dart to a javascript runtime, which is currently its only viable deployment target.