Code, that is unreviewed, unaccounted and executed automatically. Now it shall be high-performance, too? Does the sandbox work? Does it really work? Are there no side channels? Are you sure? How do you make sure you don't take part in a DDoS attack or mine cryptocurrencies for somebody else? These are just points I can come up with spontaneously.

Besides that, the appification of the web is bad because it leads ultimately to dependency on software that is outside of the users control.

This is all already true for Javascript, wasm doesn't change that much here.

It makes the use-case for this type of code deployment wider and it's more effective at what it's already used for.

These are two reasons why developing and supporting WebAssembly is finally against the interest of the users.

How does it do that exactly? Anything you can do in wasm you can do in JavaScript, only was can do it faster. This freak out that some people have over wasm is bizarre to me on a technical level. I think it comes down to lots of JavaScript devs being threatened by more difficult languages being useful for web pages.

I don't program in JavaScript.

> Anything you can do in wasm you can do in JavaScript, only was can do it faster.

It's faster and more flexible because it can easily be targeted by compilers. That is the problem. This might sound surprising. Allow me use an analogy to explain it.

Let's assume some new technology was invented to more easily breed cattle for meat production. I completely understand why some people would want that, and develop it. I think breeding and killing cows and bulls just to eat a steak is unethical. So, I would absolutely refuse to work on the technology, and I'd expect the same of everybody that cares about being ethical.

Now, coming back to JavaScript and wasm, it is used to deploy code in a way that takes the control of the software from the users to the developers. The deployed code is unreviewed, unaccounted, unsigned and executed automatically. I consider unsafe in the computing sense. So, I consider code execution on the web unacceptable. Since, wasm makes that easier and more efficient, I'm opposed to it.

On top of that I consider JavaScript a bad language. I'm worried by how much it's pushed as a teaching language.

> It's faster and more flexible

I can see where you are getting confused. It is actually just faster. Again, there is nothing you can do is wasm that you can't already do it javascript.

> The deployed code is unreviewed, unaccounted, unsigned and executed automatically. I consider unsafe in the computing sense. So, I consider code execution on the web unacceptable.

All of these things apply to javascript.

> On top of that I consider JavaScript a bad language. I'm worried by how much it's pushed as a teaching language.

This has absolutely nothing to do with anything in this thread. It is pretty clear that you have biases and frustrations that have nothing to do with technical merits.

It's irrelevant if it's just faster, or has other technical merits, too. What those specifically are is irrelevant, as the political and societal consequences of advancing that way of code deployment are bad independently of that. My whole point is solely based on these consequences.

You keep making that assertion, but you haven't really backed it up by anything. If you are talking about obfuscation, javascript can be obfuscated just as much as webasm. Again, all IO must happen in javascript anyway and anyone can look at a text representation of webasm.