Charlie’s thoughts on dev perception:
People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.
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.
We’ve arrived at an industrialised process, one that’s like an assembly line for applications. Frameworks like React have become the machinery of that assembly line. They enable us to build efficiently, to build at scale, to build predictably. But they also constrain what we build.
But what aren’t we building? What new kinds of experiences, what new kinds of applications, what new kinds of interaction could we create if we were deeply exploring and engaging with the capabilities of the platform? I don’t know, because we’re not building them. We’re building what the frameworks enable us to build, what the assembly line can produce efficiently.
Collectively, as an industry and as a profession, consciously or not, we’ve chosen this maxima that we’re stuck on. We can build what React or Vue or Next or name your framework/library enables us to do.
I share John’s despair at this situation, but I don’t share his belief that large language models will save us.
A very, very deep dive into like-for-like comparison of JavaScript frameworks. The takeaway:
Nuxt demonstrates that established “big three” frameworks can achieve next-gen performance when properly configured. Vue’s architecture allows competitive mobile web performance while maintaining a mature ecosystem. React and Angular show no path to similar results.
And the real takeaway:
Mobile is the web. These measurements matter because mobile web is the primary internet for billions of people. If your app is accessible via URL, people will use it on phones with cellular connections. Optimizing for desktop and hoping mobile is good enough is backwards. The web is mobile. Build for that reality.
React exists as a profound perversion of the web platform. React has failed upwards to widespread adoption because it provides a “developer experience” that bypasses the hard parts. Like learning HTML, or CSS, or JavaScript. Even learning React itself is discouraged; that’s for adults, you should use meta-frameworks. React devs are burdened with multi-megabyte monstrosities before they’ve written a single line of code. You cannot fix “too much JavaScript” with more JavaScript and yet React devs are trained to
npm installuntil their problems become their users’ problems.
Web browsers provide you with great features for free. Why would you choose to use tools that stop you taking advantage of that?
It’s almost as though humans prefer to use post-hoc justifications rather than being rational actors.
Try writing your HTML in HTML, your CSS in CSS, and your JavaScript in JavaScript.
Don’t replace. Augment.
Serious business or tools for online expression?