It sounds like Remix takes a sensible approach to progressive enhancement.
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.
I get it. React feels good and it’s sticky. But all frameworks eventually fizzle out.
Thanks to Web Components, large companies are realizing you don’t need to rebuild buttons and other UI primitives every few years. Teams don’t need to argue about frameworks anymore. You can have your cake and eat it too!
I think this may be the best long-term argument for web components:
Any org that goes all in on a single framework will eventually find themselves swimming upstream to hire talent to maintain legacy code and avoid framework rot. But you can reduce this burden (and the associated costs) by using Web Components in your design system.
Matcalfe’s Law in action:
Companies keep choosing React because they know there’s a massive pool of candidates who know it; candidates keep learning React because they know companies are hiring for it. It’s a self-sustaining cycle.
But the problem is:
React isn’t great at anything except being popular.
Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.
This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!
I really enjoyed Laurie’s talk in Berlin a few weeks back. I must blog my thoughts on it.
But I must admit that something didn’t sit quite right about the mocking tone he took on the matter of “the fundamentals” (whatever that may mean). Chris shares my misgivings:
Those websites that don’t load on slow connections, or break completely when a JS file fails to load, or don’t work for people with visual or physical impairments?
That’s not an issue of time. It’s an issue of fundamentals.
I think I agree with Laurie that there’s basically no such thing as fundamental technologies (and if there is such a thing, the goalposts are constantly moving). But I agree with Chris with that there is such a thing as fundamental concepts. On the web, for example, accessibility is a core principle of its design that should, in my opinion, be fundamental.
Do I wanna see teenagers building frivolous websites? Absolutely. But when people are getting paid well to build our digital world, they have a responsibility to ensure the right to engage with that world for everyone.
The problem I’ve regularly encountered in my work is that I don’t get to do my job the way I think is best for both me and my employer or client. The employer, who isn’t the web development expert, almost always has a clear idea of what real web development is supposed to look like: Single-Page-Apps and React (or React-like frameworks).
An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence.
I’ve experienced this. And I think this observation is even more true when it comes to recruitment.
While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.
Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.
Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.
I love these notes on my recent talk!
I believe that we haven’t figured out when and how to give a developer access to an abstraction or how to evaluate when an abstraction is worth using. Abstractions are usually designed for a set of specific use-cases. The problems, however, start when a developer wants to do something that the abstraction did not anticipate.
Smart thoughts from Surma on the design of libraries, frameworks, and other abstractions:
Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.
This really resonated with parts of my recent talk at CSS Day when I was talking about Sass and jQuery:
If you care about DX and the adoption of your abstraction, it is much more beneficial to let developers use as much of their existing skills as possible and introduce new concepts one at a time.
This is a great case study of switching from a framework mindset to native browser technologies.
Though this is quite specific to Jack’s own situation, I do feel like there’s something in the air here. The native browser features are now powerful and stable enough to make the framework approach feel outdated.
And if you do want to use third-party dependencies, Jack makes a great case for choosing smaller single-responsibility helpers rather than monolithic frameworks.
Replacing lit-html would be an undertaking but much less so than replacing React: it’s used in our codebase purely for having our components (re)-render HTML. Replacing lit-html would still mean that we can keep our business logic, ultimately maintaining the value they provide to end-users. Lit-Html is one small Lego brick in our system, React (or Angular, or similar) is the entire box.
We noticed a trend: students who pick a UI framework like Bootstrap or Material UI get off the ground quickly and make rapid progress in the first few days. But as time goes on, they get bogged down. The daylight grows between what they need, and what the component library provides. And they wind up spending so much time trying to bend the components into the right shape.
I remember one student spent a whole afternoon trying to modify the masthead from a CSS framework to support their navigation. In the end, they decided to scrap the third-party component, and they built an alternative themselves in 10 minutes.
This tracks with my experience. These kinds of frameworks don’t save time; they defer it.
The one situation where that works well, as Josh also points out, is prototyping.
If the goal is to quickly get something up and running, and you don’t need the UI to be 100% professional, I do think it can be a bit of a time-saver to quickly drop in a bunch of third-party components.
Robin adds a long-zoom perspective on my recent post:
This is a really excellent four-part series on web performance that really dives into the technical details and asks all the right questions:
Just like jQuery dominated the front end yesterday, React dominates it today. There will be something new that dominates it tomorrow. Your design system team will continue doing the same work and incurring more and more costs to keep up with framework churn. And let’s not forget the cost of updating tomorrow’s legacy apps, who are consumers of your soon to be legacy design system.
This is a terrific analysis of why frameworks exist, with nods to David Hume’s is-ought problem: the native features are what is, and the framework features are what somebody thinks ought to be.
I’ve been saying at conferences for years now that if you choose to use a framework, you need to understand that you are also taking on the philosophy and worldview of the creators of that framework. This post does a great job of explaining that.