"I'm wondering if there is a more holistic approach."

The end game, once WebAssembly is fully integrated into the browser, is to expose the 3D API and/or a high-performance low-level 2D API (or both) and slowly, but surely, a "web browser" will become an environment where you download a full rendering engine for a website, written in an arbitrary language that has WebASM support, and in the end both DOM and JS will become merely another option, at which point IMHO neither of them will actually fare very well, excepting their substantial existing install base. Caching will make this feasible as most of the "long tail" isn't going to make their own engine, just use someone else's, and there aren't really all that many sites who can afford to write their own.

While I consider the forces pressing on the browser to virtually predestine this outcome, it is at least 10 years off.

(If it wasn't for the fact that Javascript is still not fast enough to pull this off, I think we'd already see more frameworks that do layout and ship down a lot more divs and such with hard-coded absolute positions, turning the browser into an environment where it simply puts text and images where the server tells it to, and stops doing all this expensive reflowing and layout. You can see on all kinds of sites the desire to do this on the part of web publishers. However, it is impossible to do this on the server side because you need access to font metrics (where you may not be able to force your own), screen size info, browser zoom level, and a whole bunch of other such things that make it impractical to do server-side in a whole bunch of ways. But JS is still at least ten times slower than native code here, plus would take an inevitable penalty accessing a lot of FFI code, so this is currently almost unthinkably infeasible on the client side.)

Unsurprisingly, something along these lines has already sorta been tried [0][1]:

> Famo.us is the only JavaScript framework that includes an open source 3D layout engine fully integrated with a 3D physics animation engine that can render to DOM, Canvas, or WebGL.

They raised a fairly large amount of money, but eventually dropped the idea and moved to a totally different market [2].

Grid Style Sheets [3] gets an honorable mention as well. It compiled GSS rules and applied them as fixed position divs.

I've been researching this subject a bit lately. Surprisingly, many of these problems were already solved in the native world by the end of the 90s. The key innovation from the web is that it's a fully sandboxed environment.

Despite all the web's flaws, one area in which it has done pretty well is accessibility. Many native apps leave a lot to be desired when it comes to basic accessibility... Heck, that goes for many "modern" web apps as well. Hopefully browsers expose good accessibility APIs by the time your vision of developers shipping their own rendering engines becomes reality.

[0] http://deprecated.famous.org

[1] https://github.com/famous/famous

[2] https://techcrunch.com/2015/11/06/nopen-source/

[3] https://github.com/gss/engine

As always, the fantastic Gary Bernhardt takes this through to its logical conclusion https://www.destroyallsoftware.com/talks/the-birth-and-death...

First, while presented humorously, I take it somewhat seriously as well. And one place where I disagree with it is that unless you consider WebAssembly as Javascript, it isn't true. It isn't Javascript destined to take over the world, it's WebAssembly.

You will know WebAssembly is here and in charge when the browsers compile Javascript itself into WebAssembly and take at most a 10% performance hit, thus making it the default. Call it 2022 or so.

James Mickens presents something like this idea: https://www.youtube.com/watch?v=1uflg7LDmzI

Yes, I had the pleasure of seeing him present that live once, though not at that one. I think he was disappointed that people weren't helping him work on it, but I still think that long term the pressures are absolutely inevitable in that direction. It's just that the world at large can't jump there in one shot, it has to get there one very laboriously-worked-out technology at a time first. He's gotten a bit more famous for his sense of humor, but I can attest that he knows his stuff.

It's a very persuasive idea. I also wonder whether Atlantis's stripped-down API could enable a lighter alternative to Electron.

Yes. This Elixir library aims to have a virtual DOM on the server and send minimal diffs to the client: https://github.com/grych/drab

It can already do this for some kinds of diffs, but it doesn't have a full VDOM yet. It basically allows you to build interactive pages without writing any javascript.

Drab is one of the most interesting and impressive libraries to emerge from the Elixir/Phoenix ecosystem.

N2O[0] does exactly that. You write your app in Erlang and the framework delivers the changes via websockets to the browser. You can even choose to have the changes computed in the browser through an Erlang -> Js bridge. Pretty cool.

[0] https://github.com/synrc/n2o

This looks great, I'll try it out!

> DOM diff-ing on the server and have the thin client only transfer the changes. This would hopefully make the initial payload extremely small and the changes being transferred minimal as well.

To achieve similar results, you could granularly partition the build so that scripts are lazy loaded as needed. This would be like sending diffs, except only once since the client can reuse them.

Having a server manage the DOM state of every client, and maintaining sockets between them, seems like a complex apparatus.

I made a proof of concept for such a framework. There are some really cool benefits (like automatic server side rendering, really small js bundle, all code on the backend etc.) but falls short for things that require immediate response, such as drag/drop, or text input.

I once wrote an app that worked by sending diffs, not DOM diffs but JSON diffs which were then applied by the client and rendered by React.

The data store was a repository, and so a client could ask "please give me the diff between states X and Y", and the server would make a diff between those trees in the repository.

Most of the time the client would be long-polling for a new revision with the diff based on the previous one, which could be cached efficiently, but sometimes a client would come back from "hibernation" and ask for a diff based on an older revision.

It was a nice system, I never tried to make it "scale" though.

Meteor is a little that way although it doesn't DOM diff on the server. It kind of diffs the Mongo database on the server and then updates mini Mongos in the clients where appropriate. Js in the clients then update the DOMs.

Seaside from Smalltalk. To some extent the original ASP. There is also a PHP framework that does that, but I forgot it's name.

I've built some prototypes like this, predating web sockets though. Web sockets are simply an optimization over standard form submission.

The problems of state management are the same though. If your protocol isn't stateless, then you're restricted in how you can manage the server, ie. no live upgrades without breaking all clients.

Not exactly the same but you might want to check out Ur/Web, Eliom and the standard Racket web server lib.

Like an X Server for the DOM? While interesting, that means that every communication would need to be tranfered to the server and there'd be no instant one-frame actions. That fits a limited set of UIs. And would lag with substantial network latency

I once saw a company that had a product which was basically JSF as network protocol for Swing.