7 ms·

And so the age of WebAssembly begins...

k__ 10y ago
What I ask myself, is this really the end of JavaScript? WASM reminds me of the NDK on Android. A way to write high performance GC-less code, but nobody started to use it for other things than high performance computations. Will people really start to port runtime environments to WASM so they can run Ruby, Python and Java in browsers? Or will this mainly be a place for C/C++, Rust and co to get some niche high end stuff running?
- bluejekyll 10y ago
  Or a bigger question, will it be a great space to show that Rust is a great language that can scale up and down through the entire stack? There is one language and toolset which can be used to do everything. Utopia? Yeah. I know people will still choose their favorite languages for task x, y and z, but I can still dream.
- judah 10y ago
  Definitely not the end of JavaScript. But it is the end of JavaScript-only. It's likely we'll see other languages targeting WebAssembly in the next few years. I heard rumors Microsoft is working on something in that area. If I were to guess, I'd expect a TypeScript-to-WASM and C#-to-WASM to follow. Java, Rust, Go, and others will likely have something too. Additionally, I expect to see some JS-heavy frameworks (React, Angular, etc.) write performance-critical sections with WASM, thus benefiting a great number of web apps.
  - bluejekyll 10y ago
    Rust already has something: https://hackernoon.com/compiling-rust-to-webassembly-guide-411066a69fde#.4nukotm6s https://hackernoon.com/compiling-rust-to-webassembly-guide-4...
  - k__ 10y ago
    Rust on WASM is probably trivial. But C#, Java and Go are GC languages, porting them is probably a much heavier venture.
  - tmccrmck 10y ago
    Where did you hear these rumors? I could see a WebAssembly target for MSVC in the near future (say hello to Office in the browser) but the CoreCLR needs GC so it's currently out of the question.
    - judah 10y ago
      I heard this directly from a higher up at MS during a conference afterparty. He said he couldn't wait for browser support for Web Assembly to go live so he can show the things they're working on. And yeah, for C# to WASM, we'd need garbage collection support in WASM. That doesn't exist yet, though it's on the list of future enhancements[0]. [0]: https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-whats-next/ https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...
- flohofwoe 10y ago
  IMHO: No, I don't think WASM is the end of Javascript, in the best case both flavours can focus on what they do best (Javascript for light-weight web-frontend scripting and DOM manipulation, WebAssembly for computation modules). And Javascript can focus on being a 'scripting language' again, and not a compile target. I think most serious WebAssembly apps will still use Javascript glue code for the actual HTML/CSS frontend. I also think there will be many web apps which are 50/50 JS/WebAssembly where WebAssembly is used for libraries that need to do fairly heavy computations, but can do that without having to call into browsers APIs too much (e.g. image processing, physics engines, AI, etc...). Android NDK is heavily used for games, I wouldn't say that 'nobody started using it'. I'm not seeing the appeal for running languages on top of WebAssembly that need a heavy runtime environment. The big downloads this requires will kill all the fun. Even C++ will create bloated WASM modules if one isn't careful. Using 'embedded style' programming practices really makes sense when trying to reduce module size for asm.js/WebAssembly.
  - pjmlp 10y ago
    > Android NDK is heavily used for games, I wouldn't say that 'nobody started using it'. Which is very much the only use case that Google's supports, and Android APIs that are exposed to it, for anything else welcome to JNI.
    - flohofwoe 10y ago
      True, and isn't that a shame :/
    - floatboth 10y ago
      Isn't JNI on Android also "NDK"? NDK provides a compiler toolchain and a build system — if you're building native libraries to JNI into, that's also built by NDK.
      - flohofwoe 10y ago
        Internally: yes. But if all you need is the C-APIs provided by the NDK you don't need to deal with JNI (or Java). Unfortunately the NDK doesn't provide much.
- pjmlp 10y ago
  Well on Android's case it helps that the Android team is not very keen in allowing the NDK to be anything more than porting native code into Android, high performance games, or just implementing Java native methods. Even for Android Things they gave up on their plan for C++ Frameworks on Brillo, and adopted the Android Frameworks instead, due to "We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK)". So to come back to WASM, it depends on how willing the browser vendors are to push it, beyond the initial prototype.
  - greenhouse_gas 10y ago
    Generally, it seems that the success and failure of a language depends on libraries, and most android libraries are written around Java rather than native. But if you want, you can write libraries which will allow you to write Android Apps in C, C++, C#, Rust or Go (as people have already done, see Qt and Xamarin for example). The thing is that it's much easier to write a simple CRUD app in Java than in C++.
    - pjmlp 10y ago
      Because of how Google handles the NDK experience. Using C++ on iOS or UWP isn't as painful experience as on Android.
- dualogy 10y ago
  No, compiled languages have never ended the existence of Python, Perl and other scripting languages. Similar principles will surely apply. For WASM code to interact with DOM or external scripts / JS libs in any meaningful manner, the wasm generator will have to provide in any event additional JS code anyway.
