But I've yet to encounter a project that actually needs this, or SSR in general.
Most projects have maybe 2 or 3 page types with mixed static and interactive content - and typically, those pages are mostly static with a few interactive elements, none of which tend to be important for SEO.
Take your typical e-commerce site - your product listing or product detail page is mostly static, with a few interactive elements that generally aren't relevant for SEO. Then you have some informational pages with nothing interactive. And then your checkout pages and maybe a contact form with nothing SEO relevant on them at all.
Maybe this is just my personal experience, but the projects I've seen in 23 years of experience, for the most part, fairly naturally partition into client or server rendered, or mostly server rendered with some interactive elements with no SEO relevance, so...
What's the problem?
Just render those few pages with mixed static and interactive content without the interactive bits, and sprinkle those on the client side - the way it was always done before SSR.
Like, who is this for? It seems like these solutions are mostly engineered for developer feel-good and some idealistic principle about insisting on a single source.
But why? Why is that important?
Why is it even considered a good thing? Maybe it's actually better to have some logical, physical and mental separation between static content and interactive islands within that content. We could call this "separation of concerns", haha. 😉
No, but seriously. I get it. I understand what you're doing - I understand why. I'm just not sure I agree that the problem is large or important enough to even bother solving.
Can you point to a site where static and interactive content is so intertwined that any of this substantially pays off?
Other than maybe facebook.com (the biggest and messiest example I can think of) who really needs this? 🤔
Just render those few pages with mixed static and interactive content without the interactive bits, and sprinkle those on the client side - the way it was always done before SSR.
There is nothing wrong with that style of development but if one steps back for a moment and surveys what has been going on over the last 15 or so years then (with the benefit of hindsight of course) it's almost inevitable that something as ambitious as Qwik would be attempted given the emerging realities of the mobile web.
The whole CSR-based SPA movement was a drive from the document web towards the application web (whether the problem being solved required it or not). However many pure-CSR solutions suffered from delayed first contentful paint (trying the visitor's patience) leading to the introduction of SSR.
Unlike dynamic server rendering SSR dictates JavaScript on the server side because it has to run the JS-based client side framework in order to render the HTML. Of course being more "application like" something else gets rendered: client side application state - and combining both the application view (HTML) and the state client side lead to the concept of hydration (which at times lead to false expectations).
Now generating client side state on the server side wasn't anything new; it's a well established practice that was a known tactic even in the jQuery era but in most cases it was simpler to "just" make some initial calls with the existing AJAX functionality rather than having to manually add and accept the additional complexity of "hydrating" client state directly from the HTML.
With SSR technologies "hydration" was automatic requiring no intervention by the developer. But "hydration" comes at a cost that can vary wildly depending on the underlying client side framework leading to the "Uncanny Valley" - the time where content is visible but not interactive.
Once again, the solution to the problem only changes the problem.
The obvious answer was to ship less JavaScript in order to minimize the uncanny valley and that's exactly what Svelte and Solid did. Among other measures both used compilation tools - unlike the established frameworks which tended to often rely on runtime solutions both Svelte and Solid reduced their runtime code output by doing work at compile time whenever possible. But in the end even those applications are monolithic affairs, so short of any manual bundle splitting to arrive at some critical core (akin to critical CSS), the whole application has to be downloaded and parsed before it can become interactive.
This is where Qwik comes in as it attacks the monolithic nature of client side JavaScript. By design the HTML and UI state is server rendered and shipped to the browser but the included (tiny) loader will only download compact JS bundles on interaction to support that particular interaction (progressive hydration) - it is gradually deploying the UI, only as necessary. There are also hints that Qwik will act much less as the center of the universe so it may be more suited to off-main-thread architecture.
Does all this sound incredibly complex?
Sure but in this case the complexity is in the service of addressing the uncertainties of the modern web when it comes to connection quality and client device computational capability. Back in 2010 Responsive Design emerged in response to the reality of unpredictable screen ratios and sizes due to the rise of the mobile web. Qwik is a phenomenon of the rest of front end development catching up to that reality as it impacts the remaining aspects of the web.
So Qwik isn't challenging the approach of "sprinkled interactivity" where that is sufficient but the assumption that "application-like" behaviour and feel will always require an SPA.
It's easy to quip about how we have now gone back to rendering HTML on the server. But these days the boundaries are very different. With PHP (1995) and Rails (2005) the boundary pretty much stopped at the server; it rendered pages and accepted submissions. jQuery made it fairly easy to use XMLHttpRequest in 2006 though AJAX was in use before that; servers would now also render data for the ad hoc consumption of page clients. Technically there is some strong coupling between the server and the client but for the most part there is a boundary between them.
I think it could be argued that in 2014 Marko (open sourced 2017) tried to to push the boundary from the server to envelop the browser - but at the time the rest of the world was too busy to notice while adopting SPAs.
So Qwik seems to be the latest attempt to view server and browser as part of the same system (application) while fully respecting the constraints of their separation/distribution. Now some might claim that Phoenix LiveView (2018), Laravel LiveWire (2019) and Rails Hotwire (2020) do the same (while being primarily developed in the server language) - but those assume availability of high bandwidth, low latency connections. Conceptually at least Qwik seems to be designed to work even when conditions are less than ideal.
Off topic: I think the above overview should give an impression of how different web development actually is from anything else. So whenever somebody predicts or hopes that technology X (current favourite: your favourite language compilation to WASM) will act as the great homogenizer to bring web development in line with native and backend development [1], I can only express my disbelief.
In my mind Qwik is an example of the outside of the box thinking that is sometimes required on the web to ensure that a certain class of solutions will work under most circumstances rather than just under the best of circumstances.
I'm just not sure I agree that the problem is large or important enough to even bother solving.
I think Qwik tries to get beyond the limitations of the current generation of SSR-SPAs perhaps in the form of an MPA. Whether or not any particular solution needs to be "app like" is an altogether different discussion; so far the SPA fashion trend seems to be continuing.
Heh, this should have been an article on it's own. 😄
Not that I needed it, thanks - I've been doing both front-end and back-end development since long before anyone even bothered making that distinction.
The whole idea of the "document web" versus the "application web" is completely silly to me. There is one web. It has documents and applications - but for the most part, it's documents with little applications here and there. If you insist on building those sites in application frameworks, of course you're going to need increasingly complex frameworks.
I dunno. It doesn't appeal to me. I like simple things.
If I'm building an application, I'll pick a front-end framework - if I'm building mostly-documents site, I'll use something for templating on the server-side.
Easy. I don't know why the trend is to find complex solutions to simple problems.
I'm sure there are a couple of projects that might need this, but in my opinion, there's no reason this or anything like it should be mainstreamed. Right tool for the job and all.
The whole idea of the "document web" versus the "application web" is completely silly to me.
Fair enough but as a page takes on more and more interactivity it becomes more and more "app like" and even though in 2014 Scott Jensen described applications as "technology tillers" with reference to the web a lot of the industry is continuing to chase the "rich user interface" experience (also [1]).
In my judgement it was the often reported jQuery spaghetti code that resulted from sprinkling too much interactivity on a page that pushed many developers to adopt pure client side rendering with the hope that it should be much easier to maintain given that the DOM is now entirely managed in one place - the client - rather than always having to go back to the server code to make the necessary adjustments to the various templates. So it could be argued the move to pure-CSR marked the beginning of the "application web".
no reason this or anything like it should be mainstreamed.
I don't think anything is being mainstreamed here. It's a development of interest against the background of Paul Lewis's observation six years ago and a change in direction from the status quo. If you look into the tweet thread:
"Paul, any examples of frameworks that actually play nicely with PR+B?" [2]
"No, and that’s my issue. Most (if not all) seem to expect all the JS up front before giving the user anything" [3]
In an earlier blog (2015) Paul Lewis aimed squarely at React to state: developer ergonomics should be less important than our users’ needs.
That message fell largely on deaf ears as evidenced by the continually growing JS payloads delivered to clients. "The network will save us" and "client devices are becoming more performant every year" are the typical excuses despite evidence that networks are at risk of becoming over subscribed and large numbers of less performant devices are entering the market while even flag ship devices are architected with a larger number of small, low power cores when the current generation of web technology requires peak single thread performance.
Back in 2016 there were some suggestions that FaceBook BigPipe and Drupal BigPipe were examples of "Progressive Rendering and Bootstrapping". (Perhaps Marko's introduction of async fragments in 2014 should at least count as "progressive rendering".)
So while Qwik emphasizes "Resumability" and "Progressive Hydration" it seems to embrace the "Progressive Rendering and Bootstrapping" approach which would likely be impossible to implement with the current generation of mainstream frameworks (Miško Hevery introduced the concepts in 2019). Interestingly during Qwik's development developer experience was only problem/priority #9 - echoing "developer ergonomics should be less important than our users’ needs".
I don't know why the trend is to find complex solutions to simple problems.
Now this is complete speculation on my part but Qwik is being developed at Builder.io - and they feature low-code services. Reportedly services like Wix, Squarespace and Webflow tend to result in fairly hefty JS payloads (likely requiring developer/engineering intervention to correct, defeating the "low-code" concept) which harms user experience. Qwik (or some derivative) could be the foundation for a low-code web site builder that has a performance advantage over those established services.
I see you aren't saying don't server render.. but rather why bother hydrating? Like Server render what you need on the server and then sprinkle on some client side JavaScript where needed interactivity.
Yeah this is mostly a developer experience consideration, but I don't think it is too far of a stretch. It is a bit like asking do you need to use frameworks, and the answer, of course, is no. Yet we still do. All of this is to allow authoring a single app experience and have it just work across the board. One that leverages declarative patterns for organizing code. There are organizational/scaling concerns too but not every project needs to worry about that.
It seems you are familiar with most the reasoning and in the same way I won't convince people who want to use Vanilla JS to do everything instead of using frameworks, I'm not going to convince you otherwise. All I got for that is, been there, tried that before, and wasn't completely satisfied. So let's see what else we can do.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting.
But I've yet to encounter a project that actually needs this, or SSR in general.
Most projects have maybe 2 or 3 page types with mixed static and interactive content - and typically, those pages are mostly static with a few interactive elements, none of which tend to be important for SEO.
Take your typical e-commerce site - your product listing or product detail page is mostly static, with a few interactive elements that generally aren't relevant for SEO. Then you have some informational pages with nothing interactive. And then your checkout pages and maybe a contact form with nothing SEO relevant on them at all.
Maybe this is just my personal experience, but the projects I've seen in 23 years of experience, for the most part, fairly naturally partition into client or server rendered, or mostly server rendered with some interactive elements with no SEO relevance, so...
What's the problem?
Just render those few pages with mixed static and interactive content without the interactive bits, and sprinkle those on the client side - the way it was always done before SSR.
Like, who is this for? It seems like these solutions are mostly engineered for developer feel-good and some idealistic principle about insisting on a single source.
But why? Why is that important?
Why is it even considered a good thing? Maybe it's actually better to have some logical, physical and mental separation between static content and interactive islands within that content. We could call this "separation of concerns", haha. 😉
No, but seriously. I get it. I understand what you're doing - I understand why. I'm just not sure I agree that the problem is large or important enough to even bother solving.
Can you point to a site where static and interactive content is so intertwined that any of this substantially pays off?
Other than maybe facebook.com (the biggest and messiest example I can think of) who really needs this? 🤔
There is nothing wrong with that style of development but if one steps back for a moment and surveys what has been going on over the last 15 or so years then (with the benefit of hindsight of course) it's almost inevitable that something as ambitious as Qwik would be attempted given the emerging realities of the mobile web.
The whole CSR-based SPA movement was a drive from the document web towards the application web (whether the problem being solved required it or not). However many pure-CSR solutions suffered from delayed first contentful paint (trying the visitor's patience) leading to the introduction of SSR.
Unlike dynamic server rendering SSR dictates JavaScript on the server side because it has to run the JS-based client side framework in order to render the HTML. Of course being more "application like" something else gets rendered: client side application state - and combining both the application view (HTML) and the state client side lead to the concept of hydration (which at times lead to false expectations).
Now generating client side state on the server side wasn't anything new; it's a well established practice that was a known tactic even in the jQuery era but in most cases it was simpler to "just" make some initial calls with the existing AJAX functionality rather than having to manually add and accept the additional complexity of "hydrating" client state directly from the HTML.
With SSR technologies "hydration" was automatic requiring no intervention by the developer. But "hydration" comes at a cost that can vary wildly depending on the underlying client side framework leading to the "Uncanny Valley" - the time where content is visible but not interactive.
Once again, the solution to the problem only changes the problem.
The obvious answer was to ship less JavaScript in order to minimize the uncanny valley and that's exactly what Svelte and Solid did. Among other measures both used compilation tools - unlike the established frameworks which tended to often rely on runtime solutions both Svelte and Solid reduced their runtime code output by doing work at compile time whenever possible. But in the end even those applications are monolithic affairs, so short of any manual bundle splitting to arrive at some critical core (akin to critical CSS), the whole application has to be downloaded and parsed before it can become interactive.
This is where Qwik comes in as it attacks the monolithic nature of client side JavaScript. By design the HTML and UI state is server rendered and shipped to the browser but the included (tiny) loader will only download compact JS bundles on interaction to support that particular interaction (progressive hydration) - it is gradually deploying the UI, only as necessary. There are also hints that Qwik will act much less as the center of the universe so it may be more suited to off-main-thread architecture.
Does all this sound incredibly complex?
Sure but in this case the complexity is in the service of addressing the uncertainties of the modern web when it comes to connection quality and client device computational capability. Back in 2010 Responsive Design emerged in response to the reality of unpredictable screen ratios and sizes due to the rise of the mobile web. Qwik is a phenomenon of the rest of front end development catching up to that reality as it impacts the remaining aspects of the web.
So Qwik isn't challenging the approach of "sprinkled interactivity" where that is sufficient but the assumption that "application-like" behaviour and feel will always require an SPA.
It's easy to quip about how we have now gone back to rendering HTML on the server. But these days the boundaries are very different. With PHP (1995) and Rails (2005) the boundary pretty much stopped at the server; it rendered pages and accepted submissions. jQuery made it fairly easy to use
XMLHttpRequestin 2006 though AJAX was in use before that; servers would now also render data for the ad hoc consumption of page clients. Technically there is some strong coupling between the server and the client but for the most part there is a boundary between them.I think it could be argued that in 2014 Marko (open sourced 2017) tried to to push the boundary from the server to envelop the browser - but at the time the rest of the world was too busy to notice while adopting SPAs.
So Qwik seems to be the latest attempt to view server and browser as part of the same system (application) while fully respecting the constraints of their separation/distribution. Now some might claim that Phoenix LiveView (2018), Laravel LiveWire (2019) and Rails Hotwire (2020) do the same (while being primarily developed in the server language) - but those assume availability of high bandwidth, low latency connections. Conceptually at least Qwik seems to be designed to work even when conditions are less than ideal.
Off topic: I think the above overview should give an impression of how different web development actually is from anything else. So whenever somebody predicts or hopes that technology X (current favourite: your favourite language compilation to WASM) will act as the great homogenizer to bring web development in line with native and backend development [1], I can only express my disbelief.
In my mind Qwik is an example of the outside of the box thinking that is sometimes required on the web to ensure that a certain class of solutions will work under most circumstances rather than just under the best of circumstances.
I think Qwik tries to get beyond the limitations of the current generation of SSR-SPAs perhaps in the form of an MPA. Whether or not any particular solution needs to be "app like" is an altogether different discussion; so far the SPA fashion trend seems to be continuing.
Heh, this should have been an article on it's own. 😄
Not that I needed it, thanks - I've been doing both front-end and back-end development since long before anyone even bothered making that distinction.
The whole idea of the "document web" versus the "application web" is completely silly to me. There is one web. It has documents and applications - but for the most part, it's documents with little applications here and there. If you insist on building those sites in application frameworks, of course you're going to need increasingly complex frameworks.
I dunno. It doesn't appeal to me. I like simple things.
If I'm building an application, I'll pick a front-end framework - if I'm building mostly-documents site, I'll use something for templating on the server-side.
Easy. I don't know why the trend is to find complex solutions to simple problems.
I'm sure there are a couple of projects that might need this, but in my opinion, there's no reason this or anything like it should be mainstreamed. Right tool for the job and all.
Fair enough but as a page takes on more and more interactivity it becomes more and more "app like" and even though in 2014 Scott Jensen described applications as "technology tillers" with reference to the web a lot of the industry is continuing to chase the "rich user interface" experience (also [1]).
In my judgement it was the often reported jQuery spaghetti code that resulted from sprinkling too much interactivity on a page that pushed many developers to adopt pure client side rendering with the hope that it should be much easier to maintain given that the DOM is now entirely managed in one place - the client - rather than always having to go back to the server code to make the necessary adjustments to the various templates. So it could be argued the move to pure-CSR marked the beginning of the "application web".
I don't think anything is being mainstreamed here. It's a development of interest against the background of Paul Lewis's observation six years ago and a change in direction from the status quo. If you look into the tweet thread:
"Paul, any examples of frameworks that actually play nicely with PR+B?" [2]
"No, and that’s my issue. Most (if not all) seem to expect all the JS up front before giving the user anything" [3]
In an earlier blog (2015) Paul Lewis aimed squarely at React to state: developer ergonomics should be less important than our users’ needs.
That message fell largely on deaf ears as evidenced by the continually growing JS payloads delivered to clients. "The network will save us" and "client devices are becoming more performant every year" are the typical excuses despite evidence that networks are at risk of becoming over subscribed and large numbers of less performant devices are entering the market while even flag ship devices are architected with a larger number of small, low power cores when the current generation of web technology requires peak single thread performance.
Back in 2016 there were some suggestions that FaceBook BigPipe and Drupal BigPipe were examples of "Progressive Rendering and Bootstrapping". (Perhaps Marko's introduction of async fragments in 2014 should at least count as "progressive rendering".)
So while Qwik emphasizes "Resumability" and "Progressive Hydration" it seems to embrace the "Progressive Rendering and Bootstrapping" approach which would likely be impossible to implement with the current generation of mainstream frameworks (Miško Hevery introduced the concepts in 2019). Interestingly during Qwik's development developer experience was only problem/priority #9 - echoing "developer ergonomics should be less important than our users’ needs".
Now this is complete speculation on my part but Qwik is being developed at Builder.io - and they feature low-code services. Reportedly services like Wix, Squarespace and Webflow tend to result in fairly hefty JS payloads (likely requiring developer/engineering intervention to correct, defeating the "low-code" concept) which harms user experience. Qwik (or some derivative) could be the foundation for a low-code web site builder that has a performance advantage over those established services.
I see you aren't saying don't server render.. but rather why bother hydrating? Like Server render what you need on the server and then sprinkle on some client side JavaScript where needed interactivity.
Yeah this is mostly a developer experience consideration, but I don't think it is too far of a stretch. It is a bit like asking do you need to use frameworks, and the answer, of course, is no. Yet we still do. All of this is to allow authoring a single app experience and have it just work across the board. One that leverages declarative patterns for organizing code. There are organizational/scaling concerns too but not every project needs to worry about that.
It seems you are familiar with most the reasoning and in the same way I won't convince people who want to use Vanilla JS to do everything instead of using frameworks, I'm not going to convince you otherwise. All I got for that is, been there, tried that before, and wasn't completely satisfied. So let's see what else we can do.