2021 could well be the year of the server's glorious return.
The React team at Facebook have previewed server components, and the people at Basecamp have released Hotwire.
The approaches are very different, but both tools seem to be about:
- writing less JavaScript
- doing more on the server
- dealing in plain old HMTL whenever we can
Why does it matter?
The past few years of web development have been about shifting as much as possible off the server.
Companies like Netlify have been arguing hard for making our apps as static as possible, and building our dynamic features with client JavaScript,APIs and serverless functions.
This is arguably a faster, more secure way of doing things, but it does have downsides.
Doing everything statically can add complexity, and shifting the burden of work from our servers to the user's browser makes it harder to progresssively enhance our apps: we're beholden to the speed of the user's connection and hardware.
Client-rendered single page apps still have accessibility issues that are hard to solve.
After a few years of this, it looks like the pendulum is now swinging back in the other direction.
Maybe the server is good for some things after all!
How do they work?
React's server components are a carefully-considered redo of what Next.js does now with getServerSideProps.
With Next.js today, you can only do server-side operations on top level "page" components. This would remove that limitation.
Meanwhile, Basecamp's Hotwire is an evolution of the Turbolinks library that comes standard with all new Rails apps.
It seems intended to be a Rails companion, though I expect there's a way to use it seperately.
Should I learn it now?
Probably not quite yet!
React's server components are a way off yet—all we can do is experiment with the demo.
While Hotwire is apparently production-ready, it'll take a little while for examples, documentation and patterns to get good enough for me to consider using it, at least.
What's the reaction been?
Everyone seems to love Facebook's server components, though there's a lot of unanswered questions.
People seem more confused about Hotwire. Maybe it's a sense of humour thing?
Either way, I'm keen to see where this goes.
Exciting times ahead!
Top comments (2)
DEV, by way of Forem has remained respectful of the server and the value of streaming HTML without being too religious about our approach.
We have some technical debt that comes with a few different patterns which I hope we can pay down in the next year or so, but I'm happy that we've had a deep focus on the problems we're trying to solve for and come up with some good solutions out of there.
It's always interesting to see that you've accidentally stumbled on to a "trend" without having known you were working with some new specific paradigm— And I've been seeing a good amount of that lately. Hotwire is a more ride-or-die version of some patterns we already make use of in some way (with ample influence from Basecamp and Rails to begin with)
Cool post 😊. Hotwire loosely reminds me of ASP.NET Blazor Server, where all the interactivity of the page is controlled by the server through SignalR. This is somewhat similar to the partial page updates done by WebSockets