News for hackers. Stuff that matters.
Re:JavaScript performance, WebAssembly, and Shared Memory in... by pcwalton on Thursday April 20, 2017 @06:57PM (#14161632)
NaCl and Dart are things that actually happened. They were decidedly not standardized.
Re:JavaScript performance, WebAssembly, and Shared Memory in... by endorphone on Thursday April 20, 2017 @07:21PM (#14161774)
Dart - ECMA-408. Open and standard. BSD grant, etc.

NaCL - Completely open, patent grants, open source, etc. Not a standard, but they did everything possible to move there, and abandoned it when it didn't get interest from others.

Anything else?

Re:JavaScript performance, WebAssembly, and Shared Memory in... by pcwalton on Thursday April 20, 2017 @07:30PM (#14161820)
Dart and NaCl actively ignored outside feedback, even when in retrospect the feedback was clearly correct.

Few Web developers wanted Dart, and this was clear at the time Google went to ECMA. They pushed ahead with a standard anyway despite no other browser vendor signing on board. You can call anything a standard, but without a multi-vendor process, and with only a single implementation, the idea of a standard is pretty meaningless.

And, regarding Dart, on the WebKit side, many WebKit contributors were (quite reasonably) opposed to adding support for pluggable languages to the DOM, because of the unavoidable overheads introduced by this. As far as I recall, no solution to the problem of cross-language GC, which is one of the biggest issues here, had been even really proposed at the time. Google continued on ahead, forking WebKit into Blink, introducing Dartium, and then ending the project. Now, with Dartium dead, it has become clear in retrospect that the WebKit community was right all along: you don't want multiple incompatible languages hooked up to the DOM.

NaCl may have been "open" in that Chromium was open source, but the dependency on Pepper meant that Google's implementation was Chrome-only. Google solicited feedback on Pepper back in 2010, but Apple and Mozilla engineers provided compelling arguments as to why Pepper was unnecessary. They ignored the feedback and did it anyway. Now, after seven years, NaCl is obsolete in favor of the multi-vendor Web Assembly, which uses the Web APIs instead of Pepper—exactly the approach that everyone else on the plugin-futures mailing list had advocated in the first place.

A lot of unnecessary work would have been avoided if NaCl and Dart had been more receptive to feedback.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by markdog12 on Thursday April 20, 2017 @09:12PM (#14162311)
> Few Web developers wanted Dart

Do you just mean they didn't want the dart vm in browsers? Or the language? If the latter as well, I respectfully disagree.

> Dart actively ignored outside feedback

Again, on the language or just having the vm in browsers?

Re:JavaScript performance, WebAssembly, and Shared Memory in... by pcwalton on Thursday April 20, 2017 @09:20PM (#14162362)
Few developers wanted either the language or the native support in browsers. Witness the success of e.g. TypeScript compared to Dart.

There were plenty of issues in the Dart language, too. The way generics variance was deliberately unsound was bizarre, in particular, and they resisted attempts to fix it.

Re:JavaScript performance, WebAssembly, and Shared Memory in... by markdog12 on Thursday April 20, 2017 @09:34PM (#14162443)
As I'm sure you're aware, the better language doesn't always win the popularity contest. Typescript, being a superset of js still has a lot of its warts. Dart is more of a clean break.