I'm siding with baybal2 on this one. No matter how much you're wishing to use your favourite language on the Web, WASM is at best unnecessary, as the kind of application it enables (near-native speed) can be had with ordinary native apps as well. Why does something like that have to run in the browser? The only reason I can think of is because software/game publishers want to control your usage even more.
But it doesn't stop there: the worst possible outcome of WASM is that entire custom browser runtimes are being pushed to you [1]. Say goodbye to content linking, sharing, saving, translation, accessibility, ad blocking, etc. Not to mention content will only work on the bundled WebKit version.
WASM is user-hostile and anti-Web. What does it even mean that W3C "approved" a working group? I thought WASM was a WHATWG thing. W3C shouldn't lend what's left of its credibility to it.
Native apps are not compatible across platform. But more importantly they can't be safely installed by the user. I don't want to install your websites app because I have no way of knowing it won't give me a virus or drain my battery. How does that let "software publishers control my usage even more"? It takes a significant amount of their control away by putting them in a limited sandbox.
Wasm is the first time we will get cross platform and fully sandboxed native speed code.
None of what you speak of has anything to do with wasm. You can do all that just fine with JavaScript. We've had that world ever since browsers allowed disabling right clicking. Even before js, you could always distribute your webpage as an image if you wanted that. Wasm just let's you run code faster. It doesn't change anything.
All of that applies to JavaScript again. Wasm is just lower level and simpler. If anything it should be significantly easier to sandbox because of its simplicity. It doesn't provide any more access to Apis or anything than JavaScript does.
Some sandbox is better than no sandbox. When's the last time somebody delivered ransomware through the browser without a user explicitly opening a downloaded file?
> But it doesn't stop there: the worst possible outcome of WASM is that entire custom browser runtimes are being pushed to you [1]
If we ever come to the point where all you need to develop a web browser is a wasm vm, don't you find exciting how much simpler a web browser would become? At the moment it is one of the most complex pieces of software out there. It is so hard to build a modern web browser from scratch nowadays that doing so as a hobby would take a lifetime. This takes the power away from individual developers, since it's not very realistic to build a new browser unless you are a big corporation with money to spare.
This situation also poses a big problem for the development of new operating systems. If your shiny, awesome, new research open source OS does not have a modern web browser, it will never reach wide adoption and thus never atract enough developers to build critical mass. The alternative is to make your OS compatible with POSIX and thus reuse the work of others so that you can build existing web browsers. But then you are most likely bound to become just another unix/linux alike, thus hindering innovation.
If we ever come to the point where all you need to develop a web browser is a wasm vm, don't you find exciting how much simpler a web browser would become?.
But you're not removing complexity, just moving it into the wasm-based runtime, and in the process it removes the power that comes with building the browser, which is shaping how the user sees and interacts with websites.
If every website is a blob of code that you have to execute as a black box, what's the point of writing your own browser? It'll just be a slower copy of every other, since all the potential for making it different has been taken away.
>If every website is a blob of code that you have to execute as a black box, what's the point of writing your own browser? It'll just be a slower copy of every other, since all the potential for making it different has been taken away.
Because not all websites need all the complexity built into a browser. And wasm does necessarily imply that we need to leave html and css behind. But we get the freedom to choose and build better options.
> This situation also poses a big problem for the development of new operating systems.
I am currently developing a new kind of operating system using nothing but web technologies (ie, it is technically a single-page web app). It might not be the same kind of legacy hardware-centric operating system that most techies fret over, as I am just interested in "userland" ideas (ie, what new kinds of applications can we build, using what new kinds of higher-order abstractions). IMO, the kinds of research programs you are thinking of are really, practically speaking, solved problems.
Also, my OS is compatible with POSIX, as it is the first (that I know of) Javascript implementation of IEEE Std. 1003.1 (Shell Command Language).
As individual developers, we really need to start thinking of web browsers as the hardware layer, virtualized as it may be. Just as the scripting languages of the early 90's allowed us all to start thinking at higher levels at the language layer, modern web browsers allow us to start thinking at higher levels at the OS layer.
You are basically saying we shouldn't bring good scripting environments into the web, because if we do, people will use them.
As much as I hate all the "javascript required to render text" sites out there, I can't agree. Scripting has its uses, and a proper environment will not only make it easier to deal with those accessibility and compatibility problems, it will also make it easier for browsers to sandbox those scripts so they won't mess with your computer.
I agree its antiweb. But as these clowns at Google and Microsoft try to figure out ways to guarantee their long term employment, whether its through the appstore or this kind of bullshit - one thing they don't realize is most ppl have enough disk space on hand to store most of the useful internet and enough processing power to index it themselves.
People really don't need the crap that is called the internet today. Just check out what kiwix can do and ask yourself what browser makers are trying to do.
> the kind of application it enables (near-native speed) can be had with ordinary native apps as well. Why does something like that have to run in the browser?
For the same reasons all the other kinds of web applications are not developed as native apps as well. Hint: it's not only about speed. Some of the main reasons web apps are winning over native apps is easy of distribution, updates and being multiplataform. And it's being increasingly harder to force javascript to behave as a general application programming environment.
Was going to reply something something about sandboxing but then I realized: If we're going to sandbox native apps, I'd rather it be done by a cross-platform standard like wasm instead of done differently by each vendor.
The fact is, this web assembly stuff could be seen in some ways as a response to the walled gardens being built by each vendor right now. I prefer native apps too, but if we're going to have walled gardens, why not one big one we can share.
Ah ok, I didn't see it from that PoV, I'm not into third-party apps on my phone. Speaking of which, do you believe Apple will allow running WASM apps on iOS?
I'm a fan of anything that will help ease the pain induced by the ever-growing Electron cancer on the desktop. Hopefully this will catch on before I need 64GB of RAM...
But it doesn't stop there: the worst possible outcome of WASM is that entire custom browser runtimes are being pushed to you [1]. Say goodbye to content linking, sharing, saving, translation, accessibility, ad blocking, etc. Not to mention content will only work on the bundled WebKit version.
WASM is user-hostile and anti-Web. What does it even mean that W3C "approved" a working group? I thought WASM was a WHATWG thing. W3C shouldn't lend what's left of its credibility to it.
[1]: https://trevorlinton.github.io/