These definitions work for me:
A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.
A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.
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.
This is a spot-on analysis of how CSS-in-JS failed to deliver on any of its promises:
CSS-in-JS was born out of good intentions — modularity, predictability and componentization. But what we got was complexity disguised as progress.
React is no longer just a library. It’s a full ecosystem that defines how frontend developers are allowed to think.
Browsers now ship View Transitions, Container Queries, and smarter scheduling primitives. The platform keeps evolving at a fair pace, but most teams won’t touch these capabilities until React officially wraps them in a hook or they show up in Next.js docs.
Innovation keeps happening right across the ecosystem, but for many it only becomes “real” once React validates the approach. Which is fine, assuming you enjoy waiting for permission to use the platform you’re already building on.
Zing!
The critique isn’t that React is bad, but that treating any single framework as infrastructure creates blind spots in how we think and build. When React becomes the lens through which we see the web, we stop noticing what the platform itself can already do, and we stop reaching for native solutions because we’re waiting for the framework-approved version to show up first.
If your team’s evolution depends on a single framework’s roadmap, you are not steering your product; you are waiting for permission to move.
Or, more precisely, why use React *in the browser*?
Web browsers provide you with great features for free. Why would you choose to use tools that stop you taking advantage of that?
Some handy tips courtesy of Chris Ferdinandi.
HTML’s new `command` attribute on the `button` element could be a game-changer.
How I switched to high-resolution maps on The Session without degrading performance.