- greenhouse_gas 10y ago
  No, but for a different reason. Right now relying solely on WebAssembly where you can use JS is dead in the water (how many websites still keep up IE support). The question will be in a few years (especially once WebAssembly DOM support comes in). Even then, there's so much JS in the wild that only a depracative step (JS is no longer supported) will kill it. It's like Clojure, Kotlin, Groovy and other JVM languages. Even if they are better by a long shot than Java, the legacy factor will keep JS (and Java) alive for a long time (and the fact that JS doesn't require a compiler or environmental).

k__ 10y ago

What I ask myself, is this really the end of JavaScript? WASM reminds me of the NDK on Android. A way to write high performance GC-less code, but nobody started to use it for other things than high performance computations. Will people really start to port runtime environments to WASM so they can run Ruby, Python and Java in browsers? Or will this mainly be a place for C/C++, Rust and co to get some niche high end stuff running?

bluejekyll 10y ago
Or a bigger question, will it be a great space to show that Rust is a great language that can scale up and down through the entire stack? There is one language and toolset which can be used to do everything. Utopia? Yeah. I know people will still choose their favorite languages for task x, y and z, but I can still dream.
judah 10y ago
Definitely not the end of JavaScript. But it is the end of JavaScript-only. It's likely we'll see other languages targeting WebAssembly in the next few years. I heard rumors Microsoft is working on something in that area. If I were to guess, I'd expect a TypeScript-to-WASM and C#-to-WASM to follow. Java, Rust, Go, and others will likely have something too. Additionally, I expect to see some JS-heavy frameworks (React, Angular, etc.) write performance-critical sections with WASM, thus benefiting a great number of web apps.
- bluejekyll 10y ago
  Rust already has something: https://hackernoon.com/compiling-rust-to-webassembly-guide-411066a69fde#.4nukotm6s https://hackernoon.com/compiling-rust-to-webassembly-guide-4...
- k__ 10y ago
  Rust on WASM is probably trivial. But C#, Java and Go are GC languages, porting them is probably a much heavier venture.
- tmccrmck 10y ago
  Where did you hear these rumors? I could see a WebAssembly target for MSVC in the near future (say hello to Office in the browser) but the CoreCLR needs GC so it's currently out of the question.
  - judah 10y ago
    I heard this directly from a higher up at MS during a conference afterparty. He said he couldn't wait for browser support for Web Assembly to go live so he can show the things they're working on. And yeah, for C# to WASM, we'd need garbage collection support in WASM. That doesn't exist yet, though it's on the list of future enhancements[0]. [0]: https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-whats-next/ https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...
flohofwoe 10y ago
IMHO: No, I don't think WASM is the end of Javascript, in the best case both flavours can focus on what they do best (Javascript for light-weight web-frontend scripting and DOM manipulation, WebAssembly for computation modules). And Javascript can focus on being a 'scripting language' again, and not a compile target. I think most serious WebAssembly apps will still use Javascript glue code for the actual HTML/CSS frontend. I also think there will be many web apps which are 50/50 JS/WebAssembly where WebAssembly is used for libraries that need to do fairly heavy computations, but can do that without having to call into browsers APIs too much (e.g. image processing, physics engines, AI, etc...). Android NDK is heavily used for games, I wouldn't say that 'nobody started using it'. I'm not seeing the appeal for running languages on top of WebAssembly that need a heavy runtime environment. The big downloads this requires will kill all the fun. Even C++ will create bloated WASM modules if one isn't careful. Using 'embedded style' programming practices really makes sense when trying to reduce module size for asm.js/WebAssembly.
- pjmlp 10y ago
  > Android NDK is heavily used for games, I wouldn't say that 'nobody started using it'. Which is very much the only use case that Google's supports, and Android APIs that are exposed to it, for anything else welcome to JNI.
  - flohofwoe 10y ago
    True, and isn't that a shame :/
  - floatboth 10y ago
    Isn't JNI on Android also "NDK"? NDK provides a compiler toolchain and a build system — if you're building native libraries to JNI into, that's also built by NDK.
    - flohofwoe 10y ago
      Internally: yes. But if all you need is the C-APIs provided by the NDK you don't need to deal with JNI (or Java). Unfortunately the NDK doesn't provide much.
pjmlp 10y ago
Well on Android's case it helps that the Android team is not very keen in allowing the NDK to be anything more than porting native code into Android, high performance games, or just implementing Java native methods. Even for Android Things they gave up on their plan for C++ Frameworks on Brillo, and adopted the Android Frameworks instead, due to "We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK)". So to come back to WASM, it depends on how willing the browser vendors are to push it, beyond the initial prototype.
- greenhouse_gas 10y ago
  Generally, it seems that the success and failure of a language depends on libraries, and most android libraries are written around Java rather than native. But if you want, you can write libraries which will allow you to write Android Apps in C, C++, C#, Rust or Go (as people have already done, see Qt and Xamarin for example). The thing is that it's much easier to write a simple CRUD app in Java than in C++.
  - pjmlp 10y ago
    Because of how Google handles the NDK experience. Using C++ on iOS or UWP isn't as painful experience as on Android.
dualogy 10y ago
No, compiled languages have never ended the existence of Python, Perl and other scripting languages. Similar principles will surely apply. For WASM code to interact with DOM or external scripts / JS libs in any meaningful manner, the wasm generator will have to provide in any event additional JS code anyway.
greenhouse_gas 10y ago
No, but for a different reason. Right now relying solely on WebAssembly where you can use JS is dead in the water (how many websites still keep up IE support). The question will be in a few years (especially once WebAssembly DOM support comes in). Even then, there's so much JS in the wild that only a depracative step (JS is no longer supported) will kill it. It's like Clojure, Kotlin, Groovy and other JVM languages. Even if they are better by a long shot than Java, the legacy factor will keep JS (and Java) alive for a long time (and the fact that JS doesn't require a compiler or environmental).