We've been doing SSR all along, folks: server side templates.
Yeah, HTML was pretty hamstrung as a hypermedia, which made for mediocre UX, but that's been fixed by libraries like unpoly, hotwire, or, my own, htmx.
Is this condescension really necessary? I don’t think it helps the discussion generally, but particularly from authors of libraries in a similar space with a different approach. Lots of others in the space, many whose work would likely get a similar reaction, are quite welcoming to competing approaches and even speak highly of them.
That said, I think you might want to consider looking more closely at how Qwik works. It produces markup metadata that’s not dissimilar to what I see in htmx. I don’t know if it’s a direct inspiration, but that similarity seems particularly odd to dismiss so bluntly.
The major philosophical difference between the two is the authoring experience: Qwik annotates the HTML with a compiler, in htmx it appears the expectation is you write the annotations directly. Qwik’s server side templates just happen to be authored as JSX components. Both are completely valid! Probably more a matter of preference than anything.
Personally, I prefer the Qwik approach. But I welcome yours as well and encourage people who would prefer it to choose it. Both are significantly better, in many cases, for users than the current outcomes from many other frameworks which appeal to the devs Qwik is targeting. Isn’t that also welcome given the state of web dev today?
Hey, thank you for this response though! It’s much more what I like/hope to see in the ecosystem. Also I’m an old curmudgeon so I relate, and sometimes need a nudge to turn the contrarian knob down to friendly :)
htmx is the first thing that’s made me feel like I can build a useful front end again in years. Plain server side rendering of templates and a bit of sprinkles on top. It’s awesome and thank you!
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.
I built my startup on elixir. Its allowed us to do things in days that would take weeks in nodejs. Absolutely fantastic system overall. biggest gripe is that its hard to hire for.
You didn't address my last points but I'll still address this comment.
> this very sentence sounds absurd
Which part? "hydration", "improve the initial load times", or "PWAs"?
Let me rephrase if you are confused. It renders a snapshot of the app on the server so when you first load the web app it's rendered already. Then the client picks it up from there. It's completely optional to do this.
> how many websites out there need to work offline?
Are you asking if it's useful to have access to information and entertainment offline? For me the answer is yes.
It depends what you are making, but yes I think you should strive to make things work offline if you can.
Also websites can work offline without CSR. That's not really what this is about.
Hydration is about improving initial load times of CSR. I really don't know how to simplify this further.
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.
That said, I think you might want to consider looking more closely at how Qwik works. It produces markup metadata that’s not dissimilar to what I see in htmx. I don’t know if it’s a direct inspiration, but that similarity seems particularly odd to dismiss so bluntly.
The major philosophical difference between the two is the authoring experience: Qwik annotates the HTML with a compiler, in htmx it appears the expectation is you write the annotations directly. Qwik’s server side templates just happen to be authored as JSX components. Both are completely valid! Probably more a matter of preference than anything.
Personally, I prefer the Qwik approach. But I welcome yours as well and encourage people who would prefer it to choose it. Both are significantly better, in many cases, for users than the current outcomes from many other frameworks which appeal to the devs Qwik is targeting. Isn’t that also welcome given the state of web dev today?