November 24th, 2020
Here are the big categories of rendering websites:
- Client: ship a
- Static: pre-render all the HTML.
- Server: let a live server process requests and generate the HTML response.
They are not mutually exclusive.
- A website could statically pre-render 75% of it’s pages (say, blog posts), but the other 25% have a server respond to (say, forums).
- A website could statically pre-render all the pages, but have a couple of empty
<div>s in there that have client-side rendered content in them (e.g. a dynamically generated menu based on the logged-in user).
- A website could be primarily server-rendered, but has caching in front of it such that it behaves statically.
- A website could render statically, but then “hydrate” itself into an entirely client-rendered site.
- A website could be a mix of server and static rendering, but have dynamic parts similar to client-side rendering, but actually happen in an edge function, so it ends up more like server-side rendering.
Next.js is interesting in that it can do all three. Here’s Tim Neutkens in a recent interview:
Next.js allows you to pre-render pages. It creates HTML on a server at build time with static site generation or uses run-time rendering on the server-side. Next allows you to do a hybrid of those. Unlike most other frameworks, you are not bound by, oh, I’m going to build my app completely statically generated. Instead, you’re allowed to have some pages be server-side rendered and some pages are statically generated.
In the new release, we make it possible to update these statically generated pages without having to run a new build, rebuilding your whole app.
Cool. Love to see that happening at the framework level. Seems like having to go all-in on one rendering style isn’t practical for a lot of sites.
Client rendering is the most flexible but comes with all these serious downsides like worse performance, worse reliability, more strain on devices, bad SEO, etc. Static pre-rendering is the most robust, speedy, and secure, but is the most limited. Edge functions on top of static are starting to open doors, but server-rendering is the classic mix of flexibility and speed that has dominated the web for good reason.
Tom MacWright wrote about that recently in his “If not SPAs, What?” post. Some of today’s alternatives:
Turbolinks … what is the bare minimum you need to do to get the SPA experience without any cooperation from your application?
Barba is all about getting page transitions going (more detail on that concept). instant.page is all about pre-loading/rendering pages right before you click then, so even though you get a page refresh, it feels less intrusive (particularly with paint holding). Both are cool, but not quite one-to-one replacements for an SPA. (Even with paint holding, pre-rendering, and lightweight pages, I still don’t think the experience is quite a smooth as an SPA. For example, you still get the page loading spinner.)
So… is anything else cooking? Kinda. There is
<portal>. Possibly too simplified, but here goes: portals are like iframes. They can even be visually displayed just like an iframe. That means the rendering of the URL in the portal is already done. Then you can “promote” the portal to be the active page, and even animate the portal itself while doing so.
I don’t hate it. I can imagine someone building a turbolinks-like library on portals so they are “easy to use” and make a site more SPA-like.
Still, animating a rectangle into position isn’t often what is desired from animated page transitions. Just look at Sarah’s “Native-Like Animations for Page Transitions on the Web” article. That’s what the people want (at least the possibility of it). That’s why Jeremy said not portals the other day when he cheekily said that “[m]ost single page apps are just giant carousels.” He also points to Jake’s navigation-transitions proposal from a few years back.
So what’s the best rendering method? Whatever works best for you, but perhaps a hierarchy like this makes some general sense:
- Static HTML as much as you can
- Edge functions over static HTML so you can do whatever dynamic things
- Server generated HTML what you have to after that
- Client-side render only what you absolutely have to
The original post Rendering Spectrum.