8 ms·

Blink, PNaCl, And Standards

94 points by thristian 13y ago

pjmlp 13y ago
IE is dead, God save Chrome!
tim_hutton 13y ago
Does NaCl/PNaCl have a future now we've seen what Emscripten/ASM.js can do?
- dochtman 13y ago
  It certainly seems unlikely, but I guess it depends on how fast asm.js can get.
  - tim_hutton 13y ago
    Now only 1.3x slower than native on one large-ish benchmark (box2d): http://youtu.be/qrf9ONmtXbM http://youtu.be/qrf9ONmtXbM (I love the comparison he makes to evolution at the end. Yes, the process may give ugly creatures sometimes but they work.)
    - cromwellian 13y ago
      Unless you have a system with 4-8 cores and SIMD, and you want to leave a multiple of performance on the table: http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/3/ http://arstechnica.com/information-technology/2013/05/native... For example, 1200% slower in Mandelbrot rendering with asm.js vs OpenMP C code.
- notatoad 13y ago
  it has a future as long as firefox is the only implementor of asm.js and chrome/ium is the only implementor of PNaCl.
- dragonwriter 13y ago
  > Does NaCl/PNaCl have a future now we've seen what Emscripten/ASM.js can do? Possibly not; Google certainly likes the things they come up with, but it wouldn't be the first time that they spent lots of effort behind one approach but switched to back another approach that solved the same problem that others championed because it was better positioned for standardization; Google's interest in native-like performance on the web are more about the functionality than the mechanism.
micro_cam 13y ago
Am I the only one who feels like locking into a standard for something like this without first developing and testing an implementation would be a mistake?
- wmf 13y ago
  There is a process for that: You prototype the feature under an off-by-default feature flag, then standardize it, then turn it on by default. Apparently Chrome follows this process for HTML/CSS features but not for PNaCl or DRM.
  - dragonwriter 13y ago
    > You prototype the feature under an off-by-default feature flag Both NaCl and PNaCl, except for Chrome Web Store content, are under an off-by-default feature flag. > then standardize it, then turn it on by default. Apparently Chrome follows this process for HTML/CSS features but not for PNaCl or DRM. Except that there is nothing but speculation, at least nothing cited in the source article, supporting the idea that Google isn't following that path with PNaCl.
lucian1900 13y ago
Asm.js is no more an open standard than PNaCl. While I'm sure others disagree, PNaCl is much cleaner in design and with more predictable performance. It's the one I'd like to see win.
- LamaOfRuin 13y ago
  Not really the same. Anything that implements standard javascript will be able to run asm.js code just fine, even if they don't implement the possible optimizations. The same isn't true for NaCL.
  - lucian1900 13y ago
    But it'll be too slow to be useful for anything, so it's not quite so different.
    - jacobparker 13y ago
      That is not true. The unreal demo is usable even without the asm.js optimizations.
      - migueldeicaza 13y ago
        Just tried it on my iPhone, and it crashed.
        jacobparker 13y ago
        I know for certain that there are previous non-asm.js optimized builds of Firefox that run it fine (with a performance penalty, naturally.) Chrome currently crashes because Chrome can't handle enough variables per context. This is a bug with V8 that is allegedly getting fixed. It wouldn't surprise me if mobile support is currently minimal to none though; but this is something that can and almost surely will change independent of asm.js optimization support. (And this is the Unreal demo specifically - smaller projects should be supported by virtually any modern browser* as far as I know.) * Caveats: IE doesn't support WebGL, etc.
