When Misko Hevery (creator of AngularJS) approaches you to look at his new framework, well, you stop and listen. I was already aware of Qwik and sa...
For further actions, you may consider blocking this person and/or reporting abuse
Great article! A few points I’d like to challenge:
Sveltekit is a framework designed from the ground up with SSR at its core! I think that’s important to note considering the statements following that quote.
I thought this was called Partial Hydration - and not really a new thing. Astro has been pioneering this with their Islands Architecture. The Svelte community has had this for years with Elder JS.
Or perhaps I’m misunderstanding the difference?
Sveltekit sure.. but not Svelte. I mean at the actual mechanical framework level. Like how they handle rendering and hydration. Not the extra dressing that the metaframework adds. Sveltekit is great but there are mechanical differences in Qwik based on this assumption of server first. Certain decisions not present in Svelte.
Sort of. Partial Hydration has existed for a long time. The earliest trace I found is Marko from eBay back in 2013/2014 period about 6 years before anyone else. But even with common partial hydration today for the parts that are hydrated they still run top down. Basically the islands are like their own apps and follow the traditional flow. And you can't nest them (although you can pass "server components" in "client components"/islands through child projections).
What Qwik is doing actually changes how hydration occurs. It actually does less work at hydration time (only attaches event handlers), and it can break things apart beyond the island level. It can hydrate child before parent.
To be clear other frameworks (like Marko) are working on the same space but this goes well beyond what Astro or Elder are doing. If I sound critical I'm not. I think Astro and Elder are great, and I push Astro a lot with my UI library SolidJS. But it is incredibly difficult to take an existing framework like React, Vue, or Svelte and do what Qwik is doing. You'd need the core framework to change its behavior.
Do you know about Opa?
opalang.org/
From 2011. 😄
This went way beyond just partial hydration - you basically just wrote programs, and the compiler would "slice" client/server concerns for you.
It was quite revolutionary at the time, I think - but for some reason was largely DOA with practically no one paying a lick of attention.
Years later there was Meteor, which has some of that, and suddenly everyone was like ooh yay isomorphic JavaScript wooh.
I think it was way ahead of it's time - and I actually loved the idea then.
In my opinion, these new tools don't go far enough. And I know that may seem like the opposite of what I was saying the other day, but the thing is, if there was a language that gave you all of this as part of the language, not just another framework with all the limitations of an existing language - I think that's cleaner and more interesting than mangling the semantics of an existing language to accomplish something that's not quite as good and will likely be superseded in another 6 months. 😄
It’s amazing and admirable that you are able to write such a neutral and unbiased review of a web framework, considering you are the author of a competing web framework yourself.
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.
Nice write up.
How does Qwick compare to htmx they sound like they are similar?
Happy coding
HTMX is a mechanism to piecewise server render. Where Qwik is a way to piecewise hydrate. The difference is that once in the browser Qwik doesn't go back to the server for things that don't need to go back to the server. So something like HTMX scales perfectly in that it just needs a small runtime and then everything runs on the server as needed. Click a button, replace part of the view. Click it again and go to the server and replace it again. You never need any more JavaScript.
Qwik on the other hand request some JavaScript when you click that button. And that JavaScript will render the new content in the browser instead of going in the server. And when you click the button again, well it already has the code so it updates immediately.
Basically the main difference in premise is that client rendering tends to be faster than server rendering when you already have JavaScript in the browser. Qwik focuses on how to take an already server rendered page and load the JavaScript as needed. HTMX is always going back to the server even when it otherwise wouldn't need to.
Now that being said in an ideal world Qwik would use HTMX approach for big changes like routing. When you need to swap out 80% of the page then lets go render on the server, as more than likely we needed to load new data etc... But for the micro-interactions keep them fast and performant in the browser.
The more subtle difference is when you consider the way you author. Now I'm sure someone could extend HTMX page and add some client side interaction and JS on top and also get the sort of best of both worlds scenario I'm talking about. However with Qwik you just build the whole app like it s a declarative stateful app like the way you would with React and this just happens. In our hybrid HTMX example we'd be using a combination of hand crafted JavaScript and mechanical directives that HTMX provides. This means for a very different sort of developer experience.
🙏 Awesome write up!
I guess every event handler will be executed in the microtask since it came from `await import()'. I wonder what would happen if I run physics engine computation on mouse click 🤔
(normally it should be run inside a webworker but running in the main thread give a better startup time)
How we cut 99% of our JavaScript with Qwik + Partytown
Partytown and Qwik are both projects at BuilderIO. Going by a recent interview they have every intention for Qwik applications to leverage web workers to immediately download and run the heavier parts - restricting the main thread to only what is essential to support the UI.
Earlier in that same interview:
"... at some point you know the client might go back to the server and say like did any of these things change or i'm deleting one or whatever right and that's up to application to kind of figure out how that that works.
How do you dictate that in Qwik?
You don't, like that's outside of the responsibility Qwik you just have data, you just have objects".
The implication is that Qwik isn't running the entire client side application but that Qwik is focused entirely on the UI aspect and its supporting state - so "the rest of the client side application" could partly or as a whole be running on a web worker.
Here is a simple scenario in gamedev (with parallelize ECS) where you don't want to lazy load the event handler nor put them in the queuMicrotask
"If you have components that contain other components and pass props throughout things need to run top down."
If you run into this situation you need to rethink your approach.
Also all this seems very familiar with Svelte/Sveltekit. IMHO it's just the same thing, but with a different name...
It is how every SPA framework works. React/Svelte/Vue/Angular/Solid/Lit you name it. And how every metaframework built on them works Next/Remix/Redwood/Nuxt/Sapper/SvelteKit/Universal/SolidStart. Things like Astro/Iles/Slinkity/Elder/Marko optimize over that model with partial hydration, but Qwik is the only shipping resumable today of known libraries.
There is comparison of two approaches: resumable hydration vs offline first.
youtu.be/N-QkXQh-TOk