Web Rendering Patterns
mburakerman.github.io
mburakerman.github.io
> We find ourselves in an era where a new Javascript framework was born, bringing exciting possibilities to the web development landscape.
If it has said “a span of several minutes” rather than “an era”, it would have made sense.
I didn't just use that video. I was keeping this post for myself, but after putting my website, it somehow blew up here. It was not 100% ready for public tbh.
Just added the credits.
Qwik has a lot more going for it that I knew. It's used by CloudFlare's Mastadon/ActivityPub implememtation. At first that was kind of a turn off to me; the initial research I did on it didnt really sell me. But this simple breakdown makes a lot of sense!
One thing that did bug me: this portrays Single Page Apps as having to load the whole site ahead of time. Projects like react-router have had exemplary incremental loading for a long long time now. I wish this was a more frequent focus. We never really got great at unbundling, breaking out multiple units of code; the hope that ESM would let us fully unbundle was the miracle that never delivered, alas, where any incremental load would just automatically quickly get whatever other new deps were needed. But there's definitely still a much wider terrain than is portrayed here for SPA.
But again, thumbs up mostly! We dont have many quick easy reviews of whats out there, how we do the web, and this post is a great quick understandable introduction. Great material.
Effectively this it what it does - intercept links to other pages, loads them in the background, then swaps out the contents of the current page with the new page. Your MPA effectively becomes an SPA with just some minor rejiggering
Some of them are hard to see.
Vercel didn't invent server side rendering. It was always there.
This article isn’t talking about server-side rendering, as one might have used the term 10–15 years ago (but not really before that, because it didn’t need a name before that, because client-side rendering wasn’t really a thing), but rather Server-Side Rendering, which is when you use client-side rendering tech, but run it on the server side (typically “as well”, but not quite necessarily).
What is more important to me is how much of the state is kept on the client and how complicated it is to synchronize with the state on the server.
I've found the most elegant "patterns" to be ones where the server maintains virtually all of the state, with the client operating more-or-less as a dumb terminal.
If it's just component rendering then how does it differ from Streaming SSR?
So I think it's more like Hotwired, because it keeps a session alive on the server, but it's declarative like React, so you just return whatever you want rendered and the VDOM will generate patches for the browser.
So if you have a like button with the number of likes totalling 3, and someone were to hit the like button to increase the count to 4 the only content transferred would literally be a string value of '4'
I never used ASP, but someone told me that my framework reminded them of JSF (JavaServer Faces).
For example, Blazor definitely is capable of http/2.
It sounds more or less like what I'm trying to do. Gonna read the documentation, maybe I can find some inspiration.
I've mostly looked at JavaScript frameworks and libraries until now. I really liked working with Vite+React+TypeScript because of the feedback loop and fast updates, and I thought it would be nice to have the same thing in Ruby.
Wikipedia says: > Remote clients act as thin clients, meaning that the bulk of the processing load is on the server. The client's web browser downloads a small page and updates its UI over a SignalR connection.
This would be a good description of my framework as well, except that it doesn't use SignalR.
There is a mechanism so that before a server shuts down, the state for each client will be serialized, compressed, encrypted and sent to the client, so they can send the state to the next server when they reconnect and resume the session.
https://www.patterns.dev/posts/rendering-patterns/
You can also check the illustration at the bottom of the page for a brief summary.
1. You're required to use qwik's API for React, limiting your flexibility and hiring.
2. The lack of compatibility with the vast React components and libraries ecosystem means you'll have to start from scratch on all your components, even essential ones like calendars, MaterialUI, charts, etc...
If your focus is on creating a website and try something else than say Gatsby, then qwik may be a good option. However, for web applications and the ability to fully utilize the React ecosystem, it doesn't seem to be the best choice.
Everything else about not being able to integrate with the React ecosystem is incorrect, please read this part of the documentation where it explains in detail how to do it and how to integrate it with Resumability in mind: https://qwik.builder.io/integrations/integration/react/
Thank you for point this out to me and taking the time to respond!