cromwellian 13y ago
NaCL was already part of Chromium prior to Blink, I hardly see the huge difference between NaCL and PNaCl in this regard. Besides that, Blink is the rendering engine, Blink != Chrome. To get Chrome, you have to add in V8, NaCL, codecs, and a bunch of other stuff. I see the promises to which Blink commits itself as being disjoint from Chrome. After all, there are lots of Chrome-only APIs, like Chrome extensions, Chrome sync, Chrome packaged apps, etc.
- espadrine 13y ago
  It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong?
  - dragonwriter 13y ago
    > It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong? Part of the incentive to fork was to avoid having to maintain support for multiple JS engines in the core project. I don't think that means that Blink requires V8 so much as that Blink's support for JS engines (compared to pre-split WebKit's) no longer includes explicit support for the engine used by Safari (whose name I can't remember) as part of the source tree, and presumably will over time be more tightly adapted to the needs of V8. This would seem to mean it will progressively become more difficult to build a Blink-based browser using a different JS engine.
    - cpleppert 13y ago
      They intend to tie V8 and the Dom deeper in the next versions of Chrome by using a new garbage collector. I'm pretty sure it will be well nigh impossible to use another Javascript engine.
- pcwalton 13y ago
  NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl is going to be enabled for Web content.
VikingCoder 13y ago
Do we know for sure that Blink itself needs to support PNaCL / Pepper? Or is it possible that PNaCL and Pepper can be implemented on top of Blink? Do we know for sure that Blink itself is violating any of these principles, to merely expose PNaCL / Pepper in Chrome?
espadrine 13y ago
What matters to me as a developer is this: will there be more compilers targeting PNaCl, or asm.js? Otherwise said, as a compiler writer, would you rather write a compiler that works in all browsers, and which needs no tools because of how simple the output is, or a compiler which targets just one browser, with a complex output to target?
- cromwellian 13y ago
  If you are a game developer, it doesn't much matter. Do you target a market of 500+ million Chrome users, or 2 billion web users, or 900 million Android users, or 500 million iOS users? You can write a game with fragmented performance, cross your fingers and hope it runs everywhere and try to hit the largest market possible, or, you can develop for a more predictable platform, target a smaller market, but potentially gain more revenue with less development cost. The idea that someone is going to just cross compile to asm.js and poof, the game will work everywhere is a pipe dream. This attitude is likely to draw public ire and bad reviews as people who happen to have VMs which won't optimize it as good as Firefox, get unpredictably bad performance. It's Android fragmentation made even worse. The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox, and native C/C++ on Android NDK or iOS, and you're going to have to maintain and certify four different versions in order to get best experience. Not much different than trying to target a PS3, XB360, and Wii with a multiplatform title. If you look at modern game platforms, both on mobile, and on console/desktop, they are leveraging not just GPUs, but multi-core CPUs. If you look at Ars's evaluation of asm.js (http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/3/ http://arstechnica.com/information-technology/2013/05/native...) lack of SIMD and multi-threading is a huge performance hit. SIMD can be fixed (e.g. what Dart did), but shared memory model in JS with concurrency primitives would be a radical change to the semantics of JS, so I don't see it happening. In short, it's a nice dream that you can write once and run everywhere high performance JS, the reality is, it isn't going to help major game developers and they will still need per-browser, per-platform extensive testing and tuning. End users don't care. When I buy a game from a store, I expect it to run at 30fps with no janks minimally. This is one reason why iOS and consoles extract great performance from platforms that have lower specs than competitors, because a fixed target offers more opportunities for optimization. I love the idea of write once run anywhere, but I think it's the wrong model for high performance cpu hungry games where you want to maximize overall system performance.
