W3C recommends WebAssembly

This is not a design opinion to me. Unless your application state can be represented as pure text, it can not be efficiently conveyed to blind users. So we force you to do that.

> It would be better if the web browser world had pixel level render targets

We also have escape hatches when you need pixel controls: Canvas, and webGL which can be rendered to a Canvas. The only difference is that they're not the core that HTML is based on. This is on purpose, because using Canvas should be very rare. You should embed your (rare) pixel-based rendered component into an HTML tree with appropriate non-visual markup around it to describe what it is and what it does.

Pixel-level render targets are a design antipattern for most apps. Not all apps (games for example), but the vast majority of them.

To me this isn't a design thing -- it's a purely practical decision. Your app state needs to be accessible to people, people need to be able to build on it, programs need to be able to parse it and manipulate it, it needs to be responsive when high-definition displays or Apple Watches come out in the future, and it needs to degrade gracefully when parts of the browser stop working. We've been able to observe for a long time that apps that are built this way are better for end-users.

In the browser, text is your pixel. Of course you are welcome to build things on top of that with CSS, images, and Canvas. More to the point, I'm not saying that 95% of the time you should abandon your design and make a minimalist terminal interface -- I'm saying that for 95% of the phone apps and native apps I see, HTML would be fine. There is a pretty good chance the design someone has come up with is already representable in pure text, and they just haven't thought hard enough about how to do it. I'm not saying design everything minimalist, I'm saying your design is probably already a lot more minimalist than you think, and it probably wouldn't be that hard to separate content from pixel-positioning and style for most apps.

> It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage?

Have you not worked in tech long? One of my 'favourite' things about one tech stack I once worked on was that someone decided to implement a file-system inside the a database that is stored on the file system. Even better, the database itself effectively just reimplements the features of a database.

So we have a file-system storing a database that exposes a completely different database that holds a file system.

That's not really relevant to the suitability of WASM in hardware, though. uops are an implementation detail of microarchitectures; even if you do not introduce the uop design into your architecture, x86, ARM, etc ISAs are still efficient to implement in logic for a number of reasons. For example, instructions in a traditional ISA normally encode things like the register operands they reference as part of encoded instruction. The bits corresponding to the register operands are carefully designed to index into another piece of memory, the register file. This means decoding the operands from an instruction and referencing the relevant registers is extremely cheap in hardware, because you simply slice a few bits out of an existing wire and do a lookup/relative increment/whatever. Similarly, things like relative jumps are encoded directly as offsets that get added to an instruction pointer, which again is extremely cheap.

In contrast, WebAssembly would be a terrible project to implement directly in logic; there are no relative offsets so incrementing an instruct pointer register simply doesn't work, which hardware is very good at. fn calls are referred to by name indexed into a table at the bytecode level, so you're inherently dealing with a level of indirection that would require 'flattening' or inlining the table values to work around before being executed, or, alternatively, you'd have to just bite the bullet and put limits on their size, and eat the cost of the indirection. Similarly, CFG blocks in WASM are represented as literal scoped blocks with nested instructions at the syntax level -- not simple jumps/calls. You need to extract the back/forward edges from the CFG to recover that information and translate it to direct jump operations.

At this point, you are just implementing a compiler, and if you choose to do it in hardware, you are willingly trying to shoot yourself in the foot (or the face), and it will end badly. You're far better off calling a spade a spade and compiling, in software, to a representation that actually can be implemented efficiently in hardware. But you could of course hide this compiler in the firmware to make it "seem" like WebAssembly is the native ISA, and the small surface area of the specification can help ensure you do it safely and correctly. This is probably for the best anyway, because it's dramatically harder to design correct hardware vs correct software.

The benefit would be not just a different language but the entire .NET ecosystem. If that ecosystem holds no compelling benefit for you, then I guess nothing. I was just answering OP's question looking for a concrete understanding of what wasm could do.

I found this [1] quite interesting. It doesn't really answer any of the questions you asked, but I think it gives some interesting insights into WebAssembly, which might make it easier to put other things in context and also give a good low level understanding of it.

It's the closing keynote talk at this year's PyCon India. From the description:

> In this talk, I live-code a simple stack machine and turn it into an interpreter capable of running WebAssembly. I then use that to play a game written in Rust.

https://www.youtube.com/watch?v=r-A78RgMhZU