4 ms·

I occasionaly read the esdiscuss list, and from those discussions, I get a sense that it is incredibly difficult to evolve JS given the legacy compatibility con

by xxgreg 12y ago

I occasionaly read the esdiscuss list, and from those discussions, I get a sense that it is incredibly difficult to evolve JS given the legacy compatibility constraints. In my view having the Dart team trial new features in a new codebase without the legacy constraints allows them to move quickly, and get feedback about new features by shipping real code in real products. The results of this process can give good input back to the ECMAScript process. Perhaps this has already happened, I guess good examples would be SIMD, and the scoping rules around for of loops. One of the most important improvements I see in Dart, is the focus on reducing start up time. i.e. snapshots and lazy evaluation of top level variable initialisers. They are currently claiming a 10x start up time when snapshots are used. This would be a huge benefit for mobile apps. Is there any one investigating how you chould change or subset Javascript to allow for snapshotting? Snapshotting seems really beneficial for the web, especially for the mobile web vs native. Currently I only see the Dart team working on this.

BrendanEich 12y ago
Dart may prototype ideas that land in JS, but then why not help with bignums sooner (see http://code.google.com/p/dart/issues/detail?id=1533 http://code.google.com/p/dart/issues/detail?id=1533)? Time's a-wasting, Dart started at least in 2010 (first I heard of it was that spring). JS compat constraints would affect anything like it at scale, see also HTML5 and version-as-anti-pattern-on-Web. Snapshotting would be relatively easy to do with ES6's module system. People would have to refrain from abusing the global object, or snapshotting might fail. Honestly, ES6 modules plus the asm.js work to avoid loading too much cold code is likely to bear more fruit than a new VM's bespoke snapshotting tech. Again, Dart ain't gonna replace JS in the foreseeable future. We need progress on the Web we have, not a dream-Web we can't have.
- xxgreg 12y ago
  > why not help with bignums sooner It's great that Apple and MS are on board with ES6. But even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors would have also implemented it already? I find this scenario unlikely - but you obviously have a better view of this than I do. > Snapshotting would be relatively easy to do with ES6's module system. People would have to refrain from abusing the global object, or snapshotting might fail. I guess you'd need to add some extra restrictions, such as no top level code outside of functions including variable initialisers, and no modification of prototype chains. This seems hard to do with JS as it is written today. Perhaps the "use strong" experiment will make this easier. > ES6 modules plus the asm.js work to avoid loading too much cold code is likely to bear more fruit than a new VM's bespoke snapshotting tech This is your intuition and opinion. Some people disagree, and have chosen to put their effort into another approach. Maybe you're right. Maybe they're right. Personally I think it's better to try both approaches, and let benchmarks settle this. From the benchmarks I've seen, snapshots look very promising. > Dart ain't gonna replace JS in the foreseeable future Flamebait! It doesn't need to. It just needs to provide good development tooling for some developers who prefer using it than vanilla javascript.
  - BrendanEich 12y ago
    Bignums have been on the Harmony agenda for years, going back to: http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums from 2010 (before the Dash memo leaked, before dherman or anyone on TC39 not from Google, and probably any of the folks from Google for that matter, knew that Dart had `int` as bignum). With V8 jumping in, you bet that they'd have been implemented in at least V8 and probably SpiderMonkey -- just as many ES6 features proposed since then have been: http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ Did you know about these precedents? Serious question. I'm not citing total what-ifs here: we did have bignums on the agenda, but we lacked a V8-level champion; we did -- we the various JS engine implementors -- implement a lot in the last few years. No intuition is required to say that VM isolate snapshotting (if that's truly needed to deal with massive gmail-level cold-code on first load; I see other solutions) could be added to JS if it could be done for Dart. Lars Bak tried asserting no-way-in-JS because of the notorious JS global object. I say: never say never, opt-in is the way the web evolves. The global object is being ring-fenced by ES6 modules and new binding forms. This is not a difference of opinion, it's a matter of choice and funding. Also not flamebait: my point about JS not going away. You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling", seemingly in response to my pointing out that there hasn't been much uplift over five years. What's with the goalpost moving, and in a weak direction to boot? You were very much on target citing SIMD flowing from Dart to JS, thanks to John McCutchan, to whom I tweeted the idea when I saw his tweet about Dart SIMD: https://twitter.com/BrendanEich/status/308343704194781186 https://twitter.com/BrendanEich/status/308343704194781186 John replied that he was going to look at JS SIMD next. So thanks to me too -- this Dart => JS transfer was not as far as I can tell on the Dart leaders' agenda, it was bottom up work by John. After our twitter exchange, Mozilla and Intel joined in. The `for (let...)` binding per iteration semantics in ES6 did not come directly from Dart. We'd been working on it for a while in TC39. Here's a note from me about it (find "binding per iteration") from 2009: http://wiki.ecmascript.org/doku.php?id=harmony:let http://wiki.ecmascript.org/doku.php?id=harmony:let It helped to have Dart do it, in the "moral support" and "evidence it is worth the spec/impl complexity" senses. But there was no tech transfer or direct causation. Don't get me wrong, Google cannot spend tens of millions on top talent and make something of zero value. My point about opportunity costs stands. We could have come a lot farther, faster. This is true now as it was in the IE monopoly era (no, I'm not saying things are as bad, just that the hazard of doing WPF or Dart instead of working more directly on the Web stack remains). Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost. There are better ways to improve the system we're stuck with, sooner. I'm not religious about this, nor are the V8 folks now working in earnest on SoundScript. You're seeing more of what I'm advocating, finally. It wasn't in evidence for too many years.
- dargle 12y ago
  Technological improvements have increased the preponderance of crap on the web. Dart ain't gonna change that but it will give more centralized control to Google. More technology means more corporations building crap. I should know, I've spent about three months of my 10+ year building things that were just slightly better than useless.

by xxgreg 12y ago

BrendanEich 12y ago

Dart may prototype ideas that land in JS, but then why not help with bignums sooner (see http://code.google.com/p/dart/issues/detail?id=1533 http://code.google.com/p/dart/issues/detail?id=1533)? Time's a-wasting, Dart started at least in 2010 (first I heard of it was that spring). JS compat constraints would affect anything like it at scale, see also HTML5 and version-as-anti-pattern-on-Web. Snapshotting would be relatively easy to do with ES6's module system. People would have to refrain from abusing the global object, or snapshotting might fail. Honestly, ES6 modules plus the asm.js work to avoid loading too much cold code is likely to bear more fruit than a new VM's bespoke snapshotting tech. Again, Dart ain't gonna replace JS in the foreseeable future. We need progress on the Web we have, not a dream-Web we can't have.

xxgreg 12y ago
> why not help with bignums sooner It's great that Apple and MS are on board with ES6. But even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors would have also implemented it already? I find this scenario unlikely - but you obviously have a better view of this than I do. > Snapshotting would be relatively easy to do with ES6's module system. People would have to refrain from abusing the global object, or snapshotting might fail. I guess you'd need to add some extra restrictions, such as no top level code outside of functions including variable initialisers, and no modification of prototype chains. This seems hard to do with JS as it is written today. Perhaps the "use strong" experiment will make this easier. > ES6 modules plus the asm.js work to avoid loading too much cold code is likely to bear more fruit than a new VM's bespoke snapshotting tech This is your intuition and opinion. Some people disagree, and have chosen to put their effort into another approach. Maybe you're right. Maybe they're right. Personally I think it's better to try both approaches, and let benchmarks settle this. From the benchmarks I've seen, snapshots look very promising. > Dart ain't gonna replace JS in the foreseeable future Flamebait! It doesn't need to. It just needs to provide good development tooling for some developers who prefer using it than vanilla javascript.
- BrendanEich 12y ago
  Bignums have been on the Harmony agenda for years, going back to: http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums from 2010 (before the Dash memo leaked, before dherman or anyone on TC39 not from Google, and probably any of the folks from Google for that matter, knew that Dart had `int` as bignum). With V8 jumping in, you bet that they'd have been implemented in at least V8 and probably SpiderMonkey -- just as many ES6 features proposed since then have been: http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ Did you know about these precedents? Serious question. I'm not citing total what-ifs here: we did have bignums on the agenda, but we lacked a V8-level champion; we did -- we the various JS engine implementors -- implement a lot in the last few years. No intuition is required to say that VM isolate snapshotting (if that's truly needed to deal with massive gmail-level cold-code on first load; I see other solutions) could be added to JS if it could be done for Dart. Lars Bak tried asserting no-way-in-JS because of the notorious JS global object. I say: never say never, opt-in is the way the web evolves. The global object is being ring-fenced by ES6 modules and new binding forms. This is not a difference of opinion, it's a matter of choice and funding. Also not flamebait: my point about JS not going away. You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling", seemingly in response to my pointing out that there hasn't been much uplift over five years. What's with the goalpost moving, and in a weak direction to boot? You were very much on target citing SIMD flowing from Dart to JS, thanks to John McCutchan, to whom I tweeted the idea when I saw his tweet about Dart SIMD: https://twitter.com/BrendanEich/status/308343704194781186 https://twitter.com/BrendanEich/status/308343704194781186 John replied that he was going to look at JS SIMD next. So thanks to me too -- this Dart => JS transfer was not as far as I can tell on the Dart leaders' agenda, it was bottom up work by John. After our twitter exchange, Mozilla and Intel joined in. The `for (let...)` binding per iteration semantics in ES6 did not come directly from Dart. We'd been working on it for a while in TC39. Here's a note from me about it (find "binding per iteration") from 2009: http://wiki.ecmascript.org/doku.php?id=harmony:let http://wiki.ecmascript.org/doku.php?id=harmony:let It helped to have Dart do it, in the "moral support" and "evidence it is worth the spec/impl complexity" senses. But there was no tech transfer or direct causation. Don't get me wrong, Google cannot spend tens of millions on top talent and make something of zero value. My point about opportunity costs stands. We could have come a lot farther, faster. This is true now as it was in the IE monopoly era (no, I'm not saying things are as bad, just that the hazard of doing WPF or Dart instead of working more directly on the Web stack remains). Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost. There are better ways to improve the system we're stuck with, sooner. I'm not religious about this, nor are the V8 folks now working in earnest on SoundScript. You're seeing more of what I'm advocating, finally. It wasn't in evidence for too many years.
dargle 12y ago
Technological improvements have increased the preponderance of crap on the web. Dart ain't gonna change that but it will give more centralized control to Google. More technology means more corporations building crap. I should know, I've spent about three months of my 10+ year building things that were just slightly better than useless.