dragonwriter 13y ago
The key premise of this article is unsubstantiated by the provided link. The article states, "Unfortunately, Google has recently announced that they will expose Portable Native Client (PNaCl) --- and by extension, the Pepper APIs --- to all Web pages"; all the article's complaints are based on this description and the assumption that it will be exposed to all web pages without first being standardized. But this claim is misleading; the closest the announcement page that is linked from the article [1] comes to supporting it is saying "Once PNaCl is fully released, users will be able to run PNaCl modules on any web page". It does not state an intent to transition PNaCl to this "fully released" state at any particular time in the future, or without standardization. [1] https://developers.google.com/native-client/announcements https://developers.google.com/native-client/announcements (the relevant announcement is the May 15, 2013)
- azakai 13y ago
  Google's announcement says > Once PNaCl is fully released, users will be able to run PNaCl modules on any web page – applications will not need to be deployed through the Chrome Web Store in order to run PNaCl modules. NaCl has always been enabled only in the Store, and not on the web, while the news in that announcement is that it will be enabled on the web. If you still think that isn't clear, watch the recent Google IO PNaCl talk, where this is stated as well, http://www.youtube.com/watch?v=5RFjOec-TI0 http://www.youtube.com/watch?v=5RFjOec-TI0 If somehow there is a misunderstanding of the intent of both announcements, then I hope Google will clarify that.
  - munificent 13y ago
    In case you're curious, the relevant bit is around here: http://www.youtube.com/watch?v=5RFjOec-TI0&feature=player_detailpage#t=2037s http://www.youtube.com/watch?v=5RFjOec-TI0&feature=playe.... "It's in Chrome 29 canary now, hopefully dev channel within a few days. We're shooting for Chrome 30 as our launch."
  - dragonwriter 13y ago
    > NaCl has always been enabled only in the Store, and not on the web, while the news in that announcement is that it will be enabled on the web. ...when PNaCl is fully released. Which is what they've said for years, that they weren't turning any Native Client on for the web until PNaCl was ready to be "fully released". So that wasn't actually the news. The actual news was the announcement that PNaCl execution is supported (not that PNaCl will be "fully released") from Chrome 29, which was, at the time, the Canary version of Chrome (its since moved to the Dev channel.) Prior to Chrome 29, the only way to run PNaCl code -- or rather, code that had been generated by the PNaCl toolchain -- in the browser was to run it through another tool which generated regular, architecture-specific NaCl code.
RRRA 13y ago
Is it only being developped as the native side for Chrome OS or is it really planned as a all around web binary running thingie? The issue being, nobody should be developing anything for it publicly until at least 2 competing implementation have been created. But people don't seem to care about that for some reason...
- wmf 13y ago
  There aren't two competing implementations of Flash or iOS, but some people made millions developing on those platforms.
programminggeek 13y ago
How is NaCL support any different than allowing Java Applets on a page, or Flash, or Silverlight?
- wmf 13y ago
  Java, Flash, and Silverlight were NPAPI plugins that could work in multiple browsers. NaCl uses PPAPI that's only supported in Chrome.
  - greggman 13y ago
    Here, Let me fix that for you Java, Flash, and Silverlight were insecure platform specific NPAPI plugins that make it easy to p0wn users machines. PNaCl uses PPAPI that together are designed from the ground up to be portable and secure. PPAPI provides the only APIs NaCL apps can call. They are cross platform so you write 1 plugin and it runs on Linux/OSX/Windows. Compare to NPAPI where the plugin has to be custom for each platform and calls into the OS directly unrestricted.
    - jimbobimbo 13y ago
      Actually, Silverlight is a pretty secure platform: out of 10 listed [1] vulnerabilities only 7 execute code and 2 gain admin access on the machine. Here's how Flash player looks like: [2] And here's Chrome's track of record: [3] (unfortunately, there's no good way to filter out NaCl defects) [1] http://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-19887/Microsoft-Silverlight.html http://www.cvedetails.com/vulnerability-list/vendor_id-26/pr... [2] http://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html http://www.cvedetails.com/vulnerability-list/vendor_id-53/pr... [3] http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 http://www.cvedetails.com/product/15031/Google-Chrome.html?v...
zobzu 13y ago
We're deep in the extend phase and start to see some extinguish attempts.
- PommeDeTerre 13y ago
  Extinguishing JavaScript would actually be a very beneficial thing to do. It's quite refreshing to see Google trying to offer a viable alternative that's far more general in nature, and far more technologically-sound than its competitors. This contrasts heavily with what Mozilla is trying to do with asm.js. Their approach, unfortunately, is nothing more than an atrocious hack. Instead of doing things properly, they just maul JavaScript into a form that isn't as horrible to work with, from an optimization standpoint. However, this is clearly inferior to using a proper instruction set, bytecode, or intermediate representation. The worst part, though, is that asm.js further entrenches JavaScript. This is going in the opposite direction of where we ought to be going. We need browsers that offer a far more general runtime. JavaScript would merely be one among many other languages targeting such a runtime, rather than being an integral part of it like we see with asm.js.

