5 ms·

> Finally we can expand beyond JavaScript on front-end development. Yup! Thats the plan for web assembly! Write in what you want, compile to browser-supported

by Ralfp 10y ago

> Finally we can expand beyond JavaScript on front-end development. Yup! Thats the plan for web assembly! Write in what you want, compile to browser-supported format, deploy.

bobajeff 10y ago
That is not the plan. WebAssembly is not some holy grail universal bitecode intended for every language. It is intended for C and C++ developers to be able run their code in a performant way on the web.
- k__ 10y ago
  So it's not suitable for Python, Java, or C#?
  - tyoverby 10y ago
    Not unless you want to compile the JVM to webassembly and load a it on every pageview.
    - binji 10y ago
      TeaVM[1] has an experimental WebAssembly backend that does something like this. Here's the recent Reddit thread[2]. [1] http://teavm.org/ http://teavm.org/ [2] https://www.reddit.com/r/programming/comments/5899ln/teavm_java_bytecode_to_js_adds_experimental/ https://www.reddit.com/r/programming/comments/5899ln/teavm_j...
    - int_19h 10y ago
      You just need an AOT compiler that targets wasm directly. AOT compilers already exist for Java and C# for various target architectures; this is just another one.
  - kibwen 10y ago
    Eventually it should be, but trying to design a way to integrate multiple runtimes into a single webpage is going to take some work (e.g. imagine a page that imports code originally written in Python and Javascript and Ruby and Go, all with their own garbage collectors (and Go's custom concurrency model!)). The reason that C and C++ and Rust will work from the start is that they don't require invasive runtimes and so allow the browser vendors to punt on this problem until later.
    - AlphaSite 10y ago
      Hey, that's pretty much possible now! Graal can support a single app using JS, Python, Ruby, Java, etc all natively interoperating with one another.
      - sidegrid 10y ago
        but oracle...
- dragonwriter 10y ago
  Even if it was just C/C++, that would get you all the interpreted languages where the runtime is C/C++, which is a fair chunk. In any case, if it's a good compilation target for C and C++, it will be a suitable, if not always ideal, target for compilers for many other languages.
  - skybrian 10y ago
    Someone writing an interpreter or (more likely) a compiler needs to decide whether to output WebAssembly or JavaScript. Since code size matters, JavaScript will make more sense for high-level languages. You can reuse JavaScript strings, objects, the garbage collector, and so on. WebAssembly only makes sense for language like C/C++ that have a minimal runtime that can be shipped in each web page. Users don't care which one you use, so it won't make sense to switch to WebAssembly until there's a significant performance benefit and the code size issues are solved.
    - dragonwriter 10y ago
      > Since code size matters, JavaScript will make more sense for high-level languages. You can reuse JavaScript strings, objects, the garbage collector, and so on. Which can be useful, but it can also be bad if your languages model doesn't map perfectly to JS's (this is an issue already with JS-hosted versions of a number of languages that introduces incompatibilities with non-JS-hosted implementations.)
      - Klathmon 10y ago
        But webasm isn't exactly going to solve that. Unless you go 100% no-js you are still going to need to interact with it, and even if you do completely remove JS in your stack, the DOM APIs are still geared toward JS, and work in ways that make sense to JS.
- vesinisa 10y ago
  You are mixing it with asm.js. Asm.js is essentially a 32-bit VM that is very well-suited as a cross-compile target for single-threaded C/C++ code, but to ship something more high-level you would have to bundle it with a respective VM implementation. AFAIK WASM literally aims to be a "universal web bytecode", and they hope to eventually add multi-threading, GC and DOM access. Of course the exact implementation details might differ from e.g. your local Java runtime vis a vis GC and threading timings and such. But for example in a distant future each browser's JavaScript runtime could be just an interpreter that internally emits WASM. And there should not be any reason why you could not compile most Java / C# code to WASM once threads and GC are added.
  - bobajeff 10y ago
    No. GC access is a feature that they may possibly add at some undisclosed point in the future. (Just like it was with asm.js via Object Types IIRC) but it's not an explicit design consideration. No where does it say that it's intended to be a universal bytecode.
    - vesinisa 10y ago
      Not exactly sure what is meant with "universal web bytecode", but a binary VM code supported by all major browsers sounds like one. There's a whole Wiki page dedicated to GC: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md Sounds like they aim to implement only GC primitives to allow emulating a wide variety of different VMs.
      - bobajeff 10y ago
        At some point in the "future [unicorn icon]" sure. But the design today is around the porting of C and C++ apps the web. The feature you're talking about is meant for integrating with the browser. It could allow emulating a variety of VM's but that's not a promise or stated goal.
- overgard 10y ago
  A lot of languages can/do compile to C which then compiles to assembly (incomplete list: https://en.wikipedia.org/wiki/Source-to-source_compiler#Programming_language_implementations https://en.wikipedia.org/wiki/Source-to-source_compiler#Prog... ), so it's sort of a moot point.
kowdermeister 10y ago
I sense some wishful thinking here. WA will supplement JS not replace it. You'll have a canvas and that's it, but with the JS interface I can see how some people will try to abuse it. You can get rid of JS's shortcomings for years now with compilation. That's not really the goal here. What I see here is low level access for raw power. Most of the JS apps don't really need it. Edit: I take it back. According to this note, I don't see what would stop anyone avoiding JS at all. http://webassembly.org/docs/gc/#webidl-integration http://webassembly.org/docs/gc/#webidl-integration
- binji 10y ago
  There is a FAQ entry on this point: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-trying-to-replace-javascript https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
  - kowdermeister 10y ago
    That's what I remembered and I answered based on that before the edit. Once you can reach the DOM API directly from WA code, JS is redundant for you can use for example C# to build apps. I hate to sound alarmist, but we might look back at 2012-16 as the years when frontend tooling was easy :)

by Ralfp 10y ago

> Finally we can expand beyond JavaScript on front-end development. Yup! Thats the plan for web assembly! Write in what you want, compile to browser-supported format, deploy.

bobajeff 10y ago

That is not the plan. WebAssembly is not some holy grail universal bitecode intended for every language. It is intended for C and C++ developers to be able run their code in a performant way on the web.

k__ 10y ago
So it's not suitable for Python, Java, or C#?
- tyoverby 10y ago
  Not unless you want to compile the JVM to webassembly and load a it on every pageview.
  - binji 10y ago
    TeaVM[1] has an experimental WebAssembly backend that does something like this. Here's the recent Reddit thread[2]. [1] http://teavm.org/ http://teavm.org/ [2] https://www.reddit.com/r/programming/comments/5899ln/teavm_java_bytecode_to_js_adds_experimental/ https://www.reddit.com/r/programming/comments/5899ln/teavm_j...
  - int_19h 10y ago
    You just need an AOT compiler that targets wasm directly. AOT compilers already exist for Java and C# for various target architectures; this is just another one.
- kibwen 10y ago
  Eventually it should be, but trying to design a way to integrate multiple runtimes into a single webpage is going to take some work (e.g. imagine a page that imports code originally written in Python and Javascript and Ruby and Go, all with their own garbage collectors (and Go's custom concurrency model!)). The reason that C and C++ and Rust will work from the start is that they don't require invasive runtimes and so allow the browser vendors to punt on this problem until later.
  - AlphaSite 10y ago
    Hey, that's pretty much possible now! Graal can support a single app using JS, Python, Ruby, Java, etc all natively interoperating with one another.
    - sidegrid 10y ago
      but oracle...
dragonwriter 10y ago
Even if it was just C/C++, that would get you all the interpreted languages where the runtime is C/C++, which is a fair chunk. In any case, if it's a good compilation target for C and C++, it will be a suitable, if not always ideal, target for compilers for many other languages.
- skybrian 10y ago
  Someone writing an interpreter or (more likely) a compiler needs to decide whether to output WebAssembly or JavaScript. Since code size matters, JavaScript will make more sense for high-level languages. You can reuse JavaScript strings, objects, the garbage collector, and so on. WebAssembly only makes sense for language like C/C++ that have a minimal runtime that can be shipped in each web page. Users don't care which one you use, so it won't make sense to switch to WebAssembly until there's a significant performance benefit and the code size issues are solved.
  - dragonwriter 10y ago
    > Since code size matters, JavaScript will make more sense for high-level languages. You can reuse JavaScript strings, objects, the garbage collector, and so on. Which can be useful, but it can also be bad if your languages model doesn't map perfectly to JS's (this is an issue already with JS-hosted versions of a number of languages that introduces incompatibilities with non-JS-hosted implementations.)
    - Klathmon 10y ago
      But webasm isn't exactly going to solve that. Unless you go 100% no-js you are still going to need to interact with it, and even if you do completely remove JS in your stack, the DOM APIs are still geared toward JS, and work in ways that make sense to JS.
vesinisa 10y ago
You are mixing it with asm.js. Asm.js is essentially a 32-bit VM that is very well-suited as a cross-compile target for single-threaded C/C++ code, but to ship something more high-level you would have to bundle it with a respective VM implementation. AFAIK WASM literally aims to be a "universal web bytecode", and they hope to eventually add multi-threading, GC and DOM access. Of course the exact implementation details might differ from e.g. your local Java runtime vis a vis GC and threading timings and such. But for example in a distant future each browser's JavaScript runtime could be just an interpreter that internally emits WASM. And there should not be any reason why you could not compile most Java / C# code to WASM once threads and GC are added.
- bobajeff 10y ago
  No. GC access is a feature that they may possibly add at some undisclosed point in the future. (Just like it was with asm.js via Object Types IIRC) but it's not an explicit design consideration. No where does it say that it's intended to be a universal bytecode.
  - vesinisa 10y ago
    Not exactly sure what is meant with "universal web bytecode", but a binary VM code supported by all major browsers sounds like one. There's a whole Wiki page dedicated to GC: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md Sounds like they aim to implement only GC primitives to allow emulating a wide variety of different VMs.
    - bobajeff 10y ago
      At some point in the "future [unicorn icon]" sure. But the design today is around the porting of C and C++ apps the web. The feature you're talking about is meant for integrating with the browser. It could allow emulating a variety of VM's but that's not a promise or stated goal.
overgard 10y ago
A lot of languages can/do compile to C which then compiles to assembly (incomplete list: https://en.wikipedia.org/wiki/Source-to-source_compiler#Programming_language_implementations https://en.wikipedia.org/wiki/Source-to-source_compiler#Prog... ), so it's sort of a moot point.

kowdermeister 10y ago

I sense some wishful thinking here. WA will supplement JS not replace it. You'll have a canvas and that's it, but with the JS interface I can see how some people will try to abuse it. You can get rid of JS's shortcomings for years now with compilation. That's not really the goal here. What I see here is low level access for raw power. Most of the JS apps don't really need it. Edit: I take it back. According to this note, I don't see what would stop anyone avoiding JS at all. http://webassembly.org/docs/gc/#webidl-integration http://webassembly.org/docs/gc/#webidl-integration

binji 10y ago
There is a FAQ entry on this point: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-trying-to-replace-javascript https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
- kowdermeister 10y ago
  That's what I remembered and I answered based on that before the edit. Once you can reach the DOM API directly from WA code, JS is redundant for you can use for example C# to build apps. I hate to sound alarmist, but we might look back at 2012-16 as the years when frontend tooling was easy :)