5 ms·

I'm of two minds about WASM. There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in mo

I'm of two minds about WASM. There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it. The other side of that, then, is the great potential for interop that Javascript offers. We now have a worldwide platform with a built-in presentation layer and a highly-optimized interpreter with useful, reflectable data structures out of the box. (edit i.e. it's a viable platform for metaprogramming... the endgame of which is JS-in-JS (see "prepack")). I would love to see a future in which the browser (and "personal" computer generally) remained a locus of significant computation. In practice, I suspect that highly-intensive tasks (mostly AI stuff) will continue to be done on servers, not because we lack the processing power, but because end users will have signed away the custody of all data worth processing. If that is the case, then WASM's role will be to fill a fairly marginal gap, between what JS can do, and what has to be farmed out anyway. So ultimately I hope that WASM offers a lifeline to the computing power that individuals still have. But given the state of JS (after huge investments), it feels like starting over again.

throwasehasdwi 9y ago
Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly demands more features and faster execution. The only logical conclusion is that the web browser will become an operating system.
- monkmartinez 9y ago
  I wholeheartedly agree with your statements. I think there are a legion of developers who would love to program for the web, but refuse to learn|use and simply can not keep up with JS. The browser is one of the only truly cross platform development environments around. The popularity of the browser is directly coupled to that fact in my opinion. How many developers|companies and organizations would be over the moon excited with hiring a Python|Ruby|Lua|Rust|C# developer that could talk natively to the browser? My guess is a LOT.
  - pfooti 9y ago
    On the one hand, I hear you and don't disagree - programming ergonomics is a big deal, and access to the language you like is important. I for one really don't want to program in a language that uses significant whitespace, if I can avoid it. On the other hand, "keep up with JS" is something of a misnomer here. It's not javascript that's moving super-fast, it's the web ecosystem (plus the node one, in parallel). It's moving fast because new ideas are evolving at speed (functional-reactive approaches, new ways to think about mixins vs multiple inheritance, etc), and those ideas lead to new framework architectures gaining popularity as they exploit these new ways of thinking about organizing data flow through a complicated system. Couple that with some baseline things that aren't changing here - you're still going to have to interact with the DOM, you aren't going to magically get re-entrant multithreading, and the event model isn't changing. There's still going to be a lot about web programming that feels different from systems programming, and things are still going to move quickly. Probably even more quickly (but I'm not certain about that - I imagine one major reason JS shifts quickly is that it has so many programmers working with it, if the population fragments there will probably be a number of slow-moving communities that neither shift often nor take advantage of new features, which feels like the kind of neophile - neophobe split that's already apparent in different areas of programming). So: I am not convinced that a (say) rust or go compiler to WASM will suddenly make front-end programming feel like systems programming. It'll be a new language, sure, but there's a lot more to web development and the (reasonable) complaints people have about a shifting landscape than just javascript and its funky definition of OO and triple equals sign.
    - monkmartinez 9y ago
      I am not sure I am qualified to really debate the merits of the JS ecosystem; perceived or real at this time. I tried to do front-end stuff when Knockout and Backbone were popular and Node was just starting. Maybe a better phrase is; I had a hard time keeping up... it was the paradigm changes (as you mentioned), but it was also the volume. Paralyzation due to choice and only so much time to evaluate each framework. Couple that to "staying" power, that is, will this library be around in 6 months? I have taken a peek from time to time and been thoroughly aghast at the volume and not really seeing any of the old stand-bys around. Now compare that to Python. There is no dearth of choice and one will find many of these choices have been around for more than a decade. They have evolved and changed of course, but not anywhere near the pace of JS. Again, I could take a 3 to 6 month break from looking at Python news and libraries... then come back and jump right into most of the libs I already know. Can a JS dev do that? > Couple that with some baseline things that aren't changing here Doesn't webASM give the power to abstract those things away? React creates a virtual DOM, right? Why can't Python create a virtual DOM via webASM? I stand with you in that I agree things are going to move quickly once Python and others become peers with JS in the browser. I am sure it will be insane as everyone figures out which lib will have staying power like Django, or similar in another lang. I do think that people who generally gravitate toward languages like Python, Go, C#, Java will bring those attitudes with them... that is, they aren't going to re-invent the wheel every three months unless there is a super compelling reason to do so.
