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.
Since you’re here: could you please remove the universal `letter-spacing: 1.5px` from the stylesheet? It’s never reasonable to use nonzero letter-spacing on body text. (Montserrat is also a dubious choice for body text—it’s not at all designed for the purpose.)
I think there is one pattern missing here. I've been working on a framework that has a server side virtual DOM, so all rendering happens on the server and updates are streamed to the browser. Kinda feels like React, but it's 100% server side. https://github.com/mayu-live/framework
Streaming SSR, as I understand it, does not keep a session alive on the server, so if you make interactive components they will still run in the browser.
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.
Instead of transferring entire components it transfers only the content that has changed since the last render.
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'
The format of the updates is a basic structure that represents a DOM-operation and an ID and some data, which is packed with MessagePack and streamed over HTTP/2.
I never used ASP, but someone told me that my framework reminded them of JSF (JavaServer Faces).
Blazor Server looks pretty interesting, I had never heard about it!
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.
Yes, the state is stored in memory, with async tasks and everything.
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.
Generally loving this breakdown! Good wide review.
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.
If you're willing to entertain MPAs, there's small little library called swup that creates seamless transitions between routes (eg. /home, /faq) despite them being 2 different domains. I'm trying it out for www.lona.so and it looks pretty interesting so far
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
Unfortunately the given examples (Next and Nuxt) are much slower than traditional template engines, even in "slow" languages like Python + Jinja2. This may not translate into financial cost at the scale of your average startup but it does have a measurable performance cost for each page load.
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).
I feel like HTMX should have a place somewhere there at the top next to Static, as "Expanded HTML" or simply HATEOAS or something like that. Very comprehensive list otherwise.
I'm not sure how HATEOAS fits here.. it's a rest principle guiding how one should be able to interact with an API to the best of my knowledge. Please clarify.
For the web, ofc. It runs in the browser. But for the backend there are many choices. If you read the list of options in the article all of them spawn from javascript.
I wish there was more written here about how each approach of delivering JS/HTML and adding interactivity works on the server and on the client in techical terms. The nomenclature used for these quickly turns into a confusing mess.
I don't think it really matters how the DOM information gets to the client.
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.
qwik may be appealing technically, but it's not the best fit for web applications because:
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.
Point 1 is irrelevant unless you're hiring devs who cannot adapt quickly to minor changes, in which case it's an useful hiring filter.
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/
My bad, sorry for the misinformation from my previous comment. I will dive more into the link you gave me to see the limitations they talk about and the small vs big island. But it makes me reconsider using qwik for future projects.
Thank you for point this out to me and taking the time to respond!
52 comments
[ 5.0 ms ] story [ 117 ms ] thread[0] - https://m.youtube.com/watch?v=Dkx5ydvtpCA
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.
https://hotwired.dev/
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.
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).
https://www.patterns.dev/posts/rendering-patterns/
You can also check the illustration at the bottom of the page for a brief summary.
> 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.
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.
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!