Hydration is pure overhead

Isomorphic (the same js libraries on the server & client) software is also nice. With WASM, it is possible with other programming languages, though js/ts has a large head start in the isomorphic web space.

Not that irrelevant.

Traditional SSR involved a separation between templates which contain presentation logic, and controllers for mediating business logic, persistence etc.

If your backend & frontend are in same language, or you use template engines with implementations in mutliple language like handlebars/pug/soy etc. you could easily render the same templates using JS and your client side can have as much ui state, interactivity etc. as you want.

If we adopt incremental enhancement then the fetching of templates can be delayed - we primarily need the controllers which handle dom events to make the server-rendered ui interactive. This is easily achievable through libraries like stimulus where controllers can add complex interactivity to server rendered templates and re-render them if needed through templates which are fetched on demand. We can even preserve form element states by using libraries like morphdom for swapping content.

However, what really breaks down all of the above is the concept of components as popularized by React etc. When we start writing react-style components then our rendering logic and associated behavior are tightly coupled and we need to pull in all the rendering logic for enhancing the server rendered content. React devs like to preach that traditional separation of concerns is not useful in practice and it is better to have rendering code colocated with behavior - but solutions like this just demonstrate that this separation did actually have some merit albeit at the cost of some indirection.

What solutions like Qwik are attempting to do is enabling folks to keep writing component oriented code but now we need a fancy compiler tooling that deeply integrates with the stack. The approach does have its merits but it is just one path to address the problem.

While we are on the topic of browser event handlers and "embracing how browser actually work", I can't help but mention that the builder.io website's top navbar cannot handle ctrl + clicking (for opening links in a new tab).

It's actually quite subtle. Sometimes it works, sometimes it doesn't, depending on which page you are on, what you've already clicked, etc. All part of the fun of frontend web development, ain't it?

that makes sense, so if you're using http caching appropriately the server side "render" or running of the javascript happens on the first visit and then infrequently thereafter.

Generally speaking, if you approach qwik.js from a 10,000 mile view like you'd normally approach other frameworks, you're going to miss the trees for the forest. One of the axioms where this framework is coming from is the idea of providing React-like developer experience, so yes, there's going to be templates expressed in JS.

Where it gets technical has to do with how the JS gets delivered to the browser. It starts with a small bootstrapping that sets up event delegation, sort of like `document.documentElement.addEventListener('click', becomeAwareOfClicks)`. This happens literally on the first chunk of HTML being streamed in, meaning that the framework is now already aware of clicks happening anywhere in the app, even before HTML is available in JS.

Eventually some HTML will stream in with an attribute that indicates how a click event on an element should be handled. The framework can then quickly determine whether it needs to "hydrate" that event handler: a) if the event was captured by `becomeAwareOfClicks` and b) the intersection observer deems that element is visible and available to DOM manipulation, then c) it can download the relevant handler, meaning it triggers business logic at latest as soon as the intersection observer downloads the handler.

Note that at this point, no other JS has downloaded yet. Eventually it does download it, like every other framework, but the key point is that it can respond to events with actual business logic before the rest of the JS comes down the pipe.