A proposal lands for a new marketing site, and the line for the stack says Next.js. Or a developer offers to spin it up in React. It sounds current and capable, and most people nod it through, because the framework name carries a quiet promise that this is the modern, serious way to build.
The question worth asking before signing is smaller than which framework. It’s whether the thing being built is content or an application. Almost everything about the right stack follows from that one answer, and for most marketing sites the honest answer points away from React and Next.js rather than toward them.
Why “build it in React” is the default
Reaching for React is rarely the result of weighing it against the alternatives for your specific site. It’s the path of least resistance, and there are good reasons it became that:
- Developers build with what they use every day, and for a large part of the industry that’s React.
- The ecosystem assumes it. Tutorials, starter templates, hiring pipelines, and job postings all point the same direction.
- “Modern” and “React” have blended together in how the work gets described, even for sites that are pure content.
None of that is a failing. It’s the same shape as answering every WordPress requirement by installing a plugin: a reasonable local habit whose cost is cumulative and shows up later, on the owner’s watch. React is fine software. The reason to question the reflex is that it gets applied by default to sites that were never going to need it.
What a marketing site actually is
Before picking the tool, it helps to name the thing. A marketing site is a set of pages: home, services, about, contact, often a blog. It’s read constantly and changed occasionally. The interactivity is light: a navigation menu, a contact form, maybe an accordion or a carousel. Structurally, it’s a stack of documents, not an application.
That distinction is the whole decision. An application is stateful and interactive: it tracks who you are, changes on every click, and does real work behind a login. A marketing site mostly presents the same content to everyone and asks the browser to do very little. Choosing an application framework for it is choosing a tool built for a problem the site doesn’t have.
What an app framework costs a document
The cost of that mismatch is concrete, and it lands in three places.
Performance. A client-side framework ships a JavaScript runtime to the browser and then hydrates the page: it downloads the JavaScript, parses it, and re-runs work to attach behavior to markup that is often just sitting there. That weight is not theoretical. The median page already ships around 558 KB of JavaScript on mobile, and roughly 44% of it goes unused. On content that could have been plain HTML, the hydration step is pure overhead, and Google’s own guidance notes it can significantly hurt INP, the Core Web Vital that measures how quickly a page responds to interaction.
Operational weight. An app framework brings a build pipeline, a Node or serverless runtime to target, and a deploy model heavier than a folder of static files. Every one of those is another moving part to maintain and another thing that can break on an upgrade. A brochure site does not need that machinery, and running it anyway is a standing cost with no return.
The owner inherits it. A non-technical owner can update content in a CMS. They cannot edit a React component. The framework quietly decides who is allowed to change the site after launch, the same way content baked into markup decides whether a redesign is a refresh or a rebuild. That decision outlives the developer who made it.
One honest caveat keeps this fair. Next.js can render static HTML at build time, and a Next site built that way is far lighter than a naive client-side app. The cost argument is strongest against the reflex (an interactive framework reached for by default and used to serve static content), not against every possible configuration. The point is narrower: the default reaches for these tools when nothing about the site calls for it.
Content, content with editors, or application
The useful question is not which framework but what the site is, and there are three honest answers. Each one points to a different stack.
Mostly static content, changed occasionally. A static-first build. The page ships as HTML and stays fast because there’s almost nothing to run on the client. This is where a tool like Astro fits: it renders to HTML and ships zero JavaScript by default, adding interactive islands only on the pages that genuinely need them. For a marketing site, that’s the shape that matches the work.
Content a non-technical team publishes regularly. Now the constraint is the editing model, not the rendering. This is the CMS question, and it’s the real exception your instinct should flag: if someone internal has to publish and edit a blog every week, the site needs an editing interface built for non-developers. That points to WordPress done properly, or a static front end paired with a headless CMS. The need for in-house editors, not the need for interactivity, is what changes the answer here.
Actually an application. Authentication, dashboards, role-based access, heavy real-time interactivity. Here React or Next.js earn their weight, because the thing really is stateful and interactive. This is the same line that separates building custom from using an off-the-shelf platform, seen from the front-end side: when the product is an application, you build it like one.
By the end of those three, most people can place their own site. The honest result for a marketing site is almost always the first box, occasionally the second, rarely the third.
When React or Next.js is the right call
The framework is not the villain, and a fair version of this argument has to say where the reflex is correct. React or Next.js is the right call when:
- The site has real application surface, like an authenticated portal or a complex interactive configurator, and the marketing pages are a small part of a larger app.
- A product team already lives in React, and running a separate stack for the marketing pages would cost more in fragmentation than it saves in payload.
- The interactivity is the product itself, not decoration around content.
The right test is simple: is this thing an application? When the answer is yes, reach for the framework with confidence. When it’s no, reaching for it anyway means paying for capability the site will never use.
The decision is made once
The framework question gets argued as if it were about technology, when it’s really about what the site actually is. Decide that honestly at the start, match the stack to the site, and you get a site that’s fast for visitors and cheap to own. Default to the framework you happen to know, and the bill arrives later: in performance, in hosting complexity, and in who’s allowed to change the site after launch. That choice is made once, at the start, and it sets the cost of everything that comes after.
If you’re weighing a proposal and can’t tell whether the stack fits the site, tell us what you’re building. We’ll give you an honest read, and if the simple option is the right one, we’ll say so.