Hacker News Reader

Comment by Ralfp | Hacker News Reader

> 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.

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

There is a FAQ entry on this point: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...

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 :)

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.

So it's not suitable for Python, Java, or C#?

Not unless you want to compile the JVM to webassembly and load a it on every pageview.

TeaVM[1] has an experimental WebAssembly backend that does something like this. Here's the recent Reddit thread[2].

[1] http://teavm.org/ [2] https://www.reddit.com/r/programming/comments/5899ln/teavm_j...

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.

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.

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.

but oracle...

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.

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.

> 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.)

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.

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.

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.

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

Sounds like they aim to implement only GC primitives to allow emulating a wide variety of different VMs.

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.

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#Prog... ), so it's sort of a moot point.

Reply on news.ycombinator.com