94 points by thristian 13y ago

pjmlp 13y ago

IE is dead, God save Chrome!

tim_hutton 13y ago

Does NaCl/PNaCl have a future now we've seen what Emscripten/ASM.js can do?

dochtman 13y ago
It certainly seems unlikely, but I guess it depends on how fast asm.js can get.
- tim_hutton 13y ago
  Now only 1.3x slower than native on one large-ish benchmark (box2d): http://youtu.be/qrf9ONmtXbM http://youtu.be/qrf9ONmtXbM (I love the comparison he makes to evolution at the end. Yes, the process may give ugly creatures sometimes but they work.)
  - cromwellian 13y ago
    Unless you have a system with 4-8 cores and SIMD, and you want to leave a multiple of performance on the table: http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/3/ http://arstechnica.com/information-technology/2013/05/native... For example, 1200% slower in Mandelbrot rendering with asm.js vs OpenMP C code.
notatoad 13y ago
it has a future as long as firefox is the only implementor of asm.js and chrome/ium is the only implementor of PNaCl.
dragonwriter 13y ago
> Does NaCl/PNaCl have a future now we've seen what Emscripten/ASM.js can do? Possibly not; Google certainly likes the things they come up with, but it wouldn't be the first time that they spent lots of effort behind one approach but switched to back another approach that solved the same problem that others championed because it was better positioned for standardization; Google's interest in native-like performance on the web are more about the functionality than the mechanism.

micro_cam 13y ago

Am I the only one who feels like locking into a standard for something like this without first developing and testing an implementation would be a mistake?

wmf 13y ago
There is a process for that: You prototype the feature under an off-by-default feature flag, then standardize it, then turn it on by default. Apparently Chrome follows this process for HTML/CSS features but not for PNaCl or DRM.
- dragonwriter 13y ago
  > You prototype the feature under an off-by-default feature flag Both NaCl and PNaCl, except for Chrome Web Store content, are under an off-by-default feature flag. > then standardize it, then turn it on by default. Apparently Chrome follows this process for HTML/CSS features but not for PNaCl or DRM. Except that there is nothing but speculation, at least nothing cited in the source article, supporting the idea that Google isn't following that path with PNaCl.

lucian1900 13y ago

Asm.js is no more an open standard than PNaCl. While I'm sure others disagree, PNaCl is much cleaner in design and with more predictable performance. It's the one I'd like to see win.

LamaOfRuin 13y ago
Not really the same. Anything that implements standard javascript will be able to run asm.js code just fine, even if they don't implement the possible optimizations. The same isn't true for NaCL.
- lucian1900 13y ago
  But it'll be too slow to be useful for anything, so it's not quite so different.
  - jacobparker 13y ago
    That is not true. The unreal demo is usable even without the asm.js optimizations.
    - migueldeicaza 13y ago
      Just tried it on my iPhone, and it crashed.
      - jacobparker 13y ago
        I know for certain that there are previous non-asm.js optimized builds of Firefox that run it fine (with a performance penalty, naturally.) Chrome currently crashes because Chrome can't handle enough variables per context. This is a bug with V8 that is allegedly getting fixed. It wouldn't surprise me if mobile support is currently minimal to none though; but this is something that can and almost surely will change independent of asm.js optimization support. (And this is the Unreal demo specifically - smaller projects should be supported by virtually any modern browser* as far as I know.) * Caveats: IE doesn't support WebGL, etc.

cromwellian 13y ago

NaCL was already part of Chromium prior to Blink, I hardly see the huge difference between NaCL and PNaCl in this regard. Besides that, Blink is the rendering engine, Blink != Chrome. To get Chrome, you have to add in V8, NaCL, codecs, and a bunch of other stuff. I see the promises to which Blink commits itself as being disjoint from Chrome. After all, there are lots of Chrome-only APIs, like Chrome extensions, Chrome sync, Chrome packaged apps, etc.

