Wasmer 1.0

Replicating a significant fraction of the functionality of a browser ends up being a lot of code and data. For a web-like experience with instant navigation between apps it will be necessary for these shared libraries to be really shared, as in almost all apps use the same libraries and the same version of those libraries. Otherwise you'd be downloading and unpacking and JIT compiling dozens or hundreds of megabytes of code and data before you could display a single line of text, every time you click a link to a new site. The linkable nature of the web would be lost. (Yes, many websites are dozens of megabytes already, but the bulk of that is delay-loaded and happens in the background after the initial content is displayed).

In order for the standard libraries to be actually shared, everyone would have to agree on the standard libraries to use, and the standard libraries would have to be designed to be backwards compatible so that older sites could be force-upgraded to use newer versions. This is essentially the role that browser updates play today. But the browser evolved over decades and it's not clear how you'd get everyone to adopt a new set of standard libraries today, nor how you'd get everyone to agree on what functionality to add over time (the role that W3C plays today).

For libraries outside of the standard set, it sounds tempting to allow them to be shared too. But this is actually an unavoidable privacy violation. If you have a shared cache, then any app can discover the set of previously loaded libraries with a timing attack, thus revealing information about the user's browsing history. This is why all browsers are now moving to partition all caches by site: https://www.jefftk.com/p/shared-cache-is-going-away. Even if multiple sites reference the same wasm blob, it must be downloaded and JITed separately with no sharing.

As I said, I like the vision of a tiny low-level runtime executing shared libraries inside a sandbox. But I'm not sure how it could be done in an efficient and privacy-respecting way if you want to replace the Web with it.

Browsers have been picking up the slack where OS and desktop developers have fallen down. The OS is supposed to handle process isolation and resource access, but here we are. Tabbed browsing became a thing because GUI toolkits didn't do multiple app instances (or MDI) in a way people liked.

Not just about performance.

> Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI.

Not probably, but definitely

> But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones.

Yeah, no. Games have had UI scaling since monitors got more resolutions than 640x480.

The reason why the web is horrible at UI performance is simple: it was never built for UIs. It is, at its core, a system to display simple texts with a few images in between, and that's it.

Look at the sad state over at https://csstriggers.com. Setting text shadow will cause a full-screen reflow. What does this have to do with "flexibility baked into its bones"?Nothing. If anything, it's entirely inflexible. Same for any type of animation apart from a handful of css transforms: touching any part of an element will cause a full-age reflow (and that's why animating `height: auto` is one of the web's holy grails). This has nothing to do with "changing screen size or the input type". The web was never built for this, and anything outside simple-text-plus-a-few-images is just a bolted-on hack that barely works.

> all sizing and positioning is determined automatically based on rules, which can be expensive to calculate, but is what makes it so robust.

iOS uses a significantly more complex system layout constraints not dissimilar to Cassowary. Cassowary was proposed for the web in the late 1990s and was rejected because it was considered to be too expensive to calculate on the hardware of the times. The vast majority of the web was designed with one goal in mind: avoid expensive calculations. To the point that the actual algorithms to decide how to layout and draw stuff are specified in the standards. And the core of the web is designed around ... a single pass. The first time an allowance for two passes appears is for some stuff in tables (was it vertical alignment?) in early 00s.

And the actual complexity on the web comes from the fact that it was never designed for any of this stuff. And, of course, there's no robustness to speak off. Even looking at the web sideways will break it in innumerable ways: from the fact that just asking for an element's size will cause a full-page reflow to inability to properly encapsulate anything.

> Qt still exists. It's still being actively developed and still gets used for some modern software.

I know it still exists. What I was saying that Qt and Delphi in early 00s and TurboVision in 1990s had tools that surpass anything the web has to offer today. Which is not unusual, because they were developed as UI frameworks/libs/tools. Unlike the web. It can barely display a simple page with text and images, and now we've built an unholy mountain of hacks on top of it.

The web is the first and only UI system that lacks any and all tools to actually build and customise a UI beyond a very restricted set of badly interconnected very rigidly defined primitives. Where any UI lib/framework gives you a rich set of complex controls, the web gives you a few form elements with little to no functionality. Where any UI lib/framework gives you a plethora of tools to design/change any control or primitive you want (going as far as letting you redefine your own paint functions), the web gives you nothing.

I keep repeating this in various comments, but: there's a reason why most CSS/UI frameworks on the web repeat the same handful of primitive elements: a badge, a text input, a button, a breadcrumb, an avatar. Because that's all you can do in any reasonable amount of time. Very very very few attempt a date picker or a complex dropdown (inevitable with significant a11y issues). More complex UI elements like virtual lists, tree views, master-detail sheets, proper data tables, truly complex layouts where you can actually mix and match any and all components? Ahahahahahaha. And of course, nothing even approaching visual editors of early 00s because they are simply impossible on the web.

> But the web works pretty well for all types of applications.

The web performs poorly for any type of application and performs barely well enough for pages.