Replacing one jQuery or AngularJS feature: write its contract before you touch it

Where support stands

The jQuery project's support page, checked on 11 October 2026, says only the latest version is officially supported: 1.x and 2.x are no longer supported and 3.x gets only critical security patches and bug fixes. It lists three options for an old version: upgrade, using the jQuery Migrate plugin to ease it; buy commercial security support from third parties; or do nothing, with multiple risks. AngularJS's own support page says support ended in January 2022. Neither fact says your application is unsafe; both say where upstream fixes will not come from.

• An upgrade of the library does not replace an abandoned plugin that depends on it.
• Commercial support buys time; it does not retire the dependency.

A feature has a contract you can write down

Open the page and list what the feature expects and what it gives. The markup it expects, the inputs it reads, the events it listens for or emits, the hidden fields and data attributes other code reads, and anything it puts on the global scope. jQuery's event documentation matters here: delegated handlers also cover elements created later if the ancestor exists, and namespaced events can be removed by namespace, so a plugin may have attached behaviour to elements that your replacement must also cover. A replacement that satisfies the contract can be swapped in without touching its neighbours.

• Search the repository for every reader of the feature's fields and events.
• Ask who else loads scripts on the page, including analytics and tag managers.

AngularJS adds state and framework questions

An AngularJS directive carries state in scopes and two-way bindings, so the contract also includes what it reads from and writes to its scope and parent. Angular's documentation describes a hybrid mode in which Angular is bootstrapped first and AngularJS second, so both run in one page and features can move one at a time. That route suits teams that have decided to adopt Angular. A team that has not can replace the feature with plain modern JavaScript behind the same markup contract.

• Decide the target before writing code: hybrid mode or a framework-neutral module.
• Do not add a new framework only to replace one feature.

Prove the swap with a browser script

Write a script, run in a real browser, of the behaviours people rely on: the inputs, the results, the events and the keyboard operation. Run it against the old feature to record the baseline, then run the same script unchanged against the replacement. Add a before-and-after check of two neighbouring features that you did not touch. A passing script covers the listed behaviours, not every possible action, so the list is part of the agreement.

• Keep the script: it is the contract in executable form.
• Check keyboard use for each agreed action on old and new.

What does not fit, and how the fixed job is accepted

Replacing a whole front end, redesigning the feature, changing the API or supporting browsers older than your current requirement are outside the fixed job. It covers one feature of about 600 lines on one page and is accepted when the agreed script of up to 15 behaviours passes on the old feature and then unchanged on the replacement, every field and event others read is still produced, the old plugin or directive is no longer loaded for that feature and two untouched features still pass their checks. Send the library versions and the plugin or directive names, not code. Prices are untested proposals; payment follows the agreed checks.