Everyone loves declaring jQuery dead.
And yet - 2025. It’s still here. Not starring in any conference talks, not topping npm charts…
but running quietly in production on ~78% of the top 1M sites (W3Techs) and hundreds of millions of websites total.
So maybe the real question isn’t “why is jQuery still alive?”
but rather:
Why do we expect old code to disappear just because we found a cooler way to write new code?
After a five-year break, I’m returning to the conference stage. On November 19th, I’ll be speaking at JS Poland about practical strategies for migrating legacy frontend systems to modern architectures.
To lead up to the talk, I’m publishing a short series of articles on legacy code, refactoring, and incremental migrations — this is the first one in the series.
If you’ll be there, feel free to say hi — I’m always up for a good legacy-code war story 🛠️.
jQuery is not “alive” - it’s installed.
jQuery isn’t winning the frontend race.
It already finished it years ago, shipped to production, and is now sitting in long-term maintenance mode…
exactly like COBOL in finance systems.
Nobody wants to rewrite an old COBOL banking backend - but they also can't just delete it.
jQuery is the same, just for the web.
🧠 Misconception: “Modern JS killed jQuery”
Yes - the browser finally caught up.
// jQuery $('#btn').on('click', () => $('#box').addClass('active')); // Modern JS document.querySelector('#btn').addEventListener('click', () => { document.querySelector('#box').classList.add('active'); }); Native DOM APIs finally do almost everything jQuery used to fix.
✅ Query selectors
✅ Class manipulation
✅ Event binding
✅ AJAX → fetch()
✅ Animations → CSS + Web Animations API
So why is jQuery still everywhere?
Because fixing the past is way more expensive than building the future.
🧱 The uncomfortable truth: refactoring doesn’t pay bills
Most jQuery code isn’t “bad.”
It’s just old, tangled, DOM-first, and impossible to replace safely in one go.
The real blockers:
| Problem | Why jQuery stays |
|---|---|
| 🧩 Business logic glued to DOM | no clean separation to migrate |
| 🔌 3rd-party plugins | no React/Vue/Svelte versions exist |
| 💸 Rewrite has no ROI | “Works now, don’t touch it” |
| 🛒 WordPress, Shopify, Drupal | ecosystems built on jQuery |
| 🧨 Migration risk | you break checkout → you lose money |
The business perspective is brutally simple:
“Does rewriting jQuery bring new revenue?”
No. It only reduces technical debt.
And debt is only paid when it starts to hurt.
📊 Data check: frameworks die faster than legacy code
| Thing | Average lifespan |
|---|---|
| JavaScript frameworks | ~5–7 years of relevance (React is a rare longer-lived exception) |
| Real commercial apps | 12–20 years |
| WordPress share of web | ~43% (jQuery in core) |
| Sites still using jQuery | ~78% of top 1M |
Frameworks come and go:
AngularJS (dead), Backbone (dead-ish), Ember (barely breathing), Meteor (remember that one?).
jQuery?
Not evolving. Not trending.
Just quietly on production servers, powering money-making code.
🧑🎓 Should juniors learn jQuery in 2025?
Short answer: No.
Not as a first tool. You don’t learn medicine by studying outdated procedures as your entry point.
jQuery doesn’t teach:
- components
- reactivity
- state management
- bundlers
- SSR / hydration
- scalable architecture
It teaches DOM scripting. And that’s not modern frontend anymore.
🧑💼 Should seniors understand jQuery?
Yes. Absolutely.
Not to write it - but to delete it safely.
A senior who can’t read legacy code is just a React developer, not a software engineer.
You don’t get paid to build shiny new things.
You get paid to keep existing things alive without breaking production.
Real senior skill today:
“I can refactor a jQuery-heavy feature into modern code without breaking the checkout button.”
🏗️ Why full jQuery removal rarely happens
Because real migrations look like this:
- Ship new UI in a framework
- Leave old jQuery modules running in parallel (strangler)
- Promise “we’ll clean it up later”
- Later never comes
You don’t “remove jQuery.”
You encapsulate it, shrink it, quarantine it.
And one day, after 5+ years, you realize only 3 old widgets still depend on it… and that’s good enough.
That’s not laziness.
That’s economic reality.
🧩 WordPress: the elephant in the room
- ~43% of websites run on WordPress
- WordPress core still ships jQuery (updated, but still required)
- Tens of thousands of themes/plugins depend on it
- Most won’t ever be rewritten
Even if every frontend dev stopped using jQuery today, WordPress alone would keep it alive for another decade.
🧨 The real punchline
jQuery isn’t “alive” because it’s good.
It’s alive because the cost of deleting it is higher than the cost of keeping it.
That’s not a technical decision.
That’s economics + risk management + legacy entropy.
🔚 Final verdict
Is jQuery the future? No.
Is it “dead”? Also no.
It’s the COBOL of the frontend - old, uncool, irreplaceable in millions of systems.
Modern frontend dev means two skills:
✅ Build the new stuff right
✅ Understand the old stuff well enough not to break it
🤔 Your turn
- Have you ever tried to remove jQuery from a production app? How did that go?
- Do you think companies should budget for refactoring - even without direct ROI?
- Will we still see jQuery in 2035? (I’ll bet yes.)
📬 Like content about legacy, migrations and real-world frontend?
I share more on my Substack:
No hype. No frameworks of the week.
Just real software reality.
Top comments (106)
jQuery, just like COBOL, VB, C will outlive most of our code these days. At the moment, I'm working on a legacy app migration from VB to Blazor. And I'd bet that by the time we finish our migration, Microsoft will deprecate Blazor...and VB will be still around, seeing dozens of other languages and tools die.
Love this comment ❤️
That’s exactly how it goes: we rewrite old tech into “modern” tech… and then the modern tech dies first.
VB, COBOL, jQuery, even plain PHP — they just keep running while newer tools come and go.
Blazor might fade someday, but VB will still be in production, laughing 😎
Perfect summary of software reality!
MIcrosoft tends to be especially frustrating at times, though. The transition from WinForms -> WPF/XAML -> UWP -> whatever's next... UWP was supposed to make development between Desktop, Mobile, Tablet/Surface, etc. easier to negotiate and then Mobile gets dropped like the plague shortly after. Anyone remember the MS Band?
But, in the background, you still have WinForms (& Win32 messaging), just chugging along... just hoping that the next OS version still allows backward compatibility... Just ask any hospital IT department what OS version they are running.
Windows XP, is that you?
Hahaha, exactly! 😂
Somewhere out there, a Windows XP machine is still running a hospital MRI controller — untouched, unpatched, and somehow still alive.
It’s basically the COBOL of operating systems at this point.
It’s the same pattern everywhere — shiny new layers on top, but the real money-making code is still the stuff from 20 years ago 😅
(And yes, the MS Band mention made me laugh way too hard.)
jqury will never end while other script also update with their front end features in web development. I have ten years experience in jquery front end handling and customisation in web pages work in header section.
That’s awesome - ten years of experience with jQuery is a lot of real-world knowledge!
And I agree - jQuery might not be the “new shiny thing” anymore, but it’s proven, stable, and still gets the job done for many projects.
It definitely earned its place in web history. 💪
yes i agree jquery never fail and its handle in and out data using events in very sequently and quick action dynamically in between the web pages function and other post and get data using database values.
Exactly! 💪
That’s one of the reasons jQuery became so popular - it made handling data, events, and dynamic updates between pages so much easier back in the day.
It really simplified the way we interacted with the DOM. 😄
great , mostly 70% people don't work with jquery while jquery ver easy to handle data flow using event handling with the help of ajax and json.
If Microsoft doesn't deprecate Blazor, we definitely will. Just wait!
Hahaha, exactly! 😂
If history has taught us anything, it’s that developers deprecate tech way faster than Microsoft ever could.
Give it two years and we’ll all be calling Blazor “legacy” while rewriting it in whatever’s trendy next. 😎
Yes, but I meant something else.
I mean Elanat's WebForms Core technology, which works on a "Server-Command/Client-Execution" model, as opposed to the current web paradigm (State/UI recovery cycle).
We will be promoting it widely soon.
Very intriguing! A "Server-Command/Client-Execution" model definitely goes against the grain of the current web paradigm. What are the biggest trade-offs or advantages you've found so far compared to, say, a component-based approach like React or Vue? I'll keep an eye out for the announcement!
You are right, this is a new paradigm on the web.
In this model, the server is stateless and generates commands. Commands are also created with order 1 (O(1)); the processing is limited to providing a static file from the server. Here, the client is responsible for interpreting the commands and executing them.
In this model, you write your code on the server and of course you can instruct the server to load JS modules to the client and then instruct the client to execute JS methods.
With just 2 or 3 commands, you can implement the entire component structure in React:
Example 1:
HTML template ("/template/content.html")
Server code
Example 2:
We have an ambitious plan to transform the structure of the web.
That’s definitely an ambitious approach - and I love seeing people experiment with how far we can push the boundaries of the web model.
Your “command-driven” concept sounds a bit like a mix of server-side rendering, template streaming, and client orchestration - almost a declarative bridge between backend and frontend.
It’s interesting that you’re focusing on statelessness on the server and shifting interpretation to the client - feels like the opposite of what most frameworks are doing right now (hydration, reactivity, etc.), which makes it even more intriguing.
I’ll definitely check out Elanat - it’s always exciting to see bold attempts to rethink how we build for the web.
Innovation often starts where everyone else says “that’s not how it’s done.” 🚀
I use jQuery on every front end and C on every back end. Why learn something new? I have piles of paying jobs to do and don't have time for the flavor of the day.
jQuery + C - the combo that’ll still be running the internet when we’re all gone 😎
I love this:
So true. And you're right. This is the same reason WordPress will never go away. There are a million new (and often better) ways of building a site with CRM-like features, but WordPress does it in one package. Similar story with jQuery. It got the job done well. Should you use it today? Almost certainly not. Does it still get the job done if you do? Of course. And that's the beauty of it.
Exactly! I remember building WordPress sites a few years back, and honestly — it just didn’t make sense to use anything else. WordPress had everything in one box, and it worked.
Suggesting something like “let’s build a headless React frontend” for a simple website felt less like good engineering and more like upselling the client for no real benefit 😅
(As long as we’re talking about a straightforward marketing site, not a complex app.)
Actually, I hate this line - because it's considered so true. But it's not (at least not in this context).
It's actually a case of confirmation bias - we all think we'll do better next time because we're smarter (and even if we're re-writing our p.o.s. code well, we're smarter this time around, amiright?).
So we tell ourselves "fixing the past is way more expensive than building the future."
Sure, that applies some of the time - just not nearly as often as we'd like to believe.
Look at it this way. If you care about getting from A to B reliably buy a Toyota Corolla and have it professionally maintained. Your ROI will be far better than abusing the Corolla, getting bored with it, leasing a new car to keep up with the Jones's etc.
It's the same with your Word Press site, or jQuery based tool. If it gets you from A to B (and that's your primary use case) then maintain it by paying for refactoring and you'll get many more miles of carefree motoring. Or something like that...
I agree with "don't new build with jQuery" - but, as the OP suggests, don't throw out all your jQ in one go - incremental refactoring is like changing the oil.
Now, when an EV comes along - and there's a paradigm shift - well, then your primary use case has changed. It's no longer just about getting from A to B - it's about getting from A to B with as little environmental impact feasible (sorry, Greta, but I'm just not going to sail across to the UK the next time I go and visit my Mum).
I definitely should have leaned into this reality a bit more. I agree 98%. The other 2% is the scenarios where you realize that whatever you've built has accumulated so much tech debt due to the very nature of how it's created and maintained that at least working towards migration becomes your only option as you scale.
I totally agree with you - there are definitely mature, well-maintained legacy systems where “regular oil changes” are enough to keep them running for years. Not every old codebase needs to be replaced just because it’s old.
But in many cases, a gradual refactor isn’t just a matter of preference - it’s a matter of risk management.
Some examples:
As always, it depends on the project - but I don’t think “never rewrite” is safer than “never refactor everything at once.” Both extremes can hurt. 😊
Wordpress doesn't goes away because it offers free/cheap hosting. It uses the make them addicted and then let them pay method.
That's bang on. You'd be surprised how many new Wordpress sites I've seen go up just because that's what the contractor they found knows, and they end up paying hundreds for plugins that do things modern systems do out of the box, or can be done in a dozen or less lines of code.
Exactly - and that’s the part people often miss.
Sometimes WordPress (or jQuery, or any legacy tech) isn’t chosen because it’s the best tool today, but simply because the person building the project only knows that tool.
And then the real cost starts later:
paid plugins, compatibility hacks, performance issues, upgrade pain…
Which is why “just keep the old stack forever” isn’t always cheaper in the long run - it depends who’s maintaining it and how.
Legacy isn’t free just because it still works. 😊
Interesting point — and I agree there’s definitely a “lock-in” effect in the WordPress ecosystem.
But I don’t think cheap hosting is the main reason it survives.
What really keeps WordPress alive is:
So yes, there’s some “addiction”… but there’s also economics, familiarity, and inertia.
People don’t stick with WordPress because it’s perfect — they stick with it because it’s good enough and already paid for. 😄
A part of the making you addicted strategy.
But once the site breaks how much money do you need to spend to get it right again? It is not like cheap things you can replace, there is a lot of value in the database that is created by a bad system.
A part of the free/cheap side, let some intern handle it so we don't need to pay IT people.
No agency I know willingly provides WordPress services if they can sell better solutions.
Migration is always a cost, and it is also a one-off cost.
It is what it costs after the migration that matters. You just can't beat free.
All fair points - and I agree that “free” often comes with hidden long-term costs, especially when the platform starts showing its age.
But that’s exactly why WordPress is such an interesting case:
it survives not because it’s ideal, but because the trade-offs are still acceptable for most businesses.
Cheap to start, expensive to fix later - yet still cheaper than rebuilding from scratch for many.
And yes, migration is a one-off cost - but the risk of breaking revenue during that migration is what keeps many companies from doing it.
In the end, it’s not about tech purity, it’s about business tolerance.
Some choose the “refactor and modernize” path, some choose “keep the old thing patched and running” - and both can be valid depending on the context. 😊
There are enough other systems you don't need to build from scratch. So that is a false assumption.
If you are rebuilding a website you analyse the features of the site and match it with other solutions.
WordPress sites aren't rocket science so there will be solutions that get you 80 or even 90 percent on your way. And the 20 or 10 percent will be custom code in Wordpress too.
How are you breaking revenue during the migration? If you go to another platform it should be the same procedure as a big update of the current code.
There can be some teething problems, but they should be fixed under the quality guarantee the IT partner provides.
That is just a nice way to say do it cheap.
I don't mind that business's want cheap sites if that is not their main platform. But if it their main platform or a significant platform they should invest in it, like they would do with all the other things that makes their company valuable.
That part, unfortunately, is different in my experience. Even at the agency level (and sometimes especially at that level), "it works" is all it takes. Forget if there's better, cheaper options. Too many people go with what they know over what they could learn and benefit from.
100%. And I think we're circling the same issue. @sylwia-lask is stating reality, and we're stating would should be true.
I can get behind the benefit part, we all need to have money.
I'm conflicted over the what they could learn part. If you don't want to learn how are you going to evolve?
You can be conservative, but you still learn over time.
I have leaned more to the should be true side in my comments, but I think the reality is more scattered than Sylwia portraits. The truth is somewhere in the middle, as it usually is.
Absolutely - I think we’ve now reached the real core of the discussion:
there’s the reality of how things work today, and there’s the ideal of how they should work.
And you're right: the truth is always somewhere in between.
Some companies choose “cheap and familiar,” others choose “invest and modernize” - and both approaches can be valid depending on the business, the budget, and the role of the platform.
Thanks for the thoughtful debate - I genuinely enjoyed the different perspectives. 🙌
This is such bait in the best way :)
No bait at all! I even softened the title — the original version said “fight me” instead of “here’s why” 😄
Oh I just mean that it's irresistable content for devs 😄
More like group therapy for FE devs (and the occasional PHP one) 😅
It’s the COBOL of the frontend — really! So true, and like COBOL, there’s no need to rewrite it as long as it works. Even if it’s dinosaur code, it works — and that’s what matters.
Not rewriting is, in fact, a form of intelligence — and of efficient laziness.
Loved this piece — you managed to capture something that too many devs overlook: stability is a feature. Congrats on the Top 7, well deserved!
Thank you so much! 🙌
And I completely agree - “efficient laziness” should honestly be recognized as an engineering principle at this point 😅
There’s real wisdom in knowing when not to rewrite - and you’re absolutely right, stability is a feature.
Love how you phrased that!
This is such a good article! It applies to PHP as well. It's not around because it's the best, it's around because it's just too ingrained into SO MUCH enterprise software.
Devs get so excited to remove old tech but really need to learn to live with it more of the time. Businesses simply aren't going to invest developer hours into something that they see has little to no tangible value
I don't agree with the comparison. jQuery was a temporary fix for Javascript goofiness.
PHP is a language, that get fixed while it evolves.
I do agree that too many developers want to use new shiny toys.
Totally agree. Beyond the fact that PHP is a language and jQuery is a JavaScript library, it’s worth remembering how far PHP has come — even since PHP 3.
Sure, it has its flaws, but it also has strengths that make it the right tool for many jobs.
Saying it’s “obsolete” is nonsense — languages like C or Perl are still alive and well, and they’re not going anywhere soon.
Each has its strengths and its natural domains.
Unless, of course, someone’s planning to automate CNC machines with React… or rebuild a banking app in Node.js? 😏
That’s a fair point - PHP and jQuery aren’t the same category of technology, so the comparison isn’t 1:1.
jQuery is a library, PHP is a language, and yes - PHP continues to evolve while jQuery has been “done” for years.
The analogy wasn’t about what they are technically, but why they’re still everywhere:
because they became deeply embedded in real products, and replacing them often has no business payoff.
And I totally agree with your last line - a lot of rewrites happen not because the old tech is broken, but because developers want the new shiny stack. That’s when rewrites become expensive hobbies instead of smart investments.
Thanks for the thoughtful pushback - always happy to refine the argument. 🙌
this is unfair PHP was bad and now is good, it genuinely is a good language that has something to offer as a choice, meanwhile JQuery was good and today is bad, it has literally nothing to offer and its worse than just using plain JS, it didn't evolved and it won't help you anymore, its just there so your old code doesn't break
That’s fair - and you’re right, modern PHP has evolved a lot!
I even mentioned in one of the earlier comments that today’s PHP is a completely different language - faster, safer, and much more structured than it used to be.
As for jQuery - I totally agree it’s not something you’d reach for in a new project anymore.
But I think its role today isn’t about offering new value - it’s about preserving the old one.
It’s not evolving, just quietly doing its job so millions of old systems don’t break - which is kind of poetic in its own way. 😄
Thank you! ❤️ And you’re absolutely right — PHP fits this story perfectly.
It’s not still here because it’s “the best,” but because it became too essential to remove. Entire ecosystems (WordPress, Laravel, half the internet 😅) depend on it.
And to be fair — modern PHP isn’t that bad at all!
It’s come a long way in terms of syntax, performance, and tooling. The reputation just hasn’t caught up yet.
Totally agree — as engineers, we often need to learn to live with legacy, not just dream about replacing it.
It is not a good thing that a website is using a library that is meant to fix Javascript problems that are mostly solved by the evolution of the language.
It means nobody is asking critical questions, like do we need this dependency. And that is the case when it comes to WordPress.
The biggest problem with Wordpress is that they want to be backwards compatible by all means possible. And that is why they have jQuery, Backbone and React as dependencies.
They are creating a spread so wide Jean-claude Van Damme can't even do it.
You’re absolutely right that modern JavaScript no longer needs jQuery the way it once did — and yes, in an ideal world every dependency would be questioned instead of “just left there because it still works.”
But I think the WordPress situation is less about developers not asking critical questions, and more about a platform with 43% of the web choosing extreme backward compatibility over technical elegance.
That’s why we end up with:
Is it pretty? Absolutely not.
Is it intentional? 100%.
WordPress doesn’t optimize for “clean architecture” - it optimizes for not breaking millions of sites overnight.
So yeah, the tech stack is doing the Van Damme split… but the alternative would be mass outage, angry clients, and lawsuits. 😅
A quick look in the Wordpress code and you see jQuery is not only for old themes and plugins. It is still part of the current admin. The same for Backbone.
43% of the websites are not going down because Wordpress is removing a dependency.
The reason sites go down is because people want to use the free stuff. If they complain have you lost customers, I don't think you do.
And obviously you don't remove a dependency without enough warning beforehand.
You can't live in the past and the present at the same time.
Not only in an ideal world. I think it is the duty of a frontend developer to question all the code you are pushing to the user. With the new possibilities like dynamically calling modules and import maps there is a big opportunity to create a better user experience.
Totally fair - and yes, you’re right that jQuery and Backbone are still part of WordPress core, not just legacy plugins. That’s exactly why the dependency can’t just be removed overnight: it’s wired too deeply into how the platform works today, not just how it worked 10 years ago.
And I agree - questioning dependencies is absolutely part of a frontend developer’s job.
The only thing I’d add is: technical decisions don’t happen in a vacuum.
Sometimes the “right” solution architecturally isn’t the right one for 43% of the internet in production 😅
But I genuinely appreciate the discussion - this is exactly the kind of nuance the topic needs. 🙌
I agree with you there. I'm not blind for business needs.
As a developer I'm giving my perspective going from ideal to compromise to bad. And hope I can give enough arguments why the compromise is the best way forward.
The compromise is never extreme backwards compatibility.
I really want to know if there is a big change, how many sites will go down?
Wordpress could provide a version you want to stay on, so you site keeps working as a work around.
For the people that host their Wordpress site, they already have the choice not to update.
It isn't a black or white situation.
I love the comparison with COBOL - that's it! 🙂
In the last couple of years when my job was mainly to architect/design FE solutions, to design a new solution you often have some old standing in the way. So I can witness that economics rule it all. And you will be blocked by it.
The only way to I managed to overcome this is to use expertise to build a solid economic case, e.g.:
refactoring the old thing 100 dev hrs => will save 150hrs/month == in the next 6 months you will have ~750hrs more for new features that drive revenueBut the main thing: this has to be done iteratively! Meaning, you sneak in 10-20% of every sprint for that refactor. That's the only way it works. No company in the world will pay for 2-3 full cycles of pure refactoring. We have to be smart and negotiate using our expertise.
My 5 cents (or maybe $5) 🙂
No offense, but.. I think you need to improve your prompts, when you generate an article - or at least read it through and check out the "temperature" regarding jQuery usage in 2025.
jQuery was/is pronounced "dead" for a reason - it is bloated, outdated, and slows down development with unnecessary abstractions.
Yes - there are old libraries that died for a reason. jQuery is the best example. In my experience, people who struggle writing vanilla JS or TS (or generally are not good at coding), still use monstrosities like jQuery.
I get where you’re coming from - the article’s more about legacy realities than about recommending jQuery.
But hey, if it got people talking, that’s a win already 😉
Okay, my bad. I read it through, and I definitely jumped to conclusions too soon. There are many valid points; however, I still believe that no one should need to even open the documentation and learn it in 2025.
If you need to refactor or remove jQuery dependency code, you have to rewrite the whole solution from scratch - without the jQuery.
Talking about jQuery in 2025 just triggers the PTSD of refactoring bloated code line after line. 😐
Totally get that PTSD 😅 Refactoring legacy jQuery code can be rough.
But yeah - in many systems, a full rewrite just isn’t realistic. That’s where the strangler pattern really shines - slowly replacing pieces until the old parts can safely fade out.
Sometimes you’ve got to live with legacy for a while before you can let it go.
Question: Have you ever tried to remove jQuery from a production app? How did that go?
Also I added
Element.prototype.asJQ(),Element.prototype.asDOM(),jQuery.prototype.asJQ(),jQuery.prototype.asDOM()to our codebase. This is really helpful if you don't know who is calling your code. Then everyone is told: "AvoidasJQ()"I think I should write an article about that.
That’s an awesome approach — I love how you turned “removing jQuery” into a team habit, not a one-time refactor.
Documentation + rules for new devs + boy-scout rule + PR reminders = that’s exactly how legacy disappears without a big risky rewrite.
Also: adding asJQ() / asDOM() is brilliant. That kind of tiny bridge layer is what makes progressive migration actually possible in real apps, where you don’t always know who’s calling what.
And yes — you should absolutely write an article about this.
There are tons of devs trying to remove jQuery with no real strategy, and your playbook is way more valuable than another “just rewrite it in React” post 😄
Tried once, with the "one component at a time" approach.
One of the best aspects of jQuery many people don't realise is that it's a library and not an obtrusive opinionated framework, so it's easy to sneak in some other similarly inobtrusive libraries that can coexist with it, or potentially enhance it.
Here's a little example of how we added rxjs and rimmel.js inside some existing jQuery code to add various pieces of advanced interactive functionality:
this way we only enhance existing jQuery code where it's convenient, leaving the rest untouched.
The benefits of reactive components and various stream-oriented patterns become quickly apparent: very few lines of code, just as powerful as rxjs can take you.
Most of this would have been much less straightforward (or outright impossible) in an Angular or React application, so kudos to jQuery for being so unobtrusive and easy to work with.
That’s an awesome example — thanks for sharing it!
What you’re describing is very close to the “islands” migration pattern: instead of rewriting the whole page or replacing jQuery in one big bang, you drop in modern, self-contained components where they add the most value, and let them coexist with the legacy code.
It works especially well in large apps (e-commerce is a classic case) where:
And yes — this is where libraries like RxJS really shine. You can layer reactive streams on top of old DOM logic and suddenly get modern behaviour without breaking what’s already there.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.