The death of jQuery and the modern stack that replaced it

Quick answer: jQuery solved DOM manipulation, AJAX, and cross-browser compatibility in 2010. In 2026 those are solved by the browser itself (querySelector, fetch, near-universal standard support). The modern stack: vanilla JavaScript for marketing sites; Astro / Next.js / Nuxt for content-led builds; React / Vue / Solid for genuine applications; HTMX or Alpine.js for sprinkling interactivity onto server-rendered HTML. jQuery isn’t wrong — it’s just no longer needed for most projects.

jQuery still runs about 70% of the web according to W3Techs, which sounds like a vote of confidence. It mostly isn’t. It’s the long-tail effect of WordPress and millions of legacy sites that ship jQuery whether they use it or not.

For new builds in 2026, the question isn’t whether to use jQuery. It’s which of the modern alternatives fits the project. Here’s the honest map.

What jQuery solved (and why it isn’t needed)

jQuery’s historical wins:

• DOM manipulation. $('#thing').addClass('foo') was simpler than the verbose DOM API of 2008.
• AJAX. $.ajax() was simpler than XMLHttpRequest.
• Cross-browser compatibility. Internet Explorer behaved differently from Firefox, which behaved differently from early WebKit. jQuery papered over the differences.
• Effects and animations. $.fadeIn() was simpler than handcrafting CSS transitions.

In 2026 each of these is solved natively:

• document.querySelector() and element.classList.add() are nearly as concise as jQuery for DOM work
• fetch() is a clean modern API for HTTP requests
• All evergreen browsers behave the same; Internet Explorer is dead
• CSS transitions and animations handle most effects natively, with Element.animate() for the rest

jQuery is no longer solving a problem you have. It’s 90 KB of JavaScript adding nothing your code couldn’t do directly.

The modern stack, by use case

Marketing sites: vanilla JS or Astro

For a typical marketing site — the kind of site where most performance budgets live — the right answer is usually no JavaScript framework at all.

The pattern:

• Static-output site (HTML pre-built at deploy time)
• A small amount of vanilla JavaScript for the bits that need interactivity (mobile menu, smooth scroll, form submission)
• CSS for animation and visual effects
• Modern image and font delivery

Built on Astro (our default), this typically ships under 30 KB of JavaScript total — and often under 10 KB. The result is a site that scores 95+ on Lighthouse Performance reliably, passes Core Web Vitals by default, and is faster than competitors using heavier stacks.

This is what we default to for premium marketing builds.

Content-led sites: Astro, Next.js, or Nuxt

For sites with real content volume — blog, documentation, knowledge base — modern static-site generators dominate. Each has different strengths:

• Astro: content-first, framework-agnostic. Best when most pages are content with light interactivity. Lowest JS shipping by default of any framework in this list.
• Next.js: React-based, good when you also have app-like sections (logged-in, dynamic) on the same site. Strong ecosystem.
• Nuxt: Vue-based equivalent of Next.js. Strong ecosystem in the Vue world.

For pure content, Astro tends to win. Once a site has both content sections and app-like sections, Next.js or Nuxt let you use one framework for both.

Apps with real interactivity: React, Vue, or Solid

For applications — logged-in dashboards, multi-step forms, real-time interfaces — the JavaScript framework is doing real work. Your choices in 2026:

• React: the dominant choice. Largest ecosystem, most talent available, most third-party libraries. Has gotten heavier over time; with React 19 server components, it’s leaner than it was.
• Vue: smaller than React but very capable. The composition API and ecosystem have matured significantly.
• Solid: newer, smallest runtime of any modern framework, fastest performance. Smaller ecosystem than React or Vue but growing.

For most app-style work, React is the safe default. For performance-critical apps where every kilobyte matters, Solid is genuinely worth considering.

Sprinkling interactivity onto server-rendered HTML: HTMX or Alpine.js

A genuinely interesting middle ground: server-render most of the HTML (from any backend — Rails, Laravel, Django, Node, Go), then add interactivity with a tiny library.