espadrine 13y ago
It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong?
- dragonwriter 13y ago
  > It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong? Part of the incentive to fork was to avoid having to maintain support for multiple JS engines in the core project. I don't think that means that Blink requires V8 so much as that Blink's support for JS engines (compared to pre-split WebKit's) no longer includes explicit support for the engine used by Safari (whose name I can't remember) as part of the source tree, and presumably will over time be more tightly adapted to the needs of V8. This would seem to mean it will progressively become more difficult to build a Blink-based browser using a different JS engine.
  - cpleppert 13y ago
    They intend to tie V8 and the Dom deeper in the next versions of Chrome by using a new garbage collector. I'm pretty sure it will be well nigh impossible to use another Javascript engine.
pcwalton 13y ago
NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl is going to be enabled for Web content.

VikingCoder 13y ago

Do we know for sure that Blink itself needs to support PNaCL / Pepper? Or is it possible that PNaCL and Pepper can be implemented on top of Blink? Do we know for sure that Blink itself is violating any of these principles, to merely expose PNaCL / Pepper in Chrome?

espadrine 13y ago

What matters to me as a developer is this: will there be more compilers targeting PNaCl, or asm.js? Otherwise said, as a compiler writer, would you rather write a compiler that works in all browsers, and which needs no tools because of how simple the output is, or a compiler which targets just one browser, with a complex output to target?

cromwellian 13y ago
If you are a game developer, it doesn't much matter. Do you target a market of 500+ million Chrome users, or 2 billion web users, or 900 million Android users, or 500 million iOS users? You can write a game with fragmented performance, cross your fingers and hope it runs everywhere and try to hit the largest market possible, or, you can develop for a more predictable platform, target a smaller market, but potentially gain more revenue with less development cost. The idea that someone is going to just cross compile to asm.js and poof, the game will work everywhere is a pipe dream. This attitude is likely to draw public ire and bad reviews as people who happen to have VMs which won't optimize it as good as Firefox, get unpredictably bad performance. It's Android fragmentation made even worse. The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox, and native C/C++ on Android NDK or iOS, and you're going to have to maintain and certify four different versions in order to get best experience. Not much different than trying to target a PS3, XB360, and Wii with a multiplatform title. If you look at modern game platforms, both on mobile, and on console/desktop, they are leveraging not just GPUs, but multi-core CPUs. If you look at Ars's evaluation of asm.js (http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/3/ http://arstechnica.com/information-technology/2013/05/native...) lack of SIMD and multi-threading is a huge performance hit. SIMD can be fixed (e.g. what Dart did), but shared memory model in JS with concurrency primitives would be a radical change to the semantics of JS, so I don't see it happening. In short, it's a nice dream that you can write once and run everywhere high performance JS, the reality is, it isn't going to help major game developers and they will still need per-browser, per-platform extensive testing and tuning. End users don't care. When I buy a game from a store, I expect it to run at 30fps with no janks minimally. This is one reason why iOS and consoles extract great performance from platforms that have lower specs than competitors, because a fixed target offers more opportunities for optimization. I love the idea of write once run anywhere, but I think it's the wrong model for high performance cpu hungry games where you want to maximize overall system performance.

dragonwriter 13y ago

The key premise of this article is unsubstantiated by the provided link. The article states, "Unfortunately, Google has recently announced that they will expose Portable Native Client (PNaCl) --- and by extension, the Pepper APIs --- to all Web pages"; all the article's complaints are based on this description and the assumption that it will be exposed to all web pages without first being standardized. But this claim is misleading; the closest the announcement page that is linked from the article [1] comes to supporting it is saying "Once PNaCl is fully released, users will be able to run PNaCl modules on any web page". It does not state an intent to transition PNaCl to this "fully released" state at any particular time in the future, or without standardization. [1] https://developers.google.com/native-client/announcements https://developers.google.com/native-client/announcements (the relevant announcement is the May 15, 2013)

