5 ms·

> 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

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

jeswin 12y ago
Stop making up stuff. I never said GC is in the language specification; instead was responding _specifically_ to your own statement about C# being supported well by the Mono runtime. I assumed it was fairly obvious what I stated: for C# to work you need the runtime (with the GC) and the Mono implementation while being good enough, lagged Microsoft's for a long time. Still does probably by a bit. In short, I don't believe we need a single Dart VM any more than we need a single HTML rendering engine. I don't believe Mozilla (and others) have to depend on Google engineers for anything in their product, even if it is Open Source. I don't believe a single company should go about extending the web by leveraging market dominance; like Google is doing right now. Our positions are very clear here, and we disagree. That's fine.
- mythz 12y ago
  > Stop making up stuff. I never said GC is in the language specification; instead was responding _specifically_ to your own statement about C# being supported well by the Mono runtime. Sorry you've got it backwards, you're the one who introduced the .NET Framework vs Mono and their differing GC implementations as a valid comparisons for Dart (which they're not): > C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years? I've just corrected you in both cases that the Mono compiler has excellent support for the (C#) language specification which it does, valid C# both compiles with the Mono C# compiler and runs on the Mono VM fine. The language specification was what made this possible. The issues that you cite in the early days have no basis for comparison with Dart, which are instead side-effects from re-implementing a closed implementation like ActiveX (another incorrect comparison) should anyone else had chosen to re-implement it. The fact is the Dart platform couldn't be any more open than it is already: it's completely open source, has a language specification, has multiple compliant open source implementations (Dart VM + Dart2JS), has open patent grants, develops in the open, accepts external contributions, features are prioritized and driven by user feedback, encourages re-use and adoption. The Mono team were instead forced to create the VM and compiler from scratch and had to re-implement and reverse-engineer .NET's vast class libraries and API's (which don't have specs), precisely because they're not able to re-use the existing implementation. The Mono team are actually very happy whenever Microsoft releases some of their .NET libraries as Open source which they've been able to re-use as-is. Thus none of the issues you've brought up applies to Dart which is entirely Open Source that both supports and encourages embedding and re-use. Instead of Mono and ActiveX, the JVM and open source OpenJDK implementation or examples of embedding V8 like node would've been better comparisons. > Our positions are very clear here, and we disagree. That's fine. Whilst I disagree with your invalid comparisons, I'm ok with the rest of your comments in which you're only stating your opinions and beliefs. In contrast, I believe innovations like Dart are going to help move the web forward and enable richer experiences and already improves the development of large web apps .

by mythz 12y ago

jeswin 12y ago

Stop making up stuff. I never said GC is in the language specification; instead was responding _specifically_ to your own statement about C# being supported well by the Mono runtime. I assumed it was fairly obvious what I stated: for C# to work you need the runtime (with the GC) and the Mono implementation while being good enough, lagged Microsoft's for a long time. Still does probably by a bit. In short, I don't believe we need a single Dart VM any more than we need a single HTML rendering engine. I don't believe Mozilla (and others) have to depend on Google engineers for anything in their product, even if it is Open Source. I don't believe a single company should go about extending the web by leveraging market dominance; like Google is doing right now. Our positions are very clear here, and we disagree. That's fine.

mythz 12y ago
> Stop making up stuff. I never said GC is in the language specification; instead was responding _specifically_ to your own statement about C# being supported well by the Mono runtime. Sorry you've got it backwards, you're the one who introduced the .NET Framework vs Mono and their differing GC implementations as a valid comparisons for Dart (which they're not): > C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years? I've just corrected you in both cases that the Mono compiler has excellent support for the (C#) language specification which it does, valid C# both compiles with the Mono C# compiler and runs on the Mono VM fine. The language specification was what made this possible. The issues that you cite in the early days have no basis for comparison with Dart, which are instead side-effects from re-implementing a closed implementation like ActiveX (another incorrect comparison) should anyone else had chosen to re-implement it. The fact is the Dart platform couldn't be any more open than it is already: it's completely open source, has a language specification, has multiple compliant open source implementations (Dart VM + Dart2JS), has open patent grants, develops in the open, accepts external contributions, features are prioritized and driven by user feedback, encourages re-use and adoption. The Mono team were instead forced to create the VM and compiler from scratch and had to re-implement and reverse-engineer .NET's vast class libraries and API's (which don't have specs), precisely because they're not able to re-use the existing implementation. The Mono team are actually very happy whenever Microsoft releases some of their .NET libraries as Open source which they've been able to re-use as-is. Thus none of the issues you've brought up applies to Dart which is entirely Open Source that both supports and encourages embedding and re-use. Instead of Mono and ActiveX, the JVM and open source OpenJDK implementation or examples of embedding V8 like node would've been better comparisons. > Our positions are very clear here, and we disagree. That's fine. Whilst I disagree with your invalid comparisons, I'm ok with the rest of your comments in which you're only stating your opinions and beliefs. In contrast, I believe innovations like Dart are going to help move the web forward and enable richer experiences and already improves the development of large web apps .