jQuery and legacy front ends
Nobody starts a project with jQuery in 2026. Plenty of working systems still run on it. The question is whether yours needs one plugin replaced, needs to keep working as it is, or needs to move.
01Overview
Why it is still in your codebase
jQuery is a JavaScript library from 2006 that hid the differences between browsers and gave developers a short way to select elements and handle events. The browsers then absorbed it. It is still in a lot of production code, usually because it arrived inside a theme or a plugin. The language underneath is JavaScript; the framework question is React.
02Capabilities
Three ways this goes, and only one is a rewrite
Every engagement on an ageing front end turns out to be one of three, and knowing which changes the estimate more than the code does.
- Maintain
Keeping an estate running
Fixes, browser updates and dependency patching on a front end that works and earns money, without pretending a rewrite is scheduled. That is maintenance and support, and it is a legitimate destination rather than a holding pattern.
- Migrate
Moving off it, one surface at a time
Replacing older screens one route at a time behind the existing routing, so the product keeps shipping. This is the core of legacy modernization, and it is how old storefronts and e-commerce admin screens get replaced without a freeze.
- Plugins
Untangling the plugin layer
The library is rarely the cost. The cost is a decade of plugins doing date pickers, tables, sliders and modals, half of them unmaintained. Working out which ones carry real behaviour is the first honest estimate anyone can give you.
03Fit
Move, maintain, or keep it patched
Legacy is not a synonym for broken. The mistake we meet most often is not keeping jQuery too long, it is a migration launched with no user-visible benefit and no owner, which stalls halfway and leaves two styles of code in one codebase forever. Each row is the call we would make, and four of them link to the unicrew page that covers it.
| Your situation | What that actually calls for |
|---|---|
| A new project, and somebody suggested jQuery | Browser APIsThe browser covers what it was for. If there is real state shared across screens, you want a framework: JavaScript and React. |
| A working application, no incidents, and changes are rare | Keep it patchedPatch the dependencies, and save the migration budget for the screens where a user would notice the difference. |
| Every change breaks something somewhere else | Different pageMove route by route behind the existing routing, most valuable screens first. See legacy modernization. Never a big-bang rewrite. |
| The library is loaded for one plugin | Replace the pluginThen drop the library. Cheapest win in this whole category, and it stops you shipping a library to every visitor for one widget. |
| Old code, no tests, and nobody left who wrote it | Tests firstTests at the boundaries before any change, so you can tell whether you broke behaviour somebody depends on. That is QA and test automation, and it comes first. |
| A security review flagged an unmaintained plugin | Move, in that orderFix or replace the flagged components first, independent of any wider plan. This is the one reason to start that does not need a separate business case. |
| You want the replacement to stay safe to keep changing | Different pageAdd types once more than one person is in the code. Our TypeScript page covers how that gets staged on a codebase that already ships. |
Scope
What we own on this kind of work is the order and whether it can be stopped: which surface moves first, what the way back is, and whether you can halt after any step with a working product rather than a half-migrated one. Where the right answer is to keep the estate running rather than migrate, we recommend that and maintain it properly. unicrew has been maintaining and replacing systems like this since 2012, with 100+ senior in-house engineers across six countries. Our information security is certified to ISO 27001:2022. Where the whole front end needs an owner, that is front-end development.
04Stack
What the replacement is built from
The four decisions this page keeps pointing at, each with a page of its own.
05Questions
What owners of an ageing codebase ask
The five that come up before anyone commits budget, answered the way we would answer them on a call.
Not automatically. The test is whether it costs you something you can name: changes take too long, defects repeat, a security review flagged an unmaintained plugin, or you cannot hire people willing to work in it. If none of those is true, the code can stay as it is, maintained properly, and the budget goes where users will notice. If several are true, the case makes itself and the question becomes sequencing.
For most of what jQuery does, the browser itself: selectors, class changes, events and network requests are all built in now, so plain JavaScript is the natural replacement. A framework like React is warranted where real state is shared across several screens, not because it is newer. Once more than one person is in the code, add TypeScript.
Yes, and it is the only way we would attempt it. Old and new interfaces run side by side behind the same routing, and we move one surface at a time so each is live before the next starts. It looks slower on a plan than a clean rewrite, and it is far more likely to finish. A migration needing a freeze gets cancelled when the business changes its mind.
Yes, through maintenance and support, and we run it as a full engagement in its own right. What we ask for is a decision rather than drift: either there is a plan to replace it, or there is an explicit decision that replacement is not worth it and we maintain it properly. Undeclared limbo is how systems end up unpatched with nobody accountable.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a codebase nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Deciding whether to move off it?
Tell us what the front end does and what actually hurts. You will get an engineer's read on whether it is worth migrating, and what order we would do it in. We will also say where legacy modernization would start.