5 ms·

He makes a solid point regarding polyfills for asm.js: if the specification is so rigorously defined, then the only fallback a current-generation browser has on

He makes a solid point regarding polyfills for asm.js: if the specification is so rigorously defined, then the only fallback a current-generation browser has on offer when encountering a "v2 asm.js" is to treat it like regular Javascript. That's a pretty nasty regression, and hopefully one that will be addressed. Regardless I still prefer building on Javascript than any proposed alternative. No matter what happens next, any pristine standard is going to look like an overextended mess even in just a few years time. So why not pick the overextended mess we started with.

niggler 14y ago
"So why not pick the overextended mess we started with." What's the starting point? Javascript or assembly? NaCl gets closer to the original starting point (which predates javascript by more than 20 years)
- hosay123 14y ago
  In the context of manipulating symbols on an infinitely long piece of tape, sure, but in the context of the web we don't "have" NaCl and there's sufficiently plausible technical and political resistance that we're probably never going to. At various points he talks about how a fresh byte code would address some of the issues raised, and certainly from a full time compiler engineer's perspective, some pristine representation and a handful of tree-walks are obviously going to appeal to his academic side. I just doubt any such perfectly forward-compatible ideal representation will ever exist that can cater to all camps and survive the test of time, because to my knowledge such a thing has never existed. So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS.
  - pifflesnort 14y ago
    > ... there's sufficiently plausible technical and political resistance that we're probably never going to. Resistance that you contribute to with almost every article that touches on NaCL, yes. It's self-fulfilling prophesy and a circular argument: "We can't adopt NaCL because nobody will ever adopt NaCL" -- say the people responsible for choosing whether to adopt NaCL. > So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS. Why is this the "inevitable" result?
    - hosay123 14y ago
      Show me a counterexample, that's all I ask. I'd give all the rhetoric in the world for a single damned counterexample of a program format that's lasted since the 80s. That's what's at stake. Instead we have a company that throws specs over the wall like they're teenaged nerds that have just discovered Pascal's pack function, a company that pushed SPDY on everyone despite it relying on a draft SSL feature that got rejected at the IETF (and in the space of 2/3 years we now have three HTTP variants - and why? Because 3 years ago it shaved 1ms off a maps.google.com request). Did you even take a look at the original WebSocket spec? It worked in terms of comparing the entire start of the HTTP request using memcmp()! Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry. Not a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them.
      - niggler 14y ago
        "a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them." Based on the media hype surrounding asm.js, it really sounds like mozilla fits the description
        shardling 14y ago
        >Based on the media hype surrounding asm.js, it really sounds like mozilla fits the description Wait, what? I'm not even sure what you're trying to say here. If you seriously think Mozilla has payed for articles about themselves, you've gone off the deep end. I know that I personally became aware of asm.js because of an offhand comment Eich made on HN. I posted that link on both reddit and HN, which I guess was the start of the hype, so if you could let me know where to collect my Mozilla money I'd be obliged. :)
      - pifflesnort 14y ago
        > Show me a counterexample, that's all I ask. I'd give all the rhetoric in the world for a single damned counterexample of a program format that's lasted since the 80s. That's what's at stake. ELF was defined in the late 80s/early 90s as part of SVR4. COFF was defined as part of SVR3. Both still exist today. The JVM bytecode was defined in 1995 and has been evolved compatibly. I'm curious, though. Do you require the same longevity of web formats that were defined in the 90s? Things have changed quite a bit, and attempting to browse the modern web with a 90s browser is futile. Given that, I don't really understand what you're arguing for. > Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry. Us 'bearded old men' aren't on the web, and its only improvements like SPDY, WebSockets, and NaCL that have made me the slightest bit interested in the web as an application platform.
- bcoates 14y ago
  By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems. Also, why the false choice between asm.js and NaCl anyway? The article makes a pretty compelling case for "neither".
  - pifflesnort 14y ago
    > By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems. That's not really how NaCL works. Any instruction that can't break out of the jail can be whitelisted; this includes all versions of SSE. Additionally, PNaCL can be retargeted at as-of-yet unknown architectures. The result is that binaries would have been either shipped as PNaCL-only, or optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped, new binaries could be targeted appropriately. This seems reasonable to me; default to portability, provide an option for best-case performance.
    - pcwalton 14y ago
      How do you plan to ensure that authors test and ship working and performant PNaCl binaries if they and their users are always using the native code?
      - pifflesnort 14y ago
        How did Apple developers ship working PPC/m68k binaries? Or PPC/x86 after that, later PPC/x86/x86-64, and armv6/armv7/armv7s on the iPhone?
        pcwalton 14y ago
        Totally different. In all of those cases, the developers have access to devices that run the hardware, and they have economic incentive to target all of those devices. Whereas with your suggestion, developers ship and test native builds for all of the CPUs on the market, plus one extra "portable" version for posterity, one that no immediate customers will ever use (because they'll be using the native versions for their architecture instead). I suspect developers wouldn't even ship the portable version (too much of a pain), browsers won't optimize it (because nobody will use it), and developers won't test it (because nobody will use it). It's like saying that images are no problem for accessibility on the Web, because designers know to use alt text. Of course they know they should, but we all know what the reality is. A backup "portable" version of an app is like alt text in this way. Some developers would do the right thing; many won't, and the Web will be de facto locked in to x86 and ARM forever.
constexpr 14y ago
Ouch, that's a great point about versioning. The thing that appeals to me about asm.js is that it short-cuts the long, slow path of VM optimization and gives great performance now instead of five years down the road. Sure it's an ugly hack but that doesn't matter to your users, all they see is a much faster user experience. Now all we need is a SIMD API for JS and we can write some truly amazing apps.
- niggler 14y ago
  "it short-cuts the long, slow path of VM optimization and gives great performance now instead of five years down the road." Something tells me that, based purely on usage metrics, chrome matters more than firefox: http://stats.wikimedia.org/archive/squid_reports/2013-02/SquidReportClients.htm http://stats.wikimedia.org/archive/squid_reports/2013-02/Squ... (and pretty much every other metric according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Historical_usage_share https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Hi... )
  - Elv13 14y ago
    Thats starcounter numbers. Do you really think IE is bellow 30%? Chrome numbers are inflated.
dherman 14y ago
We've talked about versioning, and I think feature detection is probably the best approach. If the user agent publishes a list of supported asm.js features via a standard query mechanism (note that this is a feature list, not browser detection) -- e.g., ASM.SIMD === true -- then apps can negotiate content accordingly. This might entail compiling multiple versions of your codebase for various versions of asm.js, but that's an acceptable price to pay for VM evolution, IMO.

niggler 14y ago

"So why not pick the overextended mess we started with." What's the starting point? Javascript or assembly? NaCl gets closer to the original starting point (which predates javascript by more than 20 years)

hosay123 14y ago
In the context of manipulating symbols on an infinitely long piece of tape, sure, but in the context of the web we don't "have" NaCl and there's sufficiently plausible technical and political resistance that we're probably never going to. At various points he talks about how a fresh byte code would address some of the issues raised, and certainly from a full time compiler engineer's perspective, some pristine representation and a handful of tree-walks are obviously going to appeal to his academic side. I just doubt any such perfectly forward-compatible ideal representation will ever exist that can cater to all camps and survive the test of time, because to my knowledge such a thing has never existed. So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS.
- pifflesnort 14y ago
  > ... there's sufficiently plausible technical and political resistance that we're probably never going to. Resistance that you contribute to with almost every article that touches on NaCL, yes. It's self-fulfilling prophesy and a circular argument: "We can't adopt NaCL because nobody will ever adopt NaCL" -- say the people responsible for choosing whether to adopt NaCL. > So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS. Why is this the "inevitable" result?
  - hosay123 14y ago
    Show me a counterexample, that's all I ask. I'd give all the rhetoric in the world for a single damned counterexample of a program format that's lasted since the 80s. That's what's at stake. Instead we have a company that throws specs over the wall like they're teenaged nerds that have just discovered Pascal's pack function, a company that pushed SPDY on everyone despite it relying on a draft SSL feature that got rejected at the IETF (and in the space of 2/3 years we now have three HTTP variants - and why? Because 3 years ago it shaved 1ms off a maps.google.com request). Did you even take a look at the original WebSocket spec? It worked in terms of comparing the entire start of the HTTP request using memcmp()! Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry. Not a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them.
    - niggler 14y ago
      "a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them." Based on the media hype surrounding asm.js, it really sounds like mozilla fits the description
      - shardling 14y ago
        >Based on the media hype surrounding asm.js, it really sounds like mozilla fits the description Wait, what? I'm not even sure what you're trying to say here. If you seriously think Mozilla has payed for articles about themselves, you've gone off the deep end. I know that I personally became aware of asm.js because of an offhand comment Eich made on HN. I posted that link on both reddit and HN, which I guess was the start of the hype, so if you could let me know where to collect my Mozilla money I'd be obliged. :)
    - pifflesnort 14y ago
      > Show me a counterexample, that's all I ask. I'd give all the rhetoric in the world for a single damned counterexample of a program format that's lasted since the 80s. That's what's at stake. ELF was defined in the late 80s/early 90s as part of SVR4. COFF was defined as part of SVR3. Both still exist today. The JVM bytecode was defined in 1995 and has been evolved compatibly. I'm curious, though. Do you require the same longevity of web formats that were defined in the 90s? Things have changed quite a bit, and attempting to browse the modern web with a 90s browser is futile. Given that, I don't really understand what you're arguing for. > Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry. Us 'bearded old men' aren't on the web, and its only improvements like SPDY, WebSockets, and NaCL that have made me the slightest bit interested in the web as an application platform.
bcoates 14y ago
By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems. Also, why the false choice between asm.js and NaCl anyway? The article makes a pretty compelling case for "neither".
- pifflesnort 14y ago
  > By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems. That's not really how NaCL works. Any instruction that can't break out of the jail can be whitelisted; this includes all versions of SSE. Additionally, PNaCL can be retargeted at as-of-yet unknown architectures. The result is that binaries would have been either shipped as PNaCL-only, or optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped, new binaries could be targeted appropriately. This seems reasonable to me; default to portability, provide an option for best-case performance.
  - pcwalton 14y ago
    How do you plan to ensure that authors test and ship working and performant PNaCl binaries if they and their users are always using the native code?
    - pifflesnort 14y ago
      How did Apple developers ship working PPC/m68k binaries? Or PPC/x86 after that, later PPC/x86/x86-64, and armv6/armv7/armv7s on the iPhone?
      - pcwalton 14y ago
        Totally different. In all of those cases, the developers have access to devices that run the hardware, and they have economic incentive to target all of those devices. Whereas with your suggestion, developers ship and test native builds for all of the CPUs on the market, plus one extra "portable" version for posterity, one that no immediate customers will ever use (because they'll be using the native versions for their architecture instead). I suspect developers wouldn't even ship the portable version (too much of a pain), browsers won't optimize it (because nobody will use it), and developers won't test it (because nobody will use it). It's like saying that images are no problem for accessibility on the Web, because designers know to use alt text. Of course they know they should, but we all know what the reality is. A backup "portable" version of an app is like alt text in this way. Some developers would do the right thing; many won't, and the Web will be de facto locked in to x86 and ARM forever.

constexpr 14y ago

Ouch, that's a great point about versioning. The thing that appeals to me about asm.js is that it short-cuts the long, slow path of VM optimization and gives great performance now instead of five years down the road. Sure it's an ugly hack but that doesn't matter to your users, all they see is a much faster user experience. Now all we need is a SIMD API for JS and we can write some truly amazing apps.

niggler 14y ago
"it short-cuts the long, slow path of VM optimization and gives great performance now instead of five years down the road." Something tells me that, based purely on usage metrics, chrome matters more than firefox: http://stats.wikimedia.org/archive/squid_reports/2013-02/SquidReportClients.htm http://stats.wikimedia.org/archive/squid_reports/2013-02/Squ... (and pretty much every other metric according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Historical_usage_share https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Hi... )
- Elv13 14y ago
  Thats starcounter numbers. Do you really think IE is bellow 30%? Chrome numbers are inflated.

dherman 14y ago

We've talked about versioning, and I think feature detection is probably the best approach. If the user agent publishes a list of supported asm.js features via a standard query mechanism (note that this is a feature list, not browser detection) -- e.g., ASM.SIMD === true -- then apps can negotiate content accordingly. This might entail compiling multiple versions of your codebase for various versions of asm.js, but that's an acceptable price to pay for VM evolution, IMO.