Coincidentally, I was just talking about hammers and nails in another context.
Progressive enhancement used to be a standard approach. Then React came along and didn’t support that approach. So, folks stopped talking about that and focused entirely on JS-centric client solutions. A few years later and now folks are talking about progressive enhancement again, under the new name of “islands”.
What is going on here?
It turns out, it’s the same old thing. Vendors peddling their wares. When Facebook introduced React, that act transformed the font-end space into a hype-driven, cult-of-personality disaster zone where folks could profit from creating the right image and narrative. I observed that it particularly preyed on the massive influx of young web developers. Facebook had finally found the silver bullet of Web Development, or so they claimed! Just adopt our tech, no questions asked, and you too can be a rock star making six figures! We’ve been living through this mess for ten years now.
The cosmic ballet goes on.
A great step-by-step walkthrough of building a really nice image gallery without any JavaScript.
The end result is really impressive but there’s still the drawback that the browser history will be updated every time you click on an image thumbnail (because the functionality relies on ID attributes referenced via :target). Depending on your use-case, that may or may not be desirable.
A thoughtful approach from Sam:
- Use AI only for tasks you already know how to do, on occasions when the time that would be spent completing the task can be better spent on other problems.
- When using AI, provide the chosen tool with something you’ve made as an input along with a specific prompt.
- Always comprehensively review the output from an AI tool for quality.
Frameworks like React are often perceived as accelerators, or even as the only sensible way to do web development. There’s this notion that a more “modern” stack (read: JS-heavy, where the JS ends up running on the user’s browser) allows you to be more agile, release more often with fewer bugs, make code more maintainable, and ultimately launch better sites. In short, the claim is that this approach will offer huge improvements to developer experience, and that these DevEx benefits will trickle down to the user.
But over the years, this narrative has proven to be unrealistic, at best. In reality, for any decently sized JS-heavy project, you should expect that what you build will be slower than advertised, it will keep getting slower over time while it sees ongoing work, and it will take more effort to develop and especially to maintain than what you were led to believe, with as many bugs as any other approach.
Where it comes to performance, the important thing to note is that a JS-heavy approach (and particularly one based on React & friends) will most likely not be a good starting point; in fact, it will probably prove to be a performance minefield that you will need to keep revisiting, risking a detonation with every new commit.
This is depressing.
Explore the platform. Challenge yourself to discover what the modern web can do natively. Pure HTML, CSS, and a bit of vanilla JS…
Embedding YouTube videos without sacrificing performance.
It’s almost as though humans prefer to use post-hoc justifications rather than being rational actors.
Inside me there are two wolves. They’re both JavaScript.
Defining the inputs instead of trying to control the outputs.
2022 was once unimaginable to some web folks.