5 ms·

It's really uncanny how Gary Bernhardt predicted it all [0] a few years ago. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript htt

It's really uncanny how Gary Bernhardt predicted it all [0] a few years ago. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

chubot 7y ago
Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which is a CPU emulator written in JavaScript that runs the Linux kernel (using typed arrays and relying on fast JITs). That's just a way of saying that "the best way to predict the future is to invent it" (and do so before people who were "predicting" it). If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's nothing surprising about the development of wasm. It's been 10+ years in the making. And 20+ years ago Microsoft's browser had ActiveX plugins (which didn't use a VM and were really unsafe and unportable). Making a portable, sandboxed bytecode solves an obvious problem with that. Also the JVM ran in the browser, etc. [1] https://news.ycombinator.com/item?id=21618323 https://news.ycombinator.com/item?id=21618323
- vanderZwan 7y ago
  > If you knew about [x], there's nothing surprising about [y] You are technically correct, but at the same time I do think this way of framing it is selling Gary Bernhardt a little bit short. There is still an uncanny part in knowing all the right things at the right time to predict the future.
  - thaumasiotes 7y ago
    "The future will be just like the past, but with a different name". I guess it's just as accurate when Gary Bernhardt says it as when everyone else says it. It's not exactly a theme that's gone overlooked before. But still... executing bytecode in the browser goes way, way, way, way back.
    - jchw 7y ago
      It’s not just executing code in the browser. It’s been a while since I’ve watched the video but its more about JavaScript becoming the universal assembly language. I think at least that aspect is wrong because Wasm came into existence. But ignoring that detail and subbing in Wasm for JS, it’s uncanny.
      - dwohnitmok 7y ago
        It's even more uncanny than that. The talk hypothesized that JavaScript will not be the universal assembly language but rather a lower level language (or more accurately an OS-like system I suppose as the talk presents it), "Metal," would be. In that respect it predicted WebAssembly on the nose.
      - sp332 7y ago
        In December that same year, the Internet Archive started letting people boot and run MS-DOS emulators in the browser. And this was well after binfmt_misc has been (ab)used with JS engines to execute JS like a native program. A couple years earlier, NetBSD device drivers were running in the browser, and JS-engine-as-hypervisor was an explicit, if distant, goal. https://news.ycombinator.com/item?id=4757581 https://news.ycombinator.com/item?id=4757581
      - Ajedi32 7y ago
        I personally see WASM as a natural descendant of ASM.js, so in that sense I'd say its not really wrong, just missing a step. I don't know that it's necessarily uncanny though either; ASM.js was already a thing back when that presentation was given, so the existence of WASM isn't really surprising. The real central "prediction" of that talk wasn't WASM, it was METAL, which hasn't quite taken off yet. (The idea is out there[0], but so far mostly just as a self-fulfilling prophecy). [0]: https://github.com/lastmjs/wasm-metal https://github.com/lastmjs/wasm-metal
- dwohnitmok 7y ago
  I think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights. The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it. Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages compile to, but rather a bytecode perhaps inspired by JavaScript that will be the language of the future. Also, importantly this bytecode will win; that is most languages will the ability to directly compile to or have a VM in this bytecode. Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance. At least to me, neither of those were obvious insights even though I knew of these plugins and JSLinux. First off, those plugins died. Silverlight, ActiveX, Java on the web, Flash, all of these died out and were replaced by JavaScript before wasm really took off. It might've looked like the end state would be a version of JavaScript "winning." Second, things like PNacl, Emscripten, etc. still seemed like curiosities (as the talk refers to when showing Repl.it). It wasn't clear that they or the ideas they championed would get widespread adoption. These days it is looking more and more likely that wasm is going to become a target for all sorts of different compilers. The fact that it's a major compilation target of Rust, a language that's about as far away from what I would've thought of as a language for the web as possible, is striking. And though we're still a long ways away from running everything on WebAssembly, it no longer seems as exotic an idea as it once did to me. And because of that, as well as the fantastic presentation, I still return to this talk every so often awed at how much closer we are to realizing Metal. There's still a lot of room for the talk to go very wrong, but it's not as far-fetched as when I first watched it. EDIT: Put another way; the talk is interesting to me because it emphasizes the birth and death of JavaScript. It talks about a world where the same forces that propelled JavaScript to towering heights of popularity ultimately cast it aside and create a world not possible without JavaScript, but in which JavaScript itself essentially no longer exists.
  - cbhl 7y ago
    > Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance. I interpreted that part of the talk as hyperbole and sarcasm. It was saying that programmers will be so far removed from how computers work that they'll happily program against a model that has five layers of abstraction that simply serve to provide the original interface of the bottom layer. Bytecode, by its nature, has to be translated into native code -- the way for it to be 'faster' than native code is to be native code. In software, you can do this with static or JIT compilation. The hardware people do this by changing their CPUs to make the things that people do in the bytecode faster. (Apple introduced new floating point CPU instructions in their iPhones just to make JavaScript faster.)
- saagarjha 7y ago
  JSLinux was largely a toy, AFAIK. I don’t think it was meant as an exhortation to write all software that way.
cjbprime 7y ago
I think we're still waiting for a WASM-only OS, though :)
- tcoff91 7y ago
  I think I remember reading something on HN about some kind of tool for running WASM in some kind of kernel module to speed up app performance. EDIT: here it is: https://medium.com/wasmer/running-webassembly-on-the-kernel-8e04761f1d8e https://medium.com/wasmer/running-webassembly-on-the-kernel-...
  - saghm 7y ago
    I remember something like that being posted too; I think this is it? https://github.com/nebulet/nebulet https://github.com/nebulet/nebulet
    - cjbprime 7y ago
      So cool!
    - syrusakbary 7y ago
      Nebulet is a great piece of engineering! <3
- Izkata 7y ago
  Like this? https://browsix.org/ https://browsix.org/
- ksec 7y ago
  I wonder if Cloudflare will do something like this given they want to run WASM in their Edge Servers.
airstrike 7y ago
Seems like the obvious next step is using WebAssembly outside the browser so we can really go full-circle on this one EDIT: some quick googling shows it's already being done https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
- JoshTriplett 7y ago
  Yup. In addition to JavaScript runtimes that have added WebAssembly support, such as Node, there are dedicated WebAssembly runtimes, like wasmtime: https://github.com/bytecodealliance/wasmtime https://github.com/bytecodealliance/wasmtime If you want to provide a plugin or extension interface, and want to give those plugins a limited interface rather than making them all-powerful, embedding a WebAssembly runtime gives you all of that plus the ability for people to easily write plugins in any language. Also see https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type... for an illustrated description of how that'll work smoothly across languages.
  - zzzcpan 7y ago
    > embedding a WebAssembly runtime gives you all of that plus the ability for people to easily write plugins in any language No, you would still have to provide an application programming interface for every target language you want to support.
    - JoshTriplett 7y ago
      No, you don't. If you export functions to WebAssembly, any language that can run in WebAssembly can call those functions. And if you define WebAssembly Interface Types for your exported functions (note: still in development), any language that handles interface types can automatically handle things like "how does this language represent a string safely". Either way, you don't need to define a new API for every language.
      - 7y ago

chubot 7y ago

Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which is a CPU emulator written in JavaScript that runs the Linux kernel (using typed arrays and relying on fast JITs). That's just a way of saying that "the best way to predict the future is to invent it" (and do so before people who were "predicting" it). If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's nothing surprising about the development of wasm. It's been 10+ years in the making. And 20+ years ago Microsoft's browser had ActiveX plugins (which didn't use a VM and were really unsafe and unportable). Making a portable, sandboxed bytecode solves an obvious problem with that. Also the JVM ran in the browser, etc. [1] https://news.ycombinator.com/item?id=21618323 https://news.ycombinator.com/item?id=21618323

vanderZwan 7y ago
> If you knew about [x], there's nothing surprising about [y] You are technically correct, but at the same time I do think this way of framing it is selling Gary Bernhardt a little bit short. There is still an uncanny part in knowing all the right things at the right time to predict the future.
- thaumasiotes 7y ago
  "The future will be just like the past, but with a different name". I guess it's just as accurate when Gary Bernhardt says it as when everyone else says it. It's not exactly a theme that's gone overlooked before. But still... executing bytecode in the browser goes way, way, way, way back.
  - jchw 7y ago
    It’s not just executing code in the browser. It’s been a while since I’ve watched the video but its more about JavaScript becoming the universal assembly language. I think at least that aspect is wrong because Wasm came into existence. But ignoring that detail and subbing in Wasm for JS, it’s uncanny.
    - dwohnitmok 7y ago
      It's even more uncanny than that. The talk hypothesized that JavaScript will not be the universal assembly language but rather a lower level language (or more accurately an OS-like system I suppose as the talk presents it), "Metal," would be. In that respect it predicted WebAssembly on the nose.
    - sp332 7y ago
      In December that same year, the Internet Archive started letting people boot and run MS-DOS emulators in the browser. And this was well after binfmt_misc has been (ab)used with JS engines to execute JS like a native program. A couple years earlier, NetBSD device drivers were running in the browser, and JS-engine-as-hypervisor was an explicit, if distant, goal. https://news.ycombinator.com/item?id=4757581 https://news.ycombinator.com/item?id=4757581
    - Ajedi32 7y ago
      I personally see WASM as a natural descendant of ASM.js, so in that sense I'd say its not really wrong, just missing a step. I don't know that it's necessarily uncanny though either; ASM.js was already a thing back when that presentation was given, so the existence of WASM isn't really surprising. The real central "prediction" of that talk wasn't WASM, it was METAL, which hasn't quite taken off yet. (The idea is out there[0], but so far mostly just as a self-fulfilling prophecy). [0]: https://github.com/lastmjs/wasm-metal https://github.com/lastmjs/wasm-metal
dwohnitmok 7y ago
I think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights. The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it. Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages compile to, but rather a bytecode perhaps inspired by JavaScript that will be the language of the future. Also, importantly this bytecode will win; that is most languages will the ability to directly compile to or have a VM in this bytecode. Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance. At least to me, neither of those were obvious insights even though I knew of these plugins and JSLinux. First off, those plugins died. Silverlight, ActiveX, Java on the web, Flash, all of these died out and were replaced by JavaScript before wasm really took off. It might've looked like the end state would be a version of JavaScript "winning." Second, things like PNacl, Emscripten, etc. still seemed like curiosities (as the talk refers to when showing Repl.it). It wasn't clear that they or the ideas they championed would get widespread adoption. These days it is looking more and more likely that wasm is going to become a target for all sorts of different compilers. The fact that it's a major compilation target of Rust, a language that's about as far away from what I would've thought of as a language for the web as possible, is striking. And though we're still a long ways away from running everything on WebAssembly, it no longer seems as exotic an idea as it once did to me. And because of that, as well as the fantastic presentation, I still return to this talk every so often awed at how much closer we are to realizing Metal. There's still a lot of room for the talk to go very wrong, but it's not as far-fetched as when I first watched it. EDIT: Put another way; the talk is interesting to me because it emphasizes the birth and death of JavaScript. It talks about a world where the same forces that propelled JavaScript to towering heights of popularity ultimately cast it aside and create a world not possible without JavaScript, but in which JavaScript itself essentially no longer exists.
- cbhl 7y ago
  > Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance. I interpreted that part of the talk as hyperbole and sarcasm. It was saying that programmers will be so far removed from how computers work that they'll happily program against a model that has five layers of abstraction that simply serve to provide the original interface of the bottom layer. Bytecode, by its nature, has to be translated into native code -- the way for it to be 'faster' than native code is to be native code. In software, you can do this with static or JIT compilation. The hardware people do this by changing their CPUs to make the things that people do in the bytecode faster. (Apple introduced new floating point CPU instructions in their iPhones just to make JavaScript faster.)
saagarjha 7y ago
JSLinux was largely a toy, AFAIK. I don’t think it was meant as an exhortation to write all software that way.

cjbprime 7y ago

I think we're still waiting for a WASM-only OS, though :)

tcoff91 7y ago
I think I remember reading something on HN about some kind of tool for running WASM in some kind of kernel module to speed up app performance. EDIT: here it is: https://medium.com/wasmer/running-webassembly-on-the-kernel-8e04761f1d8e https://medium.com/wasmer/running-webassembly-on-the-kernel-...
- saghm 7y ago
  I remember something like that being posted too; I think this is it? https://github.com/nebulet/nebulet https://github.com/nebulet/nebulet
  - cjbprime 7y ago
    So cool!
  - syrusakbary 7y ago
    Nebulet is a great piece of engineering! <3
Izkata 7y ago
Like this? https://browsix.org/ https://browsix.org/
ksec 7y ago
I wonder if Cloudflare will do something like this given they want to run WASM in their Edge Servers.

airstrike 7y ago

Seems like the obvious next step is using WebAssembly outside the browser so we can really go full-circle on this one EDIT: some quick googling shows it's already being done https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

JoshTriplett 7y ago
Yup. In addition to JavaScript runtimes that have added WebAssembly support, such as Node, there are dedicated WebAssembly runtimes, like wasmtime: https://github.com/bytecodealliance/wasmtime https://github.com/bytecodealliance/wasmtime If you want to provide a plugin or extension interface, and want to give those plugins a limited interface rather than making them all-powerful, embedding a WebAssembly runtime gives you all of that plus the ability for people to easily write plugins in any language. Also see https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type... for an illustrated description of how that'll work smoothly across languages.
- zzzcpan 7y ago
  > embedding a WebAssembly runtime gives you all of that plus the ability for people to easily write plugins in any language No, you would still have to provide an application programming interface for every target language you want to support.
  - JoshTriplett 7y ago
    No, you don't. If you export functions to WebAssembly, any language that can run in WebAssembly can call those functions. And if you define WebAssembly Interface Types for your exported functions (note: still in development), any language that handles interface types can automatically handle things like "how does this language represent a string safely". Either way, you don't need to define a new API for every language.
    - 7y ago