JavaScript Stacks: The Acronyms Are Dead

MEAN, MERN, MEVN. For about five years, people described a JavaScript application this way, and bootcamps still teach them by name.

Nobody building anything serious talks that way now, and the reason is more interesting than the fashion. Each acronym bundled four fixed choices into one package, and almost every assumption underneath those choices has since broken. Understanding which ones broke tells you more about modern JavaScript development than any list of stacks could.

What the acronyms assumed

Strip MERN down, and it makes three claims: your database is MongoDB, your server is Express, and your front end is a separate single-page application that talks to it over HTTP. MEAN and MEVN swap the front-end letter and leave the rest.

The MongoDB assumption broke first, and hardest. The acronyms were coined when document databases were new and exciting, and the pitch was that JSON in the browser should be JSON in the database. In practice, most applications have relational data: users belong to organisations, orders contain line items, everything joins to everything. Modelling that in a document store means either duplicating data or reimplementing joins in application code, both of which get expensive. PostgreSQL, meanwhile, handles JSON natively, so the one genuine advantage evaporated. Postgres is the default now, and reaching for Mongo needs a reason.

The separate SPA assumption broke next. Building a client application and an API server as two codebases meant duplicating types, duplicating validation, writing an API layer whose only consumer was your own front end, and shipping a blank page to anything that couldn't run JavaScript. That last part has real costs for crawlers and anyone on a slow device, which I covered in the piece on SEO for front-end developers.

The Express assumption broke quietly. Express is still fine, still everywhere, and no longer the only sensible answer. Fastify is faster with schema validation built in, and Hono is small and portable across runtimes.

So all three letters that weren't the front-end framework have come loose. What replaced the bundle is not another bundle.

The meta-framework era

What actually replaced the acronym stacks: frameworks that collapse the client and server into one codebase, so the "stack" is mostly one decision instead of four.

Next.js is the React default, and version 16 made Turbopack the production bundler while pushing Partial Prerendering toward general availability. Largest ecosystem, largest hiring pool, and the deepest bet on React Server Components. Its gravitational pull toward Vercel is real, though self-hosting works.

React Router v7 is what Remix became. The merge landed in late 2024, bringing loaders, actions, and progressive enhancement into React Router itself. It bets on web standards rather than Server Components, and it suits URL-centric products: marketplaces, multi-step forms, anything where the browser's navigation model is an asset. Worth knowing that Remix 3 is being reimagined as something separate, forking Preact and leaving the React ecosystem, so the name now points to two different things.

TanStack Start is the third React option, built on TanStack Router by the team behind TanStack Query. Its pitch is type safety, and it picked up developers unhappy with the React Router merge. Newer, so weigh that accordingly.

SvelteKit produces the smallest bundles of the group, and Svelte 5's runes made reactivity explicit. The trade-off is being outside the React mainstream, which affects hiring more than it affects the code.

Nuxt is the answer for Vue teams, and it's the only answer, which makes the decision easy.

Astro ships zero JavaScript by default and hydrates only the islands that need it. It's the right choice for content-heavy sites, and it accepts components from multiple frameworks. Reports in early 2026 suggest Cloudflare is acquiring it, pointing to deeper edge integration.

One thing to note if you're following older tutorials: Create React App is dead, and the React documentation no longer recommends it. Vite or a meta-framework are the current starting points.

The decisions you actually make

Here's the useful reframing. A stack isn't a package you adopt; it's a short sequence of decisions, and they're roughly in this order.

Rendering strategy first. Server-rendered, statically generated, client-rendered, or a mix. This is the highest-consequence decision on the list because it determines what crawlers see, how fast the first paint is, and how much JavaScript reaches a mid-range phone. Everything else is downstream of it.

Then the framework, which mostly follows from the rendering decision and from what your team already knows.

Then the database. Postgres unless you have a reason. Managed hosting has made this close to a free operational cost, and the one system now covers relational data, JSON, full-text search, and vector search.

Then the data access layer. Drizzle if you want something close to SQL with types on top; Prisma if you want the smoother developer experience and can live with the abstraction. Either way, read the SQL it generates, which is the same caution I gave in the server-side tools piece.

Then the runtime and hosting target. Node is the safe default, Bun is faster, and edge runtimes impose real constraints on what libraries you can use. Decide this before you build, because retrofitting is painful.

Then authentication, which is the piece people leave until last and shouldn't. Rolling your own is a bad idea, and the options are mature.

Notice there's no single letter for any of these, which is precisely why the acronyms stopped working.

Combinations that make sense now

Named honestly rather than as acronyms:

A SaaS product or dashboard: Next.js, Postgres, Drizzle, hosted wherever you like. Boring, well-documented, and the largest hiring pool of any option here.

A content site, blog, or marketing site: Astro, with islands only where you need interactivity. Cheapest to host and the fastest by a wide margin, because most pages ship no JavaScript at all.

A Vue team, anything: Nuxt and Postgres. The decision makes itself.

Performance-critical, small team, comfortable outside React: SvelteKit and Postgres.

A genuinely decoupled API, meaning mobile apps and third parties consume it too: Fastify or Hono as a standalone service, with the front end as a separate application. This is the one case where the old split architecture is still correct, and it's worth naming because the meta-framework enthusiasm sometimes obscures it.

When MongoDB is actually right

To be fair to it, rather than dismissive.

Document databases suit genuinely document-shaped data: content management, event logs, product catalogues with wildly varying attributes, anything where the schema differs per record and joins are rare. They also suit early prototypes where the schema changes daily, and you don't want migrations slowing you down.

What they don't suit is the typical application with users, permissions, and transactions across related entities, which is most applications, and which is what the acronym stacks pointed everyone at by default.

So is MERN worth learning?

If you're following a MERN tutorial, it's fine. You'll learn Node, Express, React, and how the pieces of a full-stack application fit together, and those transfer.

What matters is knowing it's a teaching stack, not a modern default. When you're building something real, make each decision on its own merits: rendering strategy first, then framework, then database. That's how the choices are actually made now, and it's why nobody puts them in an acronym.

What to learn

JavaScript and TypeScript properly, ahead of any framework. Types across the client-server boundary remove an entire category of bugs, and the language outlasts everything built on it.

Node fundamentals: the event loop, streams, and why CPU-bound work blocks everything. Frameworks hide these until something breaks.

SQL, which is the most transferable item on this list and the one JavaScript developers most often skip.

One meta-framework, deeply. The concepts move across, so depth in one beats familiarity with three.

HTTP itself: caching headers, status codes, and content negotiation. Meta-frameworks abstract these, and understanding what they abstract lets you debug.

The short version

The acronym stacks encoded assumptions that no longer hold. Mongo isn't the default database, the separate SPA-plus-API split isn't the default architecture, and Express isn't the only server.

What replaced them is a set of independent decisions: rendering strategy, framework, database, data access, runtime, auth. Make them in that order, on their own merits.

For most applications, the answer is a meta-framework plus Postgres, with the specific framework following from whether you're building a content site, a product, or a decoupled API. That's less memorable than a four-letter acronym, and considerably more likely to be right.