Great article! A few points I’d like to challenge:
But what if the framework was built on SSR in the first place?
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.
But perhaps the first to realize the idealized hydration execution.
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.
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.
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. 😄
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.
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. 😄