- copperx 9y ago
  I agree, but at the same time I look at the Webassembly web page, and they explicitly state that replacing Javascript is not their objective. Why is that?
  - JBiserkov 9y ago
    So the next generation can't have nice things either :). It seems to me that the history of computing so far can be summarized as "due to popular demand, things have been used far outside their creator's intended scope, with 3-4 non-horrible results". (Lisp is definitely one, can't think of another on the top of my head).
    - devrandomguy 9y ago
      If only we had used Lisps for all the things! We could have had Lisp instead of JS, but no, that would have worked too well; management wants Java. We almost had a Scheme instead of CSS: DSSSL, which could also do structural transformations of the document tree. But once again, no. The simplicity multiplied by the flexibility of a Lisp, equaled unacceptable complexity, for some strange definition of complexity. XML looks like it really, really wanted to be a Lisp, what with its orderly nesting of tags. I almost wonder if XML stumbled and fell, due to the supporting pillars of parens being knocked out or corrupted, left, right and center.
  - mtvrandom 9y ago
    <excessive snark deleted>
  - wotamRobin 9y ago
    To make an analogy, right now it's possible to write and include C++ modules in your Python scripts, just like it's possible to do with WASM/JS. But people still use Python, because it's a much faster/easier way to get a specific kind of thing done. So WASM is a great tool, but not a good choice for building something like HN, where perf isn't an issue. Iteration speed, debuggability, and the GC make HTML/CSS/JS a better choice here.
  - throwasehasdwi 9y ago
- thaumasiotes 9y ago
  Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?
  - jimmaswell 9y ago
    Java applets were unfortunately ahead of their time for the hardware available and got a bad reputation for being slow, along with security problems, and now that Google extinguished plugins like Java and Flash (Google gets to skip the Extend step) we're stuck with whatever Chrome lets webasm do with no competition for this kind of VM-in-a-browser. The homogenization Google forced on the web is a travesty but everybody is too distracted by shiny new HTML5 features and the anti-plugin bandwagon to care.
  - khedoros1 9y ago
    I'd assume something like the conceptual difference between HTML5 canvas/video ("good") and Flash ("bad"). No plugins. Better sandboxing. Open specification not owned by some specific company. An expectation of multiple competing implementations. Basically, it's a lot of the same stuff, but a (hopefully) better implementation, and promoted in a way that appeals to the people likely to use it. Start with an old technology. Tweak, relabel, and market under the new name.
  - Rusky 9y ago
    Java applets have a radically different security model from Javascript and wasm. There's only thing that makes wasm any closer to Java applets than Javascript already is- it's distributed as a bytecode that's not dynamically typed, rather than text. But Javascript's dynamically typed textual representation has nothing to do with what makes it better than Java applets. It's the security model, which wasm shares.
    - thaumasiotes 9y ago
      Wouldn't it be easier to change the security model on Java applets than to go through whatever the process of developing wasm is?
