DEV Community

Discussion on: Resumable JavaScript with Qwik

peerreynders profile image

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.

mindplay profile image
Rasmus Schultz

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.

Thread Thread
peerreynders profile image
peerreynders • Edited on

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 - 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.