Exception handling is necessary to efficiently support languages that need it without giving them direct control over the stack. I'd prefer if exception handling was provided with a more general abstraction though.

GC is necessary for the same reasons, to prevent each language from bringing it's own GC and to enable cross-language interop.

JIT is already implied by the very nature of Webassembly being an architecture independent stack machine, so every runtime has to already be a JIT compiler anyway (except interpreters). Exposing JITing to Wasm code is a natural progression and very valuable.

Not that the WASM spec work doesn't have problems (looking in as an outsider), but the existence of these features are not my complaints.

If you want to write in a high-level language in the browser, wouldn't it make more sense to compile to JavaScript?

It seems to me like the main value proposition in Web Assembly was to provide a target for languages like C, C++, and Rust.

Compiling to JS is a good option, with the caveat that it will never deliver consistent performance. JS engine vendors place less importance on optimizing for JS transpilers now that the future is WebAssembly.

WASM has become a Web Standard a couple of years ago. It's very simple (at its first version at least) which allowed all browser implementers to support it from day one. It has accomplished the goal of running C/C++ applications efficiently. Rust code can mostly compile to WASM and run as well (only crates that use stuff like drivers or OS-specific calls don't work).

However, a few years later, there's not much that has been improved in the WASM world. The work being done on the current proposals is monumental and would require the same level of investment that has already been spent on things like the JVM and the .NET runtime, as you point out. To write a specification as well written as WASM for these things is basically impossible.

And they're only doing that in order to support other high level languages to compile to it without having to ship their own runtimes.

But the problem is that given how hard the work is, the benefit of doing this would need to be enormous to justify spending so much work on it... but it's not! JavaScript, for better or worse, has pretty decent performance and a huge amount of code has been written in it. If you try to re-write something in Java or Go, say, to replace JS, even when WASM supports GC and exceptions, I doubt it'll improve anything over JS performance.

Besides, GraalVM already exists which can run nearly any language with very high performance if you're not completely locked on the web platform.

So, all this drama that's going on around WASM for what?

I say, leave it alone, make sure it stays simple and supports high performance stuff written on non-managed languages... and consider the job done.

> I doubt it'll improve anything over JS performance.

I will take a small memory/performance/bandwidth hit to not have to program in JavaScript.

We aren't fully there yet but something like .NET Blazor demonstrates the potential. Once we've over the hump I expect an explosion of alternatives.

EH, GC and JIT are examples of difficult things that some use cases demand, yeah. They were intentionally punted out of the MVP into the Future as a result of that - the spec committee were aware of the need for those things (and some of us actively wanted them) but it's really hard to satisfy all interested parties and still ship.

Exception Handling appears to be in really good shape right now, but I have my doubts about GC. I'm not sure JIT will ever be solved (right now people seem to just compile tons of modules and hope the browser won't crash).

I don't think any of this means that WASM has a bad future, but it'll probably require a lot of careful work as it has up until now.

Adding those features doesn't mean you have to start using them for everything. This is different from how they work in the JVM or CLR- their role in WebAssembly is to enable interop with the host (which already has them regardless), and to round out some of the capabilities that native code has but which can't be implemented efficiently on the current WebAssembly sandbox.

I don't see how that harms WebAssembly as a lightweight cross-platform target. It may make it more difficult to implement, but AIUI there will always be room for simpler hosts that leave these features out or keep them simplistic. There is no equivalent ecosystem problem to adding these kinds of features to a language, where all your dependencies will start using them, any more than inherently exists for native code that can already just implement those things itself.

> of being a lightweight, platform agnostic target

A little late for that. I see that my Chrome browser is currently using 2.66GB of RAM (for about 40 tabs, or about 65M per tab). I remember when I first started using Java, my whole computer only had 8M of RAM, and while it has gotten larger, I think it is still considerably lighter weight than a web app, despite also giving much richer APIs and multi-threading. The advantage of web apps isn't that they're lighter weight from a systems resource point of view, but lighter weight from a user's effort in installing and using the app, point of view (now that Applets are gone).

I'm actually pretty excited about the three features you mention, mainly because it would make WASM useful to me.

Why not make WASM as simple as possible, and let layers on top of it deal with extensions like GC?

Stacking abstractions, like how computer architecture used to work in the old days.

If you provide a non-opinionated base platform, users will add opinions, and those will not all be compatible with each other.

Not adding GC or not defining how exceptions work could easily lead to a situation where you want to use a couple of third-party libraries, but discover they, combined, use three different garbage-collecting memory allocators and two different ways to handle exceptions, even where function overloading works differently in different libraries.

As an example, look at string implementations in various C programs. Even if they if they boil down to a pair (int, malloced memory), you still might not be able to pass one obtained from a function in one library to a function in another library.

Sounds nice in theory, but I suppose that if Linux or OSX or whatever OS you use forced developers to use one style of GC, a lot of people would be very disappointed.

I believe that the problem is that the more features you add, the less general it's going to be (for example, add canonical exception handling and you'll almost certainly exclude Common Lisp, the advanced exception handling features of which the canonical exception handling for WASM almost certainly won't include). Presumably on a scale from a physical computer to a JVM, you don't want to slide towards JVM too much, since not everyone wants to program in Java.

Sounds like what you want is Java Applets.

Everyone wants graalvm, people have just not realized it yet and it's sad

I've poked around in Chrome's source code, and what struck me is that the JS-to-C++ interface seems pretty similar to what's going on in a game engine - C++ classes with generally pretty similar APIs to their JS counterparts are wrapped and exposed to JavaScript - I think this is the way WebAssembly should be implemented as well- an interface that replaces this interaction layer with its own - since the native objects' lifetimes are handled by C++, a typical WASM target language (say C++ or Rust) would be pretty straightforward, since it could access these resources with similar semantics.

Additonally, in managed, garbage collected runtimes, like .NET, the handling of native resources with explicit lifetimes is a solved problem as well - garbage collection would be handled by the languages own runtimes, no need to move this responsibility to WASM.

This would also avoid the issue of having the .NET GC and the JS GC coexist - this typical too many cooks scenario of 2 separate GCs is a nightmare to manage.

Another daring, pie-in-the-sky thought: Javascript could use this interface as well, becoming just one of the many languages that can target the browser.

GC & JIT are complications, but some error handling and ways to deal with complex types are truly useful, IMHO.

You forgot the fourth: file I/O, and wider coverage by JavaScript thereof

These are considered extensions and WASM is useful even without them.

Aren't those functionalities critical for WASM to fully replace JS and become "the common runtime" for all web languages? I don't think we can build an efficient implementation of those on top of the "simple" WASM.

Spend 5 minutes reading about WASM and see how everyone involved in it keeps repeating "replacing JS is NOT the goal". Even with all the repeating, the message does not seem to be coming across.

To be fair, I imagine the original IBM PC team in 1980 kept repeating "replacing our mainframes is NOT the goal", too.

The more features you add, the less (not more) common it's going to be as a runtime.