Always bet on HTML
In September of 2019, Zach Leatherman tweeted
Which has a better First Meaningful Paint time?
- a raw 8.5MB HTML file with the full text of every single one of my 27,506 tweets
- a client rendered React site with exactly one tweet on it
(Spoiler: @____lighthouse reports 8.5MB of HTML wins by about 200ms)
Take a moment to wrap your head around that.
It’s perceivably faster to load 8.5 megabytes of HTML than it is to load a single tweet with a client-side React app.
[…]
Real companies can and do build apps with HTML first
The folks at Basecamp just released a new email product, Hey, that tries to address a lot of the stuff that people find frustrating about email.
Neither product is really my cup of tea, but what I find super interesting is how Hey is built.
It’s core is server-rendered HTML. Basecamp is a Ruby on Rails shop (their CTO created Rails). Almost every view in the app is created on a server.
Then, they sprinkle just a little vanilla JS on top to turn things up to 11.
Basecamp uses a project they open sourced called Turbolinks. This JavaScript plugin intercepts link clicks and progressively enhances a server-side app into a single-page app (or SPA) by fetching additional pages with Ajax and only replacing the stuff that needs updating.
By using this approach, if the JS fails or isn’t supported, the app still loads and works and gives people the full experience. It also means you don’t have to wait for the full JS package to load before you can start using the app.
You still get the benefits of faster page loading that SPAs sometimes give you, but you don’t have to maintain two code bases or do complicated server-to-client hand offs (“rehydration” as they call it in the React world).