azakai 13y ago
Google's announcement says > Once PNaCl is fully released, users will be able to run PNaCl modules on any web page – applications will not need to be deployed through the Chrome Web Store in order to run PNaCl modules. NaCl has always been enabled only in the Store, and not on the web, while the news in that announcement is that it will be enabled on the web. If you still think that isn't clear, watch the recent Google IO PNaCl talk, where this is stated as well, http://www.youtube.com/watch?v=5RFjOec-TI0 http://www.youtube.com/watch?v=5RFjOec-TI0 If somehow there is a misunderstanding of the intent of both announcements, then I hope Google will clarify that.
- munificent 13y ago
  In case you're curious, the relevant bit is around here: http://www.youtube.com/watch?v=5RFjOec-TI0&feature=player_detailpage#t=2037s http://www.youtube.com/watch?v=5RFjOec-TI0&feature=playe.... "It's in Chrome 29 canary now, hopefully dev channel within a few days. We're shooting for Chrome 30 as our launch."
- dragonwriter 13y ago
  > NaCl has always been enabled only in the Store, and not on the web, while the news in that announcement is that it will be enabled on the web. ...when PNaCl is fully released. Which is what they've said for years, that they weren't turning any Native Client on for the web until PNaCl was ready to be "fully released". So that wasn't actually the news. The actual news was the announcement that PNaCl execution is supported (not that PNaCl will be "fully released") from Chrome 29, which was, at the time, the Canary version of Chrome (its since moved to the Dev channel.) Prior to Chrome 29, the only way to run PNaCl code -- or rather, code that had been generated by the PNaCl toolchain -- in the browser was to run it through another tool which generated regular, architecture-specific NaCl code.

RRRA 13y ago

Is it only being developped as the native side for Chrome OS or is it really planned as a all around web binary running thingie? The issue being, nobody should be developing anything for it publicly until at least 2 competing implementation have been created. But people don't seem to care about that for some reason...

wmf 13y ago
There aren't two competing implementations of Flash or iOS, but some people made millions developing on those platforms.

programminggeek 13y ago

How is NaCL support any different than allowing Java Applets on a page, or Flash, or Silverlight?

wmf 13y ago
Java, Flash, and Silverlight were NPAPI plugins that could work in multiple browsers. NaCl uses PPAPI that's only supported in Chrome.
- greggman 13y ago
  Here, Let me fix that for you Java, Flash, and Silverlight were insecure platform specific NPAPI plugins that make it easy to p0wn users machines. PNaCl uses PPAPI that together are designed from the ground up to be portable and secure. PPAPI provides the only APIs NaCL apps can call. They are cross platform so you write 1 plugin and it runs on Linux/OSX/Windows. Compare to NPAPI where the plugin has to be custom for each platform and calls into the OS directly unrestricted.
  - jimbobimbo 13y ago
    Actually, Silverlight is a pretty secure platform: out of 10 listed [1] vulnerabilities only 7 execute code and 2 gain admin access on the machine. Here's how Flash player looks like: [2] And here's Chrome's track of record: [3] (unfortunately, there's no good way to filter out NaCl defects) [1] http://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-19887/Microsoft-Silverlight.html http://www.cvedetails.com/vulnerability-list/vendor_id-26/pr... [2] http://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html http://www.cvedetails.com/vulnerability-list/vendor_id-53/pr... [3] http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 http://www.cvedetails.com/product/15031/Google-Chrome.html?v...

zobzu 13y ago

We're deep in the extend phase and start to see some extinguish attempts.

PommeDeTerre 13y ago
Extinguishing JavaScript would actually be a very beneficial thing to do. It's quite refreshing to see Google trying to offer a viable alternative that's far more general in nature, and far more technologically-sound than its competitors. This contrasts heavily with what Mozilla is trying to do with asm.js. Their approach, unfortunately, is nothing more than an atrocious hack. Instead of doing things properly, they just maul JavaScript into a form that isn't as horrible to work with, from an optimization standpoint. However, this is clearly inferior to using a proper instruction set, bytecode, or intermediate representation. The worst part, though, is that asm.js further entrenches JavaScript. This is going in the opposite direction of where we ought to be going. We need browsers that offer a far more general runtime. JavaScript would merely be one among many other languages targeting such a runtime, rather than being an integral part of it like we see with asm.js.