Change and risk

<p>Kelly Sutton on <a href="https://kellysutton.com/2025/01/18/moving-on-from-react-a-year-later.html">why his team views big front-end frameworks as a liability</a>:</p> <blockquote> <p>Maybe it’s the changing interest rates or political winds, but I think the “fat client” era JS-heavy frontends is on its way out. The hype around edge applications is misplaced and unnecessary for building many different flavors of successful businesses.</p> </blockquote> <p>My translation here: what’s good for business often isn’t what’s cool or tracking at the top of the orange website or what has most likes on GitHub. A product can be <em>extremely</em> useful and interesting and still be on the most boring tech stack imaginable.</p> <p>But also, this bit:</p> <blockquote> <p>Change comes with risk, and changing untested code has a higher regression risk. [...] Moving more slowly is fine in many cases. But when compared to a world where that change isn’t risky (server-rendered ERB), we are suddenly paying a very pricey tax for making changes in JavaScript.</p> </blockquote> <p>At most places I’ve worked at, any amount of change feels <em>extremely</em> risky and that sentiment at one point or another moves out of the codebase and into every meeting and discussion. So I think that as a small dev team, where every moment is precious, perhaps the most important thing is reliability in a codebase.</p> <p>And big, overly complicated JS-heavy frontends are anything but reliable.</p>