When to Say No to the Latest JS Framework

Shiny isn’t always better. Sometimes it’s just distracting.

A new framework can be genuinely useful, but novelty is not the same thing as suitability. Before adding one to a project, I want it to solve a real problem rather than simply give the team a fresh collection of problems to learn.

Framework choice matters, but usually less than the quality of the decisions made inside it. A fashionable stack cannot rescue unclear ownership, inaccessible markup or a product nobody has tested with real users.

The answer is rarely a universal rule. It is a way of looking at the decision clearly enough to choose on purpose.

Prefer the thing that survives contact

Front-end work has a habit of looking simple from a distance. The browser then introduces real content, small screens, old devices, keyboard navigation and somebody using the product in a way nobody drew in the design file.

That is why I favour choices that are easy to inspect. Start with semantic HTML, let CSS do the layout work it was designed for, and add JavaScript where it creates genuine value. Cleverness is occasionally useful; legibility is useful every day.

The best front-end code does not show off. It makes the interface feel obvious.

The web is wonderfully forgiving, but users should not have to rely on that forgiveness. Build from sturdy foundations and the interesting parts become much easier to enjoy.

I do not always manage it perfectly. The aim is to make the better choice easier to recognise the next time it appears.