28 ms·

> Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input,

• cromwellian 14y ago
  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.
• justinschuh 14y ago
  >I don't think that's accurate. We started work on asm.js only a few months ago; at the beginning, we had no idea if it would work, so we just threw around some ideas between each other. When we had something we felt could actually work, we immediately put it up on As others have pointed out, Mozilla has been less than receptive when similar situations were reversed. I also know from working with the NaCl and PPAPI teams that they repeatedly reached out to Mozilla in an effort to publicly develop a mutually agreeable standard, but they were not well received. So, given past precedent, the way asm.js was introduced isn't necessarily bad, but it certainly feels a bit hypocritical. >> relies extensively on engine quirks >That would be a bad bug in the asm.js spec. Can you please elaborate? Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention. It's certainly an ingenious way to get backwards compatibility while basically defining a new IR, but it is a bit... quirky. As I mentioned elsewhere, I think asm.js might really catch on. It could be the IR that finally becomes universal, in large part because your backwards compatibility strategy is so damn clever. That said, I also see a few obvious pain points that will need solutions: * Reasonable debugging support (maybe just a metadata standard morally equivalent to symbol files) * Threading (even just co-routines, it seems some behavior needs to be specified) * Load performance (validation and code caching seem needed, which are very tractable but just mean more work)
  • azakai 14y ago
    > As others have pointed out, Mozilla has been less than receptive when similar situations were reversed. That's a long conversation, and I likely know nothing of the non-public aspects of it. From what I know of the public stuff, I don't think it is the same in reverse. I do see the general similarity you refer to, I just think there are some fundamental differences that explain the different responses. Happy to discuss this more if you want. > Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention. I still don't know what you mean, can you please say what concretely in the spec you are referring to?
    • justinschuh 14y ago
      >> Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention. >I still don't know what you mean, can you please say what concretely in the spec you are referring to? You're using a subset of JS as an IR, which is something the language was never designed for and not inherently good at. To make that performant you have to hack in things like manual memory management and use type coercions to game existing engine behavior. To get full performance you need significant engine changes including a mode switch, validation step, and special purpose compiler. And of course, the JS as IR doesn't really qualify as human readable in any meaningful sense. And I happily admit that type coercions and similar tricks are a very clever way to structure your IR while simultaneously maintaining compatibility and improving performance in existing JS engines. However, in doing so you're already relying heavily on unspecced implementation details of existing engines. So, my point is that it's a hack... a really brilliant hack that might actually be the best path forward for a universal IR on the Web. But it's still a hack, and it brings with it some serious pain points that still need to be resolved.