3 ms·

Yet when Google spent only a few months developing the first Dart, and then released it to the public, and has been iterating on it for 2 years in full public v

Yet when Google spent only a few months developing the first Dart, and then released it to the public, and has been iterating on it for 2 years in full public view, and it still isn't even in Chrome nightlies (yet asm.js has already been dumped into Firefox nightlies) the same criticism was leveled at Google from Mozilla. I think Mozilla would get a lot more benefit if people stop with the juvenile "You're going down!" adversarial mentality. If someone from the Dart or NaCL team had tweeted "2013 is the year NaCL and Dart destroy Javascript!" imagine the uproar. This is about exploring the solution space for solving technical challenges related to maximizing performance, helping developer productivity, and strengthening the Web, and there are many potential solutions. (I for one don't see the "Web" as Javascript, I see it as HTTP, URL, 'drive-by', indexability, transparency, platform independence and location independence. HTML, CSS, and JS are just particular concrete embodiments of those principles, but 30 years from now, they could be implemented in a radically different way) I think asm.js is great for a slice of game genres, and I fully support it. The cheerleading and politics just isn't needed, let the code, benchmarks, and game demos speak for themselves.

haberman 14y ago
Couldn't agree more. I think asm.js is very cool, and very likely a better approach than PNaCl (which I have been a big fan of for a while). But the "take THAT, Google," sentiment is really off-putting. Native Client was never about "take THAT, Mozilla" (or anyone else), it was about serving an unmet need that no one else was serving.
azakai 14y ago
(reversed order of replies) > I think Mozilla would get a lot more benefit if people stop with the juvenile "You're going down!" adversarial mentality. [..] The cheerleading and politics just isn't needed, let the code, benchmarks, and game demos speak for themselves. I agree. Also, btw, I think NaCl is wrong for the web, but an amazing technology, designed by super-talented people (I met a few). It solves a very hard problem in an impressive way. It already has other use cases than the web, and I imagine will continue to. For the web, however, as I say I think it is inappropriate, due to portability and standardizability concerns (PNaCl solves some of the portability concerns). > Yet when Google spent only a few months developing the first Dart, and then released it to the public, and has been iterating on it for 2 years in full public view, and it still isn't even in Chrome nightlies (yet asm.js has already been dumped into Firefox nightlies) the same criticism was leveled at Google from Mozilla. I think a big part of the PR problem Dart has began with the fact that it was leaked. The leak was an internal document, and it spoke somewhat bluntly - which is fine for an internal document, but it was an unfortunate way for it to be revealed to the world.
fivealive 14y ago
> Yet when Google spent only a few months developing the first Dart ... the same criticism was leveled at Google from Mozilla. Yeah right. Dart was originally dash. Before that it was planned modifications to JS, but nobody wanted to turn JS into Java so you threatened JavaScript "would be replaced". Dart/dash/google.js is just open-washing. Nobody outside of Google has any say in it, and that's why they don't take to it.
- cromwellian 14y ago
  Sigh... No, Dart had nothing to do with planned modifications to JS, and if you think it was in the oven for a long time, why then have 2 years passed and it still isn't shipping in the browser, and the language grammar has undergone many changes? It's spent an enormous amount of time, the vast majority, in public development. The Dart2JS compiler was rewritten multiple times from scratch since then. I work for the GWT team, which was also owns the Google Closure Compiler. Simultaneously, at the same time, our team was kicking around taking the Closure type annotations, and making them actual (optional) grammar terminals instead of boilerplately JsDoc comments, pretty much exactly what TypeScript or JSX is today, and then propose those changes to TC39 (one difference is, we didn't have classes, we had Structural Types). A separate team was working on Traceur, which was prototyping a different set of changes to JS, and they too were planning to go the TC39 route. Google is a big company and can have multiple teams prototyping many approaches. This stuff about turning JS into Java sounds like religious nonsense from people who have an aesthetic derangement over classes and OO, there are advocates on both sides, not just Googlers (and in fact, there are Googlers opposed to classes in JS), and ES6 has been fielding Class proposals. We were testing out how various extensions "felt" and worked with tooling, for example, Structural Typing in the presence of recursive types has issues. There's nothing "non-open" about coming up with language extensions, doing a prototype implementation, and then putting it out for public review and drawing up a spec. That's exactly how all of the IETF specs get done -- rough consensus and running code. Talk is cheap, a proposal is better understood if it comes with an example prototype. Mozilla does their own prototyping of extensions to JS, it's the only way to really do a sanity check. Compared to IronMonkey, no one is under any illusions that something like Traceur was being pushed as some kind of official product for people to adopt and use, it was very clearly, a test bed for experimentation. If we take your definition, no one outside of Mozilla had any say over asm.js, they developed the complete asm.js spec without involving the public, dumped it fully formed, along with an implementation VM, emscripten integration, and even an UnrealEngine demo, all before any standardization activity. The draft spec has no non-Mozilla editors/contributors listed or acknowledged as far as I can tell. One of the real shames here, all the focus on Dart/NaCL, while native apps distributed on mobile OSes are eating our lunch. I want ChromeOS and FirefoxOS to be a success, but it is more likely to be a success if Mozilla, Google, et al can work together, and avoid attacks. It pains me to see this because both sides are doing tremendous work to move the web forward, and pettiness can harm spirit of cooperation.
smrtinsert 14y ago
Why is this a game technology and not a general purpose one? I think Mozilla might want to expand their message a bit, and provide some non game engine demos.

haberman 14y ago

Couldn't agree more. I think asm.js is very cool, and very likely a better approach than PNaCl (which I have been a big fan of for a while). But the "take THAT, Google," sentiment is really off-putting. Native Client was never about "take THAT, Mozilla" (or anyone else), it was about serving an unmet need that no one else was serving.

azakai 14y ago

(reversed order of replies) > I think Mozilla would get a lot more benefit if people stop with the juvenile "You're going down!" adversarial mentality. [..] The cheerleading and politics just isn't needed, let the code, benchmarks, and game demos speak for themselves. I agree. Also, btw, I think NaCl is wrong for the web, but an amazing technology, designed by super-talented people (I met a few). It solves a very hard problem in an impressive way. It already has other use cases than the web, and I imagine will continue to. For the web, however, as I say I think it is inappropriate, due to portability and standardizability concerns (PNaCl solves some of the portability concerns). > Yet when Google spent only a few months developing the first Dart, and then released it to the public, and has been iterating on it for 2 years in full public view, and it still isn't even in Chrome nightlies (yet asm.js has already been dumped into Firefox nightlies) the same criticism was leveled at Google from Mozilla. I think a big part of the PR problem Dart has began with the fact that it was leaked. The leak was an internal document, and it spoke somewhat bluntly - which is fine for an internal document, but it was an unfortunate way for it to be revealed to the world.

fivealive 14y ago

> Yet when Google spent only a few months developing the first Dart ... the same criticism was leveled at Google from Mozilla. Yeah right. Dart was originally dash. Before that it was planned modifications to JS, but nobody wanted to turn JS into Java so you threatened JavaScript "would be replaced". Dart/dash/google.js is just open-washing. Nobody outside of Google has any say in it, and that's why they don't take to it.

cromwellian 14y ago
Sigh... No, Dart had nothing to do with planned modifications to JS, and if you think it was in the oven for a long time, why then have 2 years passed and it still isn't shipping in the browser, and the language grammar has undergone many changes? It's spent an enormous amount of time, the vast majority, in public development. The Dart2JS compiler was rewritten multiple times from scratch since then. I work for the GWT team, which was also owns the Google Closure Compiler. Simultaneously, at the same time, our team was kicking around taking the Closure type annotations, and making them actual (optional) grammar terminals instead of boilerplately JsDoc comments, pretty much exactly what TypeScript or JSX is today, and then propose those changes to TC39 (one difference is, we didn't have classes, we had Structural Types). A separate team was working on Traceur, which was prototyping a different set of changes to JS, and they too were planning to go the TC39 route. Google is a big company and can have multiple teams prototyping many approaches. This stuff about turning JS into Java sounds like religious nonsense from people who have an aesthetic derangement over classes and OO, there are advocates on both sides, not just Googlers (and in fact, there are Googlers opposed to classes in JS), and ES6 has been fielding Class proposals. We were testing out how various extensions "felt" and worked with tooling, for example, Structural Typing in the presence of recursive types has issues. There's nothing "non-open" about coming up with language extensions, doing a prototype implementation, and then putting it out for public review and drawing up a spec. That's exactly how all of the IETF specs get done -- rough consensus and running code. Talk is cheap, a proposal is better understood if it comes with an example prototype. Mozilla does their own prototyping of extensions to JS, it's the only way to really do a sanity check. Compared to IronMonkey, no one is under any illusions that something like Traceur was being pushed as some kind of official product for people to adopt and use, it was very clearly, a test bed for experimentation. If we take your definition, no one outside of Mozilla had any say over asm.js, they developed the complete asm.js spec without involving the public, dumped it fully formed, along with an implementation VM, emscripten integration, and even an UnrealEngine demo, all before any standardization activity. The draft spec has no non-Mozilla editors/contributors listed or acknowledged as far as I can tell. One of the real shames here, all the focus on Dart/NaCL, while native apps distributed on mobile OSes are eating our lunch. I want ChromeOS and FirefoxOS to be a success, but it is more likely to be a success if Mozilla, Google, et al can work together, and avoid attacks. It pains me to see this because both sides are doing tremendous work to move the web forward, and pettiness can harm spirit of cooperation.

smrtinsert 14y ago

Why is this a game technology and not a general purpose one? I think Mozilla might want to expand their message a bit, and provide some non game engine demos.