- gavinpc 9y ago
  People could be perfectly happy with today's performance levels (or tomorrow's, or yesterday's) if the prevailing systems were designed to serve and empower them, rather than to exploit them. The market wants people to want "more features and faster execution." The market doesn't care what it's selling per se. If the web-browser-as-OS seems like an inevitability in that context, it's only a side-effect, and one that could change at any time. WASM also impacts the labor market, as you mention. But it's not, as we might like to believe, because programmers' demands for more freedom and expressive power are being honored; it's because, as monkmartinez suggests [0] (and maybe this is what you mean by "floodgates"), companies would rather not be limited to a smaller human-resource pool when developing web properties. If I sound a little dystopian, it might be because I'm currently reading Cyber-Marx [1], an insightful book from 1999 about the "information revolution" and its relation to capital. [0] https://news.ycombinator.com/item?id=14342983 https://news.ycombinator.com/item?id=14342983 [1] http://www.press.uillinois.edu/books/catalog/66mwg3pc9780252067952.html http://www.press.uillinois.edu/books/catalog/66mwg3pc9780252...
  - andrewflnr 9y ago
    I'm a little confused by this comment. Are you saying it would be better for the world if companies were limited to a "smaller human-resource pool"? Does anyone besides JS devs benefit from that scenario?
    - monkmartinez 9y ago
      Me too, but I am drawing a different conclusion. Perhaps he/she means that companies ultimately drive the market forward as it were. I mean, most people do not strictly trade time/effort for no reward. Reward can mean different things for different people, but I would tend to land on most people trade labor for money. Companies invest in tools all the time, especially internet companies. They would have the bigger reason to get behind efforts that increase the share of developers available.
      - gavinpc 9y ago
        Yes, I'm saying that this would not move forward without buy-in from non-programmers with influence. But language isn't the only thing. WASM is (correct me if I'm wrong) harder to reverse engineer, which must matter to those same stakeholders.
- rustyhacker 9y ago
  I'm not entirely convinced that the reason why people aren't using their preferred language is due to the absence of WASM up until now. Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web. I think the reasons why programmers aren't using their preference when coding for web is, firstly because of the lack industry approval/support and secondly the speed of development. As much I complain about writing js code, it's a lot faster to get things done compared to Rust/C++.
  - flukus 9y ago
    > Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web. Because transpilers are an incredibly leaky abstraction. You have to know your language, the language you're transpiling to and quite often you need to know about how that translation occurs. That's before you even get into the idiomatic differences between languages and libraries.
  - throwasehasdwi 9y ago
    You might be right about C++/Rust but I hear constant complaints from C#, Java, and Go devs about JS. It feels like about half of them would jump ship immediately given another choice. The truth is that even with all the advancements JS has made the tooling and features are still years behind some other mainstream languages. The transpilers don't work that great and don't produce standard bytecode, in this regard WASM will be a game changer.
  - derefr 9y ago
    Alternate hypothesis: at least as of right now†, Web Workers still don't support thread-like behavior. If I wanted to program e.g. a game in C++ or Python, I'd be pulling in an engine and some libraries that all expect to have threads available. This code would not transpile. You can write a native app in pretty much any language that can sit on top of the current web stack—but from the perspective of most programming languages, the result is very non-idiomatic code. Not only do you have to avoid consuming most of the library ecosystem of your language; you also have to code in the "Javascript style", with co-operatively scheduled async tasks running in a single execution-thread context (plus maybe some memory-isolated "secondary process"-like execution-threads you have to do message-passing IPC against) in order to make your native code "work" in a web browser after transpilation. If we clear that hurdle, using arbitrary languages for the web will be a lot easier, and you'll see far more porting of native apps to the web. † https://kripken.github.io/emscripten-site/docs/porting/pthreads.html https://kripken.github.io/emscripten-site/docs/porting/pthre...
- wotamRobin 9y ago
  At the very least, browsers are the new JRE.
- moosingin3space 9y ago
  I'm very interested in the possibility of using a WASM VM as a unit of process isolation in an operating system. I actually kind of like Babel-compiled JavaScript, so I'm not as interested in WASM as a way to "get away from JavaScript", but the VM-based containerization possibilities (maybe with hardware-assist) are very cool. Looks like Docker/Unikernel Systems actually has plans to build something like this: https://github.com/linuxkit/linuxkit/tree/master/projects/miragesdk https://github.com/linuxkit/linuxkit/tree/master/projects/mi...

throwasehasdwi 9y ago

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly demands more features and faster execution. The only logical conclusion is that the web browser will become an operating system.

monkmartinez 9y ago
I wholeheartedly agree with your statements. I think there are a legion of developers who would love to program for the web, but refuse to learn|use and simply can not keep up with JS. The browser is one of the only truly cross platform development environments around. The popularity of the browser is directly coupled to that fact in my opinion. How many developers|companies and organizations would be over the moon excited with hiring a Python|Ruby|Lua|Rust|C# developer that could talk natively to the browser? My guess is a LOT.
- pfooti 9y ago
  On the one hand, I hear you and don't disagree - programming ergonomics is a big deal, and access to the language you like is important. I for one really don't want to program in a language that uses significant whitespace, if I can avoid it. On the other hand, "keep up with JS" is something of a misnomer here. It's not javascript that's moving super-fast, it's the web ecosystem (plus the node one, in parallel). It's moving fast because new ideas are evolving at speed (functional-reactive approaches, new ways to think about mixins vs multiple inheritance, etc), and those ideas lead to new framework architectures gaining popularity as they exploit these new ways of thinking about organizing data flow through a complicated system. Couple that with some baseline things that aren't changing here - you're still going to have to interact with the DOM, you aren't going to magically get re-entrant multithreading, and the event model isn't changing. There's still going to be a lot about web programming that feels different from systems programming, and things are still going to move quickly. Probably even more quickly (but I'm not certain about that - I imagine one major reason JS shifts quickly is that it has so many programmers working with it, if the population fragments there will probably be a number of slow-moving communities that neither shift often nor take advantage of new features, which feels like the kind of neophile - neophobe split that's already apparent in different areas of programming). So: I am not convinced that a (say) rust or go compiler to WASM will suddenly make front-end programming feel like systems programming. It'll be a new language, sure, but there's a lot more to web development and the (reasonable) complaints people have about a shifting landscape than just javascript and its funky definition of OO and triple equals sign.
  - monkmartinez 9y ago
    I am not sure I am qualified to really debate the merits of the JS ecosystem; perceived or real at this time. I tried to do front-end stuff when Knockout and Backbone were popular and Node was just starting. Maybe a better phrase is; I had a hard time keeping up... it was the paradigm changes (as you mentioned), but it was also the volume. Paralyzation due to choice and only so much time to evaluate each framework. Couple that to "staying" power, that is, will this library be around in 6 months? I have taken a peek from time to time and been thoroughly aghast at the volume and not really seeing any of the old stand-bys around. Now compare that to Python. There is no dearth of choice and one will find many of these choices have been around for more than a decade. They have evolved and changed of course, but not anywhere near the pace of JS. Again, I could take a 3 to 6 month break from looking at Python news and libraries... then come back and jump right into most of the libs I already know. Can a JS dev do that? > Couple that with some baseline things that aren't changing here Doesn't webASM give the power to abstract those things away? React creates a virtual DOM, right? Why can't Python create a virtual DOM via webASM? I stand with you in that I agree things are going to move quickly once Python and others become peers with JS in the browser. I am sure it will be insane as everyone figures out which lib will have staying power like Django, or similar in another lang. I do think that people who generally gravitate toward languages like Python, Go, C#, Java will bring those attitudes with them... that is, they aren't going to re-invent the wheel every three months unless there is a super compelling reason to do so.
copperx 9y ago
I agree, but at the same time I look at the Webassembly web page, and they explicitly state that replacing Javascript is not their objective. Why is that?
- JBiserkov 9y ago
  So the next generation can't have nice things either :). It seems to me that the history of computing so far can be summarized as "due to popular demand, things have been used far outside their creator's intended scope, with 3-4 non-horrible results". (Lisp is definitely one, can't think of another on the top of my head).
  - devrandomguy 9y ago
    If only we had used Lisps for all the things! We could have had Lisp instead of JS, but no, that would have worked too well; management wants Java. We almost had a Scheme instead of CSS: DSSSL, which could also do structural transformations of the document tree. But once again, no. The simplicity multiplied by the flexibility of a Lisp, equaled unacceptable complexity, for some strange definition of complexity. XML looks like it really, really wanted to be a Lisp, what with its orderly nesting of tags. I almost wonder if XML stumbled and fell, due to the supporting pillars of parens being knocked out or corrupted, left, right and center.
- mtvrandom 9y ago
  <excessive snark deleted>
- wotamRobin 9y ago
  To make an analogy, right now it's possible to write and include C++ modules in your Python scripts, just like it's possible to do with WASM/JS. But people still use Python, because it's a much faster/easier way to get a specific kind of thing done. So WASM is a great tool, but not a good choice for building something like HN, where perf isn't an issue. Iteration speed, debuggability, and the GC make HTML/CSS/JS a better choice here.
- throwasehasdwi 9y ago
thaumasiotes 9y ago
Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?
- jimmaswell 9y ago
  Java applets were unfortunately ahead of their time for the hardware available and got a bad reputation for being slow, along with security problems, and now that Google extinguished plugins like Java and Flash (Google gets to skip the Extend step) we're stuck with whatever Chrome lets webasm do with no competition for this kind of VM-in-a-browser. The homogenization Google forced on the web is a travesty but everybody is too distracted by shiny new HTML5 features and the anti-plugin bandwagon to care.
- khedoros1 9y ago
  I'd assume something like the conceptual difference between HTML5 canvas/video ("good") and Flash ("bad"). No plugins. Better sandboxing. Open specification not owned by some specific company. An expectation of multiple competing implementations. Basically, it's a lot of the same stuff, but a (hopefully) better implementation, and promoted in a way that appeals to the people likely to use it. Start with an old technology. Tweak, relabel, and market under the new name.
- Rusky 9y ago
  Java applets have a radically different security model from Javascript and wasm. There's only thing that makes wasm any closer to Java applets than Javascript already is- it's distributed as a bytecode that's not dynamically typed, rather than text. But Javascript's dynamically typed textual representation has nothing to do with what makes it better than Java applets. It's the security model, which wasm shares.
  - thaumasiotes 9y ago
    Wouldn't it be easier to change the security model on Java applets than to go through whatever the process of developing wasm is?
gavinpc 9y ago
People could be perfectly happy with today's performance levels (or tomorrow's, or yesterday's) if the prevailing systems were designed to serve and empower them, rather than to exploit them. The market wants people to want "more features and faster execution." The market doesn't care what it's selling per se. If the web-browser-as-OS seems like an inevitability in that context, it's only a side-effect, and one that could change at any time. WASM also impacts the labor market, as you mention. But it's not, as we might like to believe, because programmers' demands for more freedom and expressive power are being honored; it's because, as monkmartinez suggests [0] (and maybe this is what you mean by "floodgates"), companies would rather not be limited to a smaller human-resource pool when developing web properties. If I sound a little dystopian, it might be because I'm currently reading Cyber-Marx [1], an insightful book from 1999 about the "information revolution" and its relation to capital. [0] https://news.ycombinator.com/item?id=14342983 https://news.ycombinator.com/item?id=14342983 [1] http://www.press.uillinois.edu/books/catalog/66mwg3pc9780252067952.html http://www.press.uillinois.edu/books/catalog/66mwg3pc9780252...
- andrewflnr 9y ago
  I'm a little confused by this comment. Are you saying it would be better for the world if companies were limited to a "smaller human-resource pool"? Does anyone besides JS devs benefit from that scenario?
  - monkmartinez 9y ago
    Me too, but I am drawing a different conclusion. Perhaps he/she means that companies ultimately drive the market forward as it were. I mean, most people do not strictly trade time/effort for no reward. Reward can mean different things for different people, but I would tend to land on most people trade labor for money. Companies invest in tools all the time, especially internet companies. They would have the bigger reason to get behind efforts that increase the share of developers available.
    - gavinpc 9y ago
      Yes, I'm saying that this would not move forward without buy-in from non-programmers with influence. But language isn't the only thing. WASM is (correct me if I'm wrong) harder to reverse engineer, which must matter to those same stakeholders.
rustyhacker 9y ago
I'm not entirely convinced that the reason why people aren't using their preferred language is due to the absence of WASM up until now. Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web. I think the reasons why programmers aren't using their preference when coding for web is, firstly because of the lack industry approval/support and secondly the speed of development. As much I complain about writing js code, it's a lot faster to get things done compared to Rust/C++.
- flukus 9y ago
  > Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web. Because transpilers are an incredibly leaky abstraction. You have to know your language, the language you're transpiling to and quite often you need to know about how that translation occurs. That's before you even get into the idiomatic differences between languages and libraries.
- throwasehasdwi 9y ago
  You might be right about C++/Rust but I hear constant complaints from C#, Java, and Go devs about JS. It feels like about half of them would jump ship immediately given another choice. The truth is that even with all the advancements JS has made the tooling and features are still years behind some other mainstream languages. The transpilers don't work that great and don't produce standard bytecode, in this regard WASM will be a game changer.
- derefr 9y ago
  Alternate hypothesis: at least as of right now†, Web Workers still don't support thread-like behavior. If I wanted to program e.g. a game in C++ or Python, I'd be pulling in an engine and some libraries that all expect to have threads available. This code would not transpile. You can write a native app in pretty much any language that can sit on top of the current web stack—but from the perspective of most programming languages, the result is very non-idiomatic code. Not only do you have to avoid consuming most of the library ecosystem of your language; you also have to code in the "Javascript style", with co-operatively scheduled async tasks running in a single execution-thread context (plus maybe some memory-isolated "secondary process"-like execution-threads you have to do message-passing IPC against) in order to make your native code "work" in a web browser after transpilation. If we clear that hurdle, using arbitrary languages for the web will be a lot easier, and you'll see far more porting of native apps to the web. † https://kripken.github.io/emscripten-site/docs/porting/pthreads.html https://kripken.github.io/emscripten-site/docs/porting/pthre...
wotamRobin 9y ago
At the very least, browsers are the new JRE.
moosingin3space 9y ago
I'm very interested in the possibility of using a WASM VM as a unit of process isolation in an operating system. I actually kind of like Babel-compiled JavaScript, so I'm not as interested in WASM as a way to "get away from JavaScript", but the VM-based containerization possibilities (maybe with hardware-assist) are very cool. Looks like Docker/Unikernel Systems actually has plans to build something like this: https://github.com/linuxkit/linuxkit/tree/master/projects/miragesdk https://github.com/linuxkit/linuxkit/tree/master/projects/mi...