Maybe we could give the rendering engines catchy names like Shockwave, Flash, Silverlight, and JavaApplet. :)

You can barely trust a typical Web site to run Javascript in your browser without leaking personal information to God knows who. I'm not going to trust them with a full-blown rendering engine.

Once people can run JavaScript and WASM in a sandboxed environment (the browser), you might as well give them the ability to run a rendering engine. There is nothing magical about rendering engines.

Comparison with Flash et al. is not accurate anymore, since these ran in an unprotected environment. Also, they were cumbersome install whereas WASM apps don't need installation (but can live in a cache if desired, and could even be shared among websites).

"Cumbersome installs" and "unprotected environment" were not why people hated Flash. People hated flash because it couldn't be {scraped, crawled, searched}, broke elementary browser controls like copy/paste and the back button, resulted in laggy and clunky UIs, and was excessively heavy on bandwidth. All of this would apply just as much to WASM 'apps'.

Fundamentally the problem is the conflict between the browser as an 'app' platform and the browser as a document viewer. Put simply, would you rather your user interface be 1) a magnificent piece of software with thousands of man-years put into it, debugged over decades, where every use case has been meticulously considered, or 2) a shitty script written by an overworked web developer?

And am sure this will happen. At some point websites will start shipping rendering with webasm. I am it keen on the details but a well done one could use a canvas to do the rendering.

As a anadotal. We can already fo to websites that run vms and emulate old operating systems. I dont this it is far fetched to run a web browser in a web browser.

Unfortunately that destroys accessibility. If you want to support accessibility, then you need a more complicated rendering target than something like a canvas.

It will for a bit. The people who build UI frameworks in wasm will either make it a priority or they'll add it later.

It sucks but this is the way we're heading. I'm not sure web devs will even be writing HTML in 5 years beyond adding a canvas tag.

With modern ML, that is not true. For example, a browser could easily run OCR on the frame-buffer and read it out loud.

In fact, the approach would be more general, since a lot of text is already embedded in images on a lot of websites (think also about ads).

In other words: "Print the file, send the printed sheets by fax to the remote office, once received, OCR them and save to a file"

Not to mention that there's no such thing as "Easily run OCR", considering how many weird fonts there are, and that they could be rendered in such small size as to make it difficult even for humans to tell them apart.

If you look at any platforms accessibility APIs, there’s a lot more to it than just exposing text.

The simplest example: how do you indicate a graphic or piece of text is a button or link? How do I set the alternate text if it’s a graphical button.

The render engine still has to do that. But that isn't much different from how it works now, where the website has to provide the necessary information.

Besides, nobody says we can't have a protocol for some additional accessibility information.

And then somebody says "how about we abstract this into some kind of markup language?" and we've come full circle.

A common markup language would be great! As long as we use it in a way that keeps us far away from compatibility problems.

But you have to make it extendable because you can't predict every possible use-case. So some kind of Extensible Markup Language, perhaps.

Maybe we make a sort of 'hyper' extension that comes with all kinds of baked in behaviours, so that we don't have to implement that behaviour ourselves when we deserialise it.

That's a good idea. Maybe we need a series of standards but all based on some kind of Standard Generalized markup.

You only get away from compatibility problems if either:

1. No-one uses it

2. There is only 1 implementation, and it is never updated

> For example, a browser could easily run OCR on the frame-buffer and read it out loud.

And then we wonder where all the software bloat comes from.

This can already be done today through canvas & webgl, or through clever combinations of DOM + JS + CSS. You can control every pixel that's rendered to the screen through the browser.

So why doesn't everyone roll their own? Some issues:

  - footprint - that whole runtime has to come across the wire just to render "hello world"
  - javascript's single-threaded tendencies make perf a big challenge
  - text rendering [this happens to be the thing the document-focused Web really excels at]
  - text semantics [SEO]
  - gigantic implementation effort [custom engines RARELY make sense even for the demands/budgets/returns of AAA games; how many websites justify this kind of investment?]

Yeah, that's because it's not really supposed to be used for that. Every single one of these is solvable if they wanted to support this use case. Ad footprint and implementation effort - of course there'd be just a few major ones that'd be cached at client side. Ad2 implementation effort, we can simply compile Qt or Gtk to WASM; it even works today, it's just slow because of platform limitations. This'd be used for applications primarily, document-oriented pages could stay HTML/CSS and HTML/CSS could be simplified thanks to complex web apps turning to other means.

That is a horrible idea. How many of them are going support Chinese, Korean, Thai, Japanese, and Arabic? If all you're supporting is English it's easy. As soon as you go international it's extremely hard to handle all the stuff you're unfamiliar with and shutting out people because their names isn't ASCII is not very inclusive.

So Gtk, Qt, Cocoa, Winforms, all of these are too hard to do? We can literally reuse (some of) these, all it takes is compiling them to WASM, it was already tried and it works, it's just slow due to current platform limitations.

There’s actually no reason the web couldn’t have been made of hyper-PostScript. Imagine how slick that would be.

This approach has a long history. Of course the rendering engine was running server-side.