Because DOM manipulation in C++ sounds like a nightmare to me.

If you want it to be fast, you probably shouldn't touch the dom.

To the contrary, I think everyone should touch the DOM when they need the DOM. If this is going to be a platform for more than ads and shitty games, it will need to be able to use the browser's exquisitely engineered ability to do text rendering and layout.

Just like Flash or the JS game platforms that are stupid hacks on top of the canvas element, if people have to implement text rendering without the DOM, it'll encourage putting poorly-rendered text in unusable layouts with squirrely scrollbars. We can do better.

I mean you would do it the react way and only manipulate an abstract representation of the dom.

C++ speed in the browser... just be sure not to touch the browser.

I was thinking more about Ruby, Python, or go

It probably won't happen in V1 but yes, it's incoming. We'll be able to pretty much use whatever we want. When wasm was first announced Brendan Eich made this clear, and a lot of the JS-All-The-Things folks who bet their careers on it were upset.

I'm not sure why, if you like JS, people can keep on using JS indefinitely. My theory on programming is to use the language that I prefer, and worry about everything else secondary. For me that's Python. I've mostly avoided any deep dives on learning JS so it'll be nice to be a part of a budding Python web frontend community when the time comes.

I'm getting somewhat excited about swift. It's quite a modern language syntactically and python/ruby-like productivity may not be out of reach. Yet it leaves managed languages in the dust performance-wise (factor 100x plus), on par with C++.

And the memory management is uses should make compilation to WebAssembly rather straightforward. (... I believe – I have little knowledge of that sphere and welcome any corrections).

Wouldn't you still have to ship the entire python VM? That doesn't sound to feasible for your average web app.

Once wasm supports some access to the gc (on the roadmap), It should be feasible. You wouldn't reimplement the entire runtime, but reuse functionality (like the gc) from the js runtime.

Do you have any reference for that? You can already technically use whatever you want and wasm will not remove the need for high level languages also having to supply a (multi megabyte) runtime as there is no direct mapping to wasm instructions unlike with C++ or C.

Eich's comments on HN and on Twitter. It was all discussed when wasm was first announced a while back. I'd dig up the exact source comments from Eich, but at work. You'll probably see enough comments from the wasm folks in this post to verify whatever particular technical specs you're interested in to satisfaction.