I'd be more concerned if it weren't already basically impossible to figure out WTF is going on on any "web app" using View Source.

I wish we'd all agreed to severely cripple Javascript[1] early on and instead improved built-in form elements and stuff like frames, but we didn't so here we are. The web's already mostly transitioned from being for people to being for machines and the delivery thereof, so webassembly's not going to ruin anything. It's already ruined.

[1] Say, no ability to trigger a broad set of events that would ordinarily be user-initated, no ability to submit forms itself, no XHR or similar. Probably some other stuff I'm not thinking of right now. So, almost but not quite worthless. That would have been necessary if we'd wanted to keep the people browsing in control of the Web. Instead we chased "oooh, shiny!" and took that control away, practically speaking.

I don't see how that does anything except force logic to the server and guarantee page-by-page update and view semantics. At least some large percentage of the code for some of these "modern" web apps is on my computer: that means a lot; and anything we can do to discourage code running in the cloud with data stored in the cloud--which absolutely implies giving complex turing complete control over local behavior and expansive state--is a fundamental win for users of the World Wide Web.

> I don't see how that does anything except force logic to the server and guarantee page-by-page update and view semantics.

Which keeps the delivered document a document, and not an application.

> At least some large percentage of the code for some of these "modern" web apps is on my computer: that means a lot; and anything we can do to discourage code running in the cloud with data stored in the cloud--which absolutely implies giving complex turing complete control over local behavior and expansive state--is a fundamental win for users of the World Wide Web.

I consider it much better that only explicitly-requested actions (clicking a "submit" button, or a link, for example[1]) trigger submission of data and execution on a server than to let javascript trigger the same. Control over behavior and data is better retained, especially for lay users, if it's impossible for an ordinary web page to send every mouse movement and keystroke to a server—something that's in fact done, all the time. Retaining that control is well worth pushing web "app" logic to the server.

Programs that need local execution would just have to be delivered as... a local program, not a web page. Losing that distinction cost the average user control and safety when they're in their browser, and fundamentally changed what the web is. Some of us much preferred what the web used to be, not because we hate progress, but because progress that destroys something that was itself valuable kinda sucks. "Web apps" should have had some other delivery channel, if they had to exist—and clearly there's a demand for better cross-platform GUI application delivery. Making browsers serve that purpose has made the web fat, opaque, and untrustworthy.

[1 EDIT] and in fact I'd rather restrict submission of new data, that the server didn't already have, to form elements the appearance of which cannot be modified at all, like a "submit" button. No JS submit-form-or-add-querystring-data-to-URL-on-link-click shenanigans. On my ideal web links would be safe to click, always, with only form submit buttons carrying any risk at all (and even that far less than now, if, say, JS isn't permitted to add to or modify form data in a POSTable form, which is another restriction JS would have on my ideal Web)

> that conflicts with the underlying tenets?

The underlying tenets are a bunch of technologies designed for rendering documents + one pretty horrible programming language. Which we're now building full-fledged apps and games on. I think that's way more of an abuse of the underlying tenets than webassembly is. I truly believe webassembly will set us free in many ways.

In which way it is terrible? It is a Ps and PDF rendering engine. I don't know if you are already aware of this, but Postcript is almost a complete programming language, so writing a Ps renderer is like writing an interpreter (or compiler...)

Not trivial stuff at all.

Also, why do you call this "legacy C++ code"?

As I noted, my comment is not about their code. Nor the functionality for that matter. And yes, I'm aware of the issues in PS and PDF rendering, having worked on them as part of a not-so-common and very-common operating system that deeply used them.

Wasm is designed around bringing non-web-native languages to the web. A good project would have been to enable new web native languages to complement JavaScript. Instead, there's an emphasis particularly on bringing C++ to the web. I think this is counter to the philosophy of the platform and harmful in the long run.

It's really about bringing any language that can target LLVM IR to the web, and that's more than just C++.

https://en.wikipedia.org/wiki/LLVM#Front_ends

C++ just happens to be a popular choice because there are many useful C++ libraries, and the compiler already produces very optimized code, so the performance benefit is most noticeable. In particular, I'm excited to get the Lua interpreter, written in C, on the web in a performant way.

There would be no issue with that, if you were forced to deliver source code, with comments, and without obfuscation instead of a highly obfuscated binary format.

WebAssembly makes it even more common to run untrusted, random code on your system. The next RowHammer.js will be a lot more powerful.

> In particular, I'm excited to get the Lua interpreter, written in C, on the web in a performant way.

Can't wait for this!

Why should they complement Javascript? The browser should be language-agnostic, just as your bare metal (computer) is.

Otherwise, then, we should tell people they "must" use C to write applications and that othrr languages should be there only to "complement C."

Understand the hesitancy. But we develop a very high quality engine for as many platforms as we can.

I.e. we can maintain less code, keep it fast, maintain high quality and identical behaviour across platforms.

I agree, it's 100% rational from your point of view, just as compiling it for the Flash VM or running as an ActiveX component would have made perfect sense for you to bring your high-quality code to more platforms.

My hesitation isn't about your code. It's about what we as a community are doing to the web platform.

Yeah it will be interesting. I feel like having used this now that we'd be poorer without it. But you are right. There are ethical challenges ahead.

Except WebAsm is language independent and reuses DOM (indirectly through javascript).