React vs vanilla JavaScript vs WordPress is the question we get on roughly half of all discovery calls. The honest answer is that all three win at different things, and the wrong stack adds 30 to 100% to the build cost over the project's lifetime. After shipping on all three for over a decade, this is the framework we use to decide which one is the right call, with three real-project receipts at the end so the trade-offs show in numbers, not adjectives.
One thing to clear up before we start: "React" in this article means a modern React stack, usually Next.js, Remix, or an SPA on Vite. "Vanilla HTML/CSS/JS" means hand-written HTML, CSS, and JavaScript without a UI framework, often paired with a static-site generator like Astro, Eleventy, or just a dead-simple build pipeline. "WordPress" means standard WordPress with a custom theme, not a pagebuilder dump.
What does each stack actually solve?
Each stack was built for a different problem. Forgetting that is how studios end up shipping React on every project and wondering why the marketing site is slow.
React solves complex client-side state. When the page has dropdowns that talk to filters that talk to a chart that talks to a search box, all updating live without a server round-trip, React's reactive model is genuinely the right tool. The reason every dashboard you have ever loved is built on React is that the alternative (managing 30 DOM nodes by hand with vanilla event listeners) is a nightmare.
Vanilla HTML/CSS/JS solves shipping fast HTML. When the page is content (text, images, a few interactive bits), the browser is already very good at rendering it. You do not need a 50-kilobyte framework runtime to display a paragraph. Every byte of JavaScript you ship is a byte the browser parses, compiles, and executes before your visitor sees anything.
WordPress solves editorial workflow. The Gutenberg editor in 2026 is genuinely good. A team that writes 5+ articles a week and does not want to file a Jira ticket every time a comma needs to move is the team WordPress was built for. The plugin ecosystem covers SEO, scheduling, multi-author workflow, and a hundred edge cases that are always more work than they look.
When does vanilla HTML/CSS/JS win?
Five project shapes where vanilla is the right answer.
Marketing sites under 30 pages. The site is mostly text and images. There are 4 to 8 places where JavaScript matters: a sticky header, a mobile menu, a form, maybe a marquee. None of those need React. A well built 12 page vanilla site can weigh around 64 kilobytes total in JS, hits Lighthouse 100 on desktop, and renders in under 0.4 seconds on 4G. The same site in Next.js would have weighed 220+ kilobytes before any custom code shipped.
Landing pages and microsites. Short-lifespan, high-craft work. The build needs to ship fast, run fast, and not require a Node.js runtime to deploy. A static HTML file on Cloudflare Pages costs $0/month and outperforms anything else on the market.
Editorial sites with light interactivity. A studio site, a portfolio, a blog, a documentation site. Astro pairs vanilla HTML output with islands of interactivity (a small React or Vue component only where needed). You get the performance of static plus the ergonomics of a component model where you genuinely want one.
Anything where Lighthouse mobile under 4G has to be 95+. Hand-written code is the only category that hits 95+ consistently. Every framework adds runtime weight that compresses the headroom.
Sites that have to outlive the framework's release cycle. Vanilla HTML written today will work in 2036. React 19 will not be running React 19 in 2036. This matters for sites that live a long time without active maintenance, like documentation, references, and brand archives.
When does React win?
Four project shapes where React earns its weight.
Product UIs and dashboards. Internal tools, customer-facing dashboards, admin panels, anything with 30+ reactive components and shared state. React's hooks model and the surrounding ecosystem (TanStack Query, Zustand, React Hook Form) make this category 2 to 3 times faster to build than vanilla.
Sites that share a design system with a product. If your SaaS app is built in React and you want the marketing site to use the same component library, building the marketing site in React (often with Next.js for static rendering) saves you maintaining two design systems. The performance penalty is real but recoverable, modern Next.js with the App Router and partial pre-rendering can hit Lighthouse 90+ on mobile if you are careful.
Anything with serious authentication or account state. Login flows, password resets, multi-step onboarding, gated content with role-based permissions. React patterns for managing session state are mature, well-documented, and what most senior front-end engineers know off the top of their head.
Heavy real-time work. Live chat, collaborative editors, anything driven by WebSockets or Server-Sent Events with frequent UI updates. React's batching and reconciliation handle frequent re-renders better than hand-rolled vanilla DOM manipulation in almost every case past trivial.
When does WordPress win?
Three project shapes where WordPress is the honest right answer.
Editorial publishing at scale. Magazines, news sites, corporate blogs that ship 100+ articles a year with a content team of 4 or more. The author workflow, the scheduling, the role-based permissions, the SEO plugins that copy editors actually understand, all of it is solved out of the box.
Multi-site setups. A company with 5+ regional sites that share branding but vary content. WordPress Multisite, while imperfect, handles this faster than building it custom or stitching multiple Webflow site plans together.
Community sites. Membership, forums, comments, user-generated content under 50,000 monthly users. BuddyPress, bbPress, and the open ecosystem give you 70% of the platform for free.
The fix when WordPress is the right tool but the default stack is too slow: headless WordPress (use it as a content API) with a hand-coded or React front-end. You get the editorial UX where it earns its place and the performance where the user lives. This is more engineering work than a standard WordPress build, but for sites with 100+ articles and serious traffic, the math works.
Three stacks at a glance
| Criterion | Vanilla HTML/CSS/JS | React | WordPress |
|---|---|---|---|
| Typical use case | Marketing sites, landing pages, content | Product UIs, dashboards, complex apps | Blogs, magazines, editorial publishing |
| Performance ceiling (Lighthouse mobile) | 95 to 100 | 75 to 95 (with effort) | 50 to 80 (with optimisation) |
| Build time (10-page site) | 3 to 5 weeks | 5 to 8 weeks | 2 to 4 weeks |
| Learning curve (new dev) | Low | High | Medium |
| Hosting cost (per month) | $0 to $20 | $20 to $250 | $10 to $300 |
| Talent pool | Massive (every front-end dev) | Massive (React is most-asked skill) | Massive but quality varies |
| Maintenance burden | Low | Medium (deps churn fast) | High (plugins + security) |
What are the hidden costs of each?
The numbers nobody puts in proposals.
Vanilla. The hidden cost is engineering judgment. There is no framework holding your hand. Junior engineers ship inconsistent patterns, accessibility regressions, and CSS that fights itself. The fix is hiring a senior or two and writing a tight design system in code. Once you have that, the per-page cost drops below any framework. The team-cost trade-off is real for studios under 5 people.
React. The hidden cost is dependency churn. Your package.json has 1,200 transitive dependencies. Six months from now, half of them have new major versions, and your build pipeline starts complaining. Realistic budget: 4 to 8 hours per quarter just keeping the dependency tree current on a mid size React project. According to Google's Web Vitals research, the larger the JavaScript bundle, the harder it is to keep INP under the 200ms green threshold, which means React projects need active performance budget enforcement to keep ranking signal healthy.
WordPress. The hidden cost is plugin sprawl and security. The "easy install" plugin you added in month two is a vulnerability vector by month fourteen. Real WordPress sites need monthly maintenance: plugin updates, core updates, security audits, performance sweeps. Budget $80 to $200 per month for managed maintenance, or $1,500 to $3,500 per year for an internal sweep.
Why do most developers default to React even when it is wrong?
This is the section the React fan club will not write. Most developers default to React because it is what they know, what their last three jobs used, and what hiring managers expect to see on a resume in 2026. None of those reasons are about your project.
The React-by-default reflex shows up in three patterns we see on incoming briefs. Studios pitch a Next.js rebuild for a 12-page marketing site that does not need it. Founders ask "should we use React?" before they have described what the site does. Job descriptions list "React" as a requirement for roles that will spend 80% of their time writing CSS.
None of this is malicious. It is rational career economics from the engineer's side. React skills are portable. Vanilla HTML/CSS/JS skills are also portable, but the job market does not always recognise them as senior. So engineers learn React, ship React, and rationalise it as the right call.
The question to ask any developer recommending React on a marketing brief: "Walk me through what state on this page actually requires React's reactive model." If the answer is "well, in case we add features later," you are paying for hypothetical future complexity now. We do not.
The honest test: if you can describe the entire page with three sentences and a wireframe, vanilla is probably the right call. If you cannot, React might earn its weight.
How do you pick the right stack for your project?
Three questions in order. Answering them in order produces the right stack roughly nine times out of ten.
- Who will edit the content? If the answer is an editorial team writing more than once a week, weight the choice toward WordPress or a hand-coded site with a clean headless CMS like Sanity or Payload. If the answer is "the marketing lead, occasionally," vanilla or React work fine.
- How interactive does the surface need to be? If the page has fewer than 5 reactive elements (a menu, a form, a few transitions), vanilla wins. If the page has 30+ reactive elements that share state and need consistent updates, React earns its weight. The grey zone in between is where Astro islands or htmx genuinely shine.
- How long is the project meant to last? A 6-month campaign microsite tolerates more aggressive choices (Webflow, off-the-shelf themes) than a 5-year flagship. The longer the lifespan, the more weight performance and longevity get versus speed-to-launch.
If you cannot answer all three with confidence, the project is not ready to scope. Spend 30 minutes with the brief before you spend 30 hours on the proposal.
Three example projects, three different stacks
To make this concrete.
Project A: Series-A SaaS marketing site, 14 pages, sub-second LCP target. The right pick: vanilla HTML/CSS/JS with Astro for islands. Lighthouse mobile: 99. JS bundle on the homepage: 18 kilobytes. Typical market cost: around $13,500. Time to launch: 4 weeks. Right call. The site has been running for 18 months with two CSS edits and zero engineering churn.
Project B: B2B analytics dashboard, 80+ reactive components, real-time data feeds. The right pick: React with Next.js, TanStack Query for data, and Tailwind for styling. Lighthouse mobile on the public marketing pages: 88. The internal app does not need to optimise for first paint, it optimises for interaction latency, which is React's strength. Typical market cost: around $48,000. Right call. Trying this on vanilla would have doubled the timeline.
Project C: Editorial publication, 240 articles per year, 4 writers. The right pick: WordPress with a custom hand-coded theme. Default Gutenberg matched the team's existing workflow. Plugins handled SEO, scheduling, and multi-author permissions out of the box. Lighthouse mobile: 78, which the editor accepted as the right trade-off for the throughput gain. Typical market cost: around $19,500. Right call.
The shortest version of the answer
React vs vanilla JavaScript vs WordPress is not a fight, it is a fit question. Match the stack to the brief. Most marketing sites do not need React. Most product apps do need React. Most editorial sites still benefit from WordPress under the hood, even if the front-end is hand-coded. To talk through your specific use case, our contact page is the fastest route, and our services page lists what we ship at each tier.