When the first jQuery 3 alpha was announced, I did not see it as a sign that jQuery was suddenly new again.
I saw it as another reminder that the browser support conversation was changing. For years, jQuery had been the practical answer to a lot of front-end problems. It smoothed over browser differences, made DOM work easier and gave developers a common way to write interactions without spending every project buried in compatibility issues.
That history matters because many websites still depend on jQuery for sensible reasons. The question in 2015 is not whether jQuery was useful. It clearly was, and still is in many projects. The more interesting question is how long every project should continue carrying the same browser assumptions that made older jQuery versions necessary.
Old Browser Support Always Has A Cost
Supporting older browsers is not only a technical checkbox.
It affects the CSS you write, the JavaScript you choose, the testing you need and the kinds of interface decisions you are comfortable making. Sometimes that cost is worth paying. If a client’s users genuinely depend on an older browser, then support is part of the job. The mistake is carrying that cost automatically without checking whether the audience still needs it.
That is where jQuery’s split between modern and compatibility-minded builds becomes interesting. It reflects a tension developers have been dealing with for years. Do we keep the project heavier so older environments remain comfortable, or do we allow modern browsers to move with less historical baggage?
jQuery Was Still Solving Real Problems
I would not remove jQuery from a project just to prove a point.
There are plenty of existing websites where jQuery is doing useful work. Removing it without a practical reason could create more risk than value. A site with plugins, existing admin behaviour, legacy templates and years of small interactions may be better served by careful maintenance than by a rewrite.
At the same time, new projects deserve a more deliberate decision. If the site only needs a menu toggle, a small accordion and a few form behaviours, perhaps native JavaScript is enough. If the project relies on plugins or a team already has a strong jQuery pattern, then using it may still be sensible. The point is to decide rather than inherit.
The Native Browser Was Catching Up
Part of the reason this conversation changed is that browsers became more capable.
Selectors, events, class manipulation and Ajax work no longer feel as painful in modern browsers as they once did. That does not erase the value jQuery provided, but it does reduce the need to reach for it on every small interaction. The browser has absorbed some of the everyday work that used to make a library feel essential.
That shift changes how I think about dependencies. A dependency is not bad because it is external. It becomes questionable when the project no longer needs what it provides. If native APIs can do the job clearly, I would rather use them. If a library still makes the project safer or faster to build, I am comfortable keeping it.
Maintenance Matters More Than Fashion
The worst reason to remove jQuery is fashion.
A client does not benefit from a rewrite if the site behaves the same, costs more and becomes harder to maintain for the team responsible for it. The better reason is clarity. If removing a dependency makes the project smaller, easier to understand and easier to test, then it is worth considering. If it only makes the stack look newer, it probably is not worth the disruption.
This is especially important with older websites. They often contain small behaviours added at different times for different reasons. Before changing the foundation, I want to understand what is actually there. Sometimes the right answer is to replace one part. Sometimes the right answer is to leave the existing layer alone and document it better.
What I Took From The Alpha
The jQuery 3 alpha made me think less about the release itself and more about the projects still depending on old assumptions.
It is healthy for tools to move forward. It is also healthy for projects to question what they still need. Browser support should be based on real users, not fear. Dependencies should be based on value, not habit.
jQuery earned its place because it solved practical problems. The decision now is whether each project still has those problems, and if it does, whether jQuery is still the cleanest answer.