Mailchimp: Grow sales with Customer Journey Smarts
Here are the big categories of rendering websites:
They are not mutually exclusive.
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 be 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 is starting to open doors, but server-rendering is the classic mix of flexibility and speed that has dominated the web for good reason.
Client rendering also opens the door for that “SPA” (Single Page App) feel. I still like that, personally. I like the no-page-refresh feel. It’s makes a site feel snappy and opens the door for page transitions. Gatsby is famous for popularizing hydration, where you get the pre-rendered static bonus, but then the upgrade into SPA as the JavaScript downloads.
I’d love to see the web get to the point where we get all that “good feel” bonus of an SPA without actually having to build an SPA. It’s notable when frameworks provide SPA feels without having to manage much of that yourself, but still, something is managing it and that something is a bunch of JavaScript.
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?
Turbolinks is like… click link, click is intercepted, Ajax request for new page is made, JavaScript flops out the content on the page with the new content. Super easy to implement, but it’s still JavaScript, and not particularly intelligent about sending less data across the wire.
barba.js and instant.page are alternative approaches to the same sort of problem.
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 the anything else cooking? Kinda. There is <a href="https://github.com/wicg/portals"><portal></a>. 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.
I love this proposal. It focuses on user needs. It also asks why people reach for JavaScript frameworks instead of using what browsers provide. People reach for JavaScript frameworks because browsers don’t yet provide some functionality: components like tabs or accordions; DOM diffing; control over styling complex form elements; navigation transitions. The problems that JavaScript frameworks are solving today should be seen as the R&D departments for web standards of tomorrow. (And conversely, I strongly believe that the aim of any good JavaScript framework should be to make itself redundant.)
So what’s the best rendering method? Whatever works best for you, but perhaps a hierarchy like this makes some general sense:
Frontend Masters has some great courses on Gatsby, starting with a great Introduction to Gatsby course from Jason Lengstorf and moving on to more advances courses.
Frontend Masters has some great courses on Gatsby, starting with a great Introduction to Gatsby course from Jason Lengstorf and moving on to more advances courses.
And for little websites, you can just use :target!
https://john-doe.neocities.org/
Sarah’s “Native-Like Animations for Page Transitions on the Web” article.
When I look at the 2 dozen apps I use on my phone, none of them have transitions like the example in the article. I suspect this isn’t any easier (or even desirable?) to do on native mobile. So I’m not sure whether the problem is real or largely hyped up. With things like Electron, it’s looking like mobile might be becoming more “webby” instead.
I really like the ideas behind HTMX. One thing that would make it even better would be to use it exclusively with forms which would make it progressively enhanced, no need for any JS but will be all that much better if you have it!