• HTMX: ~14 KB. Adds attributes to your HTML that swap server-returned fragments into the page on user interactions. The pattern: server returns HTML; client doesn’t need to know JSON. Surprisingly capable.
• Alpine.js: ~15 KB. Vue-like reactivity declared inline in HTML. Best for sprinkles of interactive behaviour rather than full components.

These suit projects where you want server-rendered HTML’s simplicity and SEO benefits but need more than vanilla JS for interactivity. Particularly strong for internal tools, content sites with light interactivity, and admin panels.

Where jQuery still makes sense

The narrow cases where staying on jQuery is reasonable:

• Legacy WordPress sites with deep jQuery integration. Migrating away is a project; if the site is otherwise working, the cost may not justify the win.
• Projects requiring jQuery-specific plugins that haven’t been ported to vanilla JavaScript and would be expensive to rewrite.
• Internal tools where bundle size doesn’t matter. If three people use the tool from corporate networks, the 90 KB cost of jQuery is irrelevant.

For everything else, jQuery is genuinely no longer the right answer.

What this means for new builds

For each project type:

• Marketing brochure: Astro + minimal vanilla JS. Or Markdown in a static-site generator with no JavaScript at all.
• Content site / blog: Astro by default. Next.js or Nuxt if you also have app sections.
• Logged-in dashboard or web app: React (safe default), Vue (smaller team, capable), or Solid (performance-critical).
• Existing server-rendered app needing more interactivity: HTMX or Alpine.js, kept light.
• Existing jQuery site that’s working fine: stay until you have a reason to migrate. If the site is being substantially rebuilt anyway, modernise the stack as part of it.

The cost of getting this wrong

Picking the wrong stack costs more than people expect:

• Over-engineering (React on a marketing brochure): visitors download 200 KB of JS to read three paragraphs. Lighthouse scores drop. Bounce rate climbs.
• Under-engineering (vanilla JS on a complex app): your codebase becomes an unmaintainable mess of addEventListener calls. Onboarding new engineers takes weeks.
• Wrong-philosophy (single-page app for content): the SEO suffers, initial load is slower than necessary, content updates require deploys.

The honest framework: pick the simplest tool that fits the job. Marketing site — Astro or vanilla. Content site — Astro. Real app — modern framework. Sprinkle on top of server HTML — HTMX or Alpine. Anything else, justify why.

What we choose for clients

For our typical client work:

• 80% of marketing sites: Astro
• Content-heavy sites: Astro (sometimes Next.js if app sections exist)
• Custom web apps: Next.js or Astro depending on the balance of static vs dynamic
• Internal tools: HTMX or Astro depending on the team’s preference
• Migrating off WordPress / legacy: usually Astro for the marketing site, with the legacy stuff phased out separately

We default to Astro because it produces tiny, fast, server-rendered output by default — which is the right answer for most of the projects clients ask us to build.

Common questions

Is jQuery dead? For new development, effectively yes — the problems jQuery solved are now solved by browsers natively. For existing projects, it remains in use because migrations cost money and the existing code works. Don’t use jQuery in new projects.

What replaced jQuery? For DOM manipulation: document.querySelector and modern DOM APIs. For HTTP: fetch(). For animations: CSS transitions and Element.animate(). For frameworks: React / Vue / Solid for apps, Astro / Next.js / Nuxt for content sites, HTMX / Alpine.js for sprinkling interactivity.

Should I use a JavaScript framework for my marketing site? Usually no. Marketing sites benefit from the smallest possible JavaScript payload. Static-output frameworks like Astro ship under 30 KB of JS by default, often under 10 KB. The performance and SEO wins are real and visible.

What’s the difference between Astro and Next.js? Astro is content-first, framework-agnostic, and ships zero JavaScript by default. Next.js is React-based and ships a JavaScript runtime even for static pages. Astro wins for marketing and content sites; Next.js wins when you also have meaningful app-like functionality.

When should I still use React? For genuine applications with significant client-side state, complex interactivity, or features that benefit from component reuse across many pages. Not for marketing sites. Not for static content. The question is “does the app benefit from a JavaScript framework”, not “is React popular” (which it is, regardless).

If you’re unsure which stack fits a specific project, start a project and we’ll give a straight recommendation. Often the right answer is simpler than expected.