4 ms·

I completely agree. I remember all the years where the prevailing wisdom was "standard web byte-code isn't necessary/feasible/desirable/etc." It's nice to rea

I completely agree. I remember all the years where the prevailing wisdom was "standard web byte-code isn't necessary/feasible/desirable/etc." It's nice to realize that such pronouncements aren't necessarily the final word. It turns out there is a way to give people the byte-code they always wanted. (btw I know WebAssembly isn't, strictly speaking, byte-code. It's a compact binary encoding of an AST. But it has all the characteristics that people really cared about when they asked for byte-code: it's a low-level representation that is a good compilation target for compiled languages)

dmix 9y ago
It might be a bit early to claim success though. We're still basically waiting for some mainstream well-regarded adoptions and use-cases. Not to say it's any less exciting in regards to it's potential. But it's important to keep expectations balanced by present outcomes.
- tyingq 9y ago
  The wasm folks will add gc, polymorphic inline cache, dom interop, some time soon. That will enable things like browser side Perl, Python, Go, Ruby, etc, without having to push the whole runtime. Nonetheless, the bloat train will resume at that point. And, the frontend will start having the same amount of fragmentation as the backend. Good news for us, though, is job security. The resulting complexity helps us, at least in one way. Web apps will be on equal footing and fragmentation as the old client/server model (vb, powerbuilder, delphi, c/x11/motif, visual c++ / mfc, dart/flutter, etc). What comes around, goes around. The cyclic nature is pretty funny.
  - jimmcslim 9y ago
    > And, the frontend will start having the same amount of fragmentation as the backend. Err, I think that boat has already sailed?... E.g. Grunt, Gulp, Webpack, make, Parcel, Brunch, Browserify, etc, etc, etc.
    - tyingq 9y ago
      As far as tooling, sure. But this will take it up a level to base language. Surely that's an exponential difference? Frontend dev won't mean what it means today.
      - ben-schaaf 9y ago
        You mean like Dart, Elm, Haxe and whatever else already compiles to javascript?
        tyingq 9y ago
        Not sure any of those have the mindshare of the languages wasm will eventually enable.
  - dmix 9y ago
    > Good news for us, though, is job security. The resulting complexity helps us, at least in one way. I don't think I despise an incentive as much as this one, even if it is a natural side-effect, not intentional. It's the reason why large and top-heavy bureaucratic organizations end up being a net-negative as a result of their structure. Despite their well intentioned attempts at 'fixing' the bumps in the road that natural free flowing systems generate, with top-down control and extreme risk management. Instead of fostering common-sense and individual talent, it creates incentives and attracts people who care more about the organization itself, and their position within it, rather than the outcomes and value creation for which the organization was originally created.
hinkley 9y ago
Every year the page weight of JavaScript creeps up. And processors aren’t outstripping gains in bandwidth the way they used to. At some point the delay between first byte and first paint becomes noteworthy and it’s no longer a wait and see game. The wasm guys may be right. Their predictions may have been accurate all along. But it may also be that we didn’t need this five years ago but we really do now.
pcwalton 9y ago
Yeah, I was one of the PNaCl naysayers. :) But wasm has different characteristics: (1) it has a forwards compatibility story because asm.js exists; (2) it's a custom IR that was designed from the ground up to not have undefined behavior; (3) it uses the Web APIs, rather than an alternate Pepper stack. Issue (1)--the forwards compatibility story--is the tricky one. Was it necessary to have asm.js as a stepping stone, or could we have gone all the way to Web Assembly from the beginning? I don't know, and we might never know, but having asm.js around for browsers that don't support wasm certainly doesn't hurt.
- haberman 9y ago
  Oh yeah, my post wasn't about PNaCl at all (I wasn't even thinking about PNaCl when I wrote it). It's very clear to me that wasm is a superior design compared to PNaCl, and I'm glad history went the way it did. :) I was talking about about the sentiment that byte-code in general isn't necessary/feasible/desirable for the web. Here are some example of the sentiment as I remember it. There was a lot of skepticism that it would be possible to design something that would be a better compilation target than JavaScript while still being fast, portable, and properly sandboxed: https://news.ycombinator.com/item?id=1893686 https://news.ycombinator.com/item?id=1893686 https://web.archive.org/web/20101126142151/http://www.aminutewithbrendan.com/pages/20101122 https://web.archive.org/web/20101126142151/http://www.aminut... https://www.infoq.com/news/2013/05/javascript-browser-bytecode https://www.infoq.com/news/2013/05/javascript-browser-byteco...
__s 9y ago
It's not a binary encoded AST anymore, it's pretty much a stack machine (with constraints like .NET which allow for easy conversion to SSA) Example: A Lua lexer, https://github.com/serprex/luwa/blob/f048aa2f67dfae00740d556cc724cea536924201/rt/_lex.lua https://github.com/serprex/luwa/blob/f048aa2f67dfae00740d556...

dmix 9y ago

It might be a bit early to claim success though. We're still basically waiting for some mainstream well-regarded adoptions and use-cases. Not to say it's any less exciting in regards to it's potential. But it's important to keep expectations balanced by present outcomes.

tyingq 9y ago
The wasm folks will add gc, polymorphic inline cache, dom interop, some time soon. That will enable things like browser side Perl, Python, Go, Ruby, etc, without having to push the whole runtime. Nonetheless, the bloat train will resume at that point. And, the frontend will start having the same amount of fragmentation as the backend. Good news for us, though, is job security. The resulting complexity helps us, at least in one way. Web apps will be on equal footing and fragmentation as the old client/server model (vb, powerbuilder, delphi, c/x11/motif, visual c++ / mfc, dart/flutter, etc). What comes around, goes around. The cyclic nature is pretty funny.
- jimmcslim 9y ago
  > And, the frontend will start having the same amount of fragmentation as the backend. Err, I think that boat has already sailed?... E.g. Grunt, Gulp, Webpack, make, Parcel, Brunch, Browserify, etc, etc, etc.
  - tyingq 9y ago
    As far as tooling, sure. But this will take it up a level to base language. Surely that's an exponential difference? Frontend dev won't mean what it means today.
    - ben-schaaf 9y ago
      You mean like Dart, Elm, Haxe and whatever else already compiles to javascript?
      - tyingq 9y ago
        Not sure any of those have the mindshare of the languages wasm will eventually enable.
- dmix 9y ago
  > Good news for us, though, is job security. The resulting complexity helps us, at least in one way. I don't think I despise an incentive as much as this one, even if it is a natural side-effect, not intentional. It's the reason why large and top-heavy bureaucratic organizations end up being a net-negative as a result of their structure. Despite their well intentioned attempts at 'fixing' the bumps in the road that natural free flowing systems generate, with top-down control and extreme risk management. Instead of fostering common-sense and individual talent, it creates incentives and attracts people who care more about the organization itself, and their position within it, rather than the outcomes and value creation for which the organization was originally created.

hinkley 9y ago

Every year the page weight of JavaScript creeps up. And processors aren’t outstripping gains in bandwidth the way they used to. At some point the delay between first byte and first paint becomes noteworthy and it’s no longer a wait and see game. The wasm guys may be right. Their predictions may have been accurate all along. But it may also be that we didn’t need this five years ago but we really do now.

pcwalton 9y ago

Yeah, I was one of the PNaCl naysayers. :) But wasm has different characteristics: (1) it has a forwards compatibility story because asm.js exists; (2) it's a custom IR that was designed from the ground up to not have undefined behavior; (3) it uses the Web APIs, rather than an alternate Pepper stack. Issue (1)--the forwards compatibility story--is the tricky one. Was it necessary to have asm.js as a stepping stone, or could we have gone all the way to Web Assembly from the beginning? I don't know, and we might never know, but having asm.js around for browsers that don't support wasm certainly doesn't hurt.

haberman 9y ago
Oh yeah, my post wasn't about PNaCl at all (I wasn't even thinking about PNaCl when I wrote it). It's very clear to me that wasm is a superior design compared to PNaCl, and I'm glad history went the way it did. :) I was talking about about the sentiment that byte-code in general isn't necessary/feasible/desirable for the web. Here are some example of the sentiment as I remember it. There was a lot of skepticism that it would be possible to design something that would be a better compilation target than JavaScript while still being fast, portable, and properly sandboxed: https://news.ycombinator.com/item?id=1893686 https://news.ycombinator.com/item?id=1893686 https://web.archive.org/web/20101126142151/http://www.aminutewithbrendan.com/pages/20101122 https://web.archive.org/web/20101126142151/http://www.aminut... https://www.infoq.com/news/2013/05/javascript-browser-bytecode https://www.infoq.com/news/2013/05/javascript-browser-byteco...

__s 9y ago

It's not a binary encoded AST anymore, it's pretty much a stack machine (with constraints like .NET which allow for easy conversion to SSA) Example: A Lua lexer, https://github.com/serprex/luwa/blob/f048aa2f67dfae00740d556cc724cea536924201/rt/_lex.lua https://github.com/serprex/luwa/blob/f048aa2f67dfae00740d556...