I’m Going Back to jQuery in 2025 (And Why That’s Not Insanity)
Posted in Thought — 4 minutes read
A Senior Developer’s Unapologetic Reckoning with the Tools We Love to Hate
“Legacy Code” or “Stable Foundation?”
When I left my agency job in 2024 as a team lead—building WordPress sites with Vue sprinkles and Laravel apps—to join a profitable SaaS startup running Laravel and jQuery, I felt a pang of dread. jQuery? In this day and age? The library I’d mocked as obsolete, bloated, and “what we used before real frontend frameworks existed”?
Six months later, I’m eating my words.
The truth is this: the codebase I inherited, built in the jQuery era, works. The business logic is robust, the profit margins are healthy, and—most surprisingly—shipping new features feels like slipping into a worn leather jacket: unfashionable, but comfortable. I’ve spent countless evenings wrestling with Vue component state management in side projects, only to come to work and solve the same problems in jQuery with a fraction of the code.
Is it “legacy” if it’s still delivering value at lightspeed?
Sit Down, Frameworks—Let’s Talk Tradeoffs
Let me be clear: I love React’s composability. Vue’s reactivity is elegant. But when your app doesn’t need a virtual DOM, global state managers, or hydration waterfalls, why pay the tax?
The SaaS I work on isn’t Facebook. We’re not rebuilding Figma in the browser. Most of our frontend needs are:
- Toggling modals
- Submitting forms with AJAX
- Updating tables dynamically
- Simple animations
For these, jQuery just works. No hooks, no dependency arrays, no JSX. Write imperative code, ship it, and move on. It’s fast—not in performance benchmarks, but in developer velocity.
And yes, jQuery’s 87kb (minified) feels bloated compared to Alpine.js. But in a world where we blindly accept 500kb JavaScript bundles for static blogs, maybe the problem isn’t jQuery.
The Ghost of Web Dev Future (HTMX, Alpine, and jQuery’s Spirit)
The htmx team isn’t wrong to call their library “the new jQuery.” Both share a philosophy: solve 80% of problems with 20% of the complexity.
jQuery normalized cross-browser DOM manipulation in the 2000s. Today, htmx normalizes hypermedia-driven interactions. Both abstract away boilerplate so developers can focus on what to build, not how. The difference? jQuery thrived in an era where developers weren’t expected to be full-stack DevOps engineers.
I see the same quiet pragmatism in Alpine.js. These tools don’t demand a PhD in reactivity or build tooling. They’re simple. And simplicity has a funny way of outlasting trends.
When Not to Go Back
Alright alright, let’s cool down the hot takes:
- Design systems? Use React/Vue. Reusable components need structure.
- Collaborative teams? Frameworks provide guardrails.
- Complex state? Reach for Pinia or Zustand.
But for most apps—CRUD dashboards, marketing sites, internal tools—you’re overengineering. Over 80% of the web is still static. Why are we pretending it’s not?
The 100-Year Web Service
My startup’s jQuery code has outlasted multiple frontend framework hype cycles. It loads in 50ms, degrades gracefully, and the learning curve for new hires is scroll down, read code, understand.
When I ask, “Will this code still work in 5 years?” with React, I’m nervous. With jQuery? It’s already worked for six.
Maybe that’s the lesson: sustainability is innovation.
Closing Thought
We worship “modern” because it feels like progress. But every abstraction has a cost: dependency churn, perpetual re-learning, and complexity that compounds silently.
In 2025, I’m choosing tools that let me ship today and sleep soundly in 2030. For me—and maybe for you—that might just mean unironically embracing the “old.”