I have been removing more JavaScript from websites than I have been adding recently.
That does not mean I have stopped using JavaScript, and it definitely does not mean every website should be reduced to static HTML. It means I am more cautious about using JavaScript as the first answer to every interface problem. The browser already knows how to do more than we sometimes give it credit for, and the platform has become stronger over the last few years.
The question I keep asking is whether the interaction needs JavaScript, or whether JavaScript is just the habit I reached for first.
The Cost Of Small Scripts
Small scripts rarely feel dangerous. A menu toggle, a tab component, a filter, an animation trigger or a tracking helper can all look harmless in isolation. The problem is that websites accumulate those decisions. A few years later, the page has several scripts running, each one written at a different time for a slightly different reason.
That affects performance, but it also affects maintenance. The next developer has to understand which scripts are still needed, which ones depend on markup that no longer exists and which ones are quietly failing in the background. The visitor only sees the end result: a site that feels heavier than it needs to.
I have started treating each piece of JavaScript as a commitment. If it is added, it needs to be understood, maintained and tested. That does not make JavaScript bad. It just means the code has to earn its place.
Native Behaviour Is Often Enough
There are plenty of places where native browser behaviour is good enough, or at least a better starting point. Disclosure widgets, form validation, CSS-driven states, sticky positioning, scroll behaviour and responsive layout can often replace scripts that used to be common.
Sometimes the native option is not perfect. That is fine. The decision still needs comparing. Is the extra polish worth the additional code? Does the interaction support a real user need, or does it only make the demo feel more impressive? Will the client still understand the behaviour a year from now when they ask for changes?
I like using JavaScript where it adds genuine value. Search overlays, dynamic forms, calculators, dashboards and richer product interfaces often need it. A standard content page usually needs much less than people assume.
React Has A Place, But Not Everywhere
React remains useful when the interface has enough state to justify it. I would not want to build certain application-style screens without a component model. The issue is when that mindset leaks into ordinary websites. A simple marketing site does not become better just because every section is hydrated into a client-side component.
This is where restraint matters. A website can use React in the places that need it and still keep the rest of the page simple. Not every interaction has to share the same architecture. The visitor does not care whether a component feels theoretically consistent with the developer’s preferred setup. They care whether the page loads, responds and lets them complete the task.
I think the best front-end decisions are often mixed decisions. Use the platform where the platform is enough. Use JavaScript where behaviour genuinely requires it. Use heavier tools only where the problem is heavy enough to deserve them.
Retrospective Thoughts
Less JavaScript is not an aesthetic position for me. It is a maintenance position. The less code a website needs to deliver the right behaviour, the easier it is to keep that website fast and understandable.
The useful question is not whether JavaScript should be used. It is whether this particular piece of JavaScript is still the simplest way to solve the problem. More often than I expected, the answer this year has been no.