Qwik is really interesting. Initially the page is rendered server-side, then sent to the page. But what happens is very unlike most we apps, which then have to re-run most of the app to hydrate:
> Qwik is different because it does not require hydration to resume an application on the client. Not requiring hydration is what makes the Qwik application startup instantaneous.
> All other frameworks' hydration replays all the application logic in the client. Qwik instead pauses execution in the server, and resumes execution in the client.
It stores state in the DOM tree in a way that lets it "resume" running. If you click a link, a top level handler can recurse down the page to find listeners. It can gather any extra state & on the fly spin up components needed by the handler.
In general I think the topic of serializing & exposing application state is a vast untapped trove of awesomeness that compsci could be mining. 9p is the best reflection we have. But we also see a steady stream of git-based data projects coming out, that also reflect the value of serializing your state in a valuable way.
The twist here of using serialized app state, baked into the DOM, to allow instant resumability is awesome. On-demand paging back in state is like live migrating a vm or user process, just an awesome feat that redefines the computing model in such a more open way.
More and more frontend frameworks are now somewhat mandating a server part. I know pretty much all(sveltekit, nextjs) say you can do static export, but docs are more focused to use with a server. IMO it appears like this is being pushed by cloud vendors sponsoring those projects.
If you want to build a plain old SPA, the new react docs pretty much have no info. Sveltekit docs discourages it. I have not looked much into vue, but it appears like vue does better here.
Qwik while has a static export, looks like you lose all the good parts of you don’t use a server.
I can certainly see the SEO and other good thing that comes with SSR but not everyone needs it.
Yep, not a fan either. A big shift is that where "routing" happens has moved. Routing has traditionally been done within the SPA. Now it's an external concern and part of a build process.
The various hybrid/mpa/spa innovations are great but not everyone needs them. It's sad to see the traditional SPA approach be discouraged so much.
These meta-frameworks crossing into the server-side will raise a lot of architectural questions for teams. For us, we have React SPAs served by ASP.NET backends and using Vite locally. We'd rather not adopt another dependency like Next or Remix. We're definitely not going to adopt any Node on the backend.
The friction we're experiencing with these new static-exports is that we'd have to configure the backends with the front-end framework's routing system in order to serve the split out static files. e.g. ASP.NET needs to know how to serve NextJS's folder/file/path structure. As opposed to today where we just have to serve an index.html file regardless of whether it's Ang, React, Svelte, etc.
A static build in Sveltekit is as simple as changing 1 line in your config:
`import adapter from “@sveltejs/adapter-auto”`
becomes
`import adapter from “@sveltejs/adapter-static”`
Also, Sveltekit was designed as a serverless framework optimized for the edge long before Vercel hired Rich. Doing SSR on the edge right can be a hard problem to solve, so getting it for free “automagically” in Sveltekit is a huge value-add! Static site generation, on the other hand, has long been a solved problem.
That said, I agree that a lot of sites are better off just being static. Nonetheless, being able to change one line in my Sveltekit config to deploy my static site onto Cloudflare Pages, Netlify, or my own node server thanks to Sveltekit’s adapters is pretty awesome in my experience!
I have not said SvelteKit can't do it. In fact having different options(and for free) is a great thing. I was raising the point that messaging [1] is that it is not recommended most of the time, and does not say when it is good to have an SPA.
Also mentions about scenario JavaScript is disabled. I am not too sure if these frameworks help there with SSR. May be it meant the user can still see a pre-rendered page but with almost no interaction possible?
Essentially I was saying there is a push towards server based frameworks.
> Having a server component is just the natural step after a decade of bloated and unnecessary SPAs.
Not sure I buy that argument. While I am not totally against the idea of server based frameworks, what is disappointing is the frameworks are appearing to plant the above message.
SPAs provided us a good boundary and that is blurred by all these server based frameworks. You now have server for UI, server for BE. While I agree some SPAs are heavy, I think we have reasonable solutions for most. And these server based framework still need all the work that is done in SPA, just that routing and some aspects of bundling are taken care.
There's no conspiracy. SPAs should have never become the default way to make web front end.
Making a good SPA takes a lot of work and almost nobody has time to do it properly. Even Google with all its resources is incapable of making a good SPA for the Google Cloud console.
> More and more frontend frameworks are now somewhat mandating a server part. I know pretty much all(sveltekit, nextjs) say you can do static export, but docs are more focused to use with a server.
Sometimes servers just make sense from an architectural sense. You wanna get a bunch of the same stuff to many people? Servers are a good and battle tested way of doing so — with very well known trade offs and costs, minus weird gotchas that you only realize after the fact.
I think Qwik is totally cool. An interesting critique brought up by Rich Harris[1] (I'm paraphrasing) was it's not clear to the developer what code runs on client and what runs on server. Given this, it's too easy for code that should not be exposed (server only stuff with database schemas, or worse) may end up being exposed (shipped to the client). Is this a valid critique?
[1]Rich Harris on frameworks, the web, and the edge
Spring Boot is a fullstack web framework but it can be used as a backend web framework.
You would use Spring Boot as the backend web framework and Qwik as the fullstack web framework that, instead of using a database*, uses an API powered by Spring Boot to access information.
* Qwik is perfectly capable of using a database despite being a frontend-heavy framework. It's like Next.js in that the backend runs in Node.js and you can use any npm package that runs on Node. The server-side part of Qwik would be lighter weight with it just passing requests on to the Spring Boot app.
Apart from just disliking JavaScript as a whole, what specifically would you improve to make it acceptable? I think any problems it has on BE would also apply on FE, and should be improved?
> Qwik is different because it does not require hydration to resume an application on the client. Not requiring hydration is what makes the Qwik application startup instantaneous.
> All other frameworks' hydration replays all the application logic in the client. Qwik instead pauses execution in the server, and resumes execution in the client.
https://qwik.builder.io/docs/concepts/resumable/
It stores state in the DOM tree in a way that lets it "resume" running. If you click a link, a top level handler can recurse down the page to find listeners. It can gather any extra state & on the fly spin up components needed by the handler.
In general I think the topic of serializing & exposing application state is a vast untapped trove of awesomeness that compsci could be mining. 9p is the best reflection we have. But we also see a steady stream of git-based data projects coming out, that also reflect the value of serializing your state in a valuable way.
The twist here of using serialized app state, baked into the DOM, to allow instant resumability is awesome. On-demand paging back in state is like live migrating a vm or user process, just an awesome feat that redefines the computing model in such a more open way.
Congrats on your 1.0!