Every agency we compete against builds on React. Or Next.js. Or Nuxt. Or Gatsby. Or Astro. The JavaScript framework ecosystem moves so fast that the stack you chose last year is already legacy.
We don’t use any of them. And it’s the best technical decision we’ve made.
The Framework Tax
Here is what happens when you build a business website on React:
- 200-400KB of JavaScript before your first word of content loads. A vanilla HTML page loads in under 50KB.
- A build step that adds complexity, dependencies, and failure points. Our sites have no build step. The code you write is the code that ships.
- A dependency tree of hundreds of packages — each one a potential supply chain attack vector. The Axios attack proved this is not theoretical.
- Framework churn. React Server Components, the App Router, Suspense boundaries — the API surface changes constantly. Code written two years ago needs refactoring to follow current best practices. Vanilla JavaScript from 2016 still works perfectly.
- Hiring complexity. You don’t just need a developer — you need a React developer, ideally one who knows your specific stack (Next.js vs Remix vs Vite). Vanilla JS is readable by any web developer.
None of this is controversial. The React team themselves acknowledge the bundle size problem — it’s why they’re pushing Server Components. But Server Components add their own complexity, their own learning curve, and their own failure modes.
For a business website — even a sophisticated one — the framework tax buys you nothing that the browser doesn’t already provide.
What the Browser Already Does
Modern browsers are extraordinarily capable. The platform features that frameworks were invented to paper over now exist natively:
-
fetch()replaced jQuery’s AJAX and Axios for HTTP requests. Built into every browser and Node.js. -
history.pushState()enables client-side routing without React Router. Our SPA uses 30 lines of vanilla routing code. - CSS Grid and Flexbox replaced Bootstrap’s grid system. No framework needed for responsive layouts.
- CSS Custom Properties replaced Sass variables. Dynamic theming in pure CSS.
-
document.querySelector()replaced jQuery’s selector engine. Same API, zero dependencies. - Template literals replaced JSX for dynamic HTML generation. Less syntax, same result.
- ES Modules replaced Webpack and bundlers for code splitting. Browsers handle imports natively.
The gap between what the platform provides and what frameworks add has been shrinking for years. For business websites, that gap is now effectively zero.
What We Actually Build
The DESIGN-R.AI website you’re reading this on is a single-page application. It has client-side routing, dynamic content loading from a headless WordPress API, smooth transitions between pages, and a real-time chat widget. Total JavaScript: under 15KB.
A comparable React implementation — with React, ReactDOM, React Router, and a data-fetching library — would start at 150KB minimum before writing a single line of application code.
Our client sites follow the same pattern. A dive centre website we built in the Philippines is a full SPA with:
- Page routing for 30+ course pages
- Dynamic blog with featured images
- WhatsApp form integration
- Google Maps embed
- Hero image preloading
- Content caching
The entire application is a single JavaScript file. No framework, no build step, no node_modules. It loads instantly on a patchy LTE connection because there’s nothing to download except the content.
The Performance Argument Is a Business Argument
Google’s research consistently shows that page load speed directly affects conversion:
- A 1-second delay in mobile load time can reduce conversions by up to 20%
- 53% of mobile users abandon sites that take over 3 seconds to load
- Core Web Vitals are a confirmed Google ranking factor
When your competitor’s React site takes 3 seconds to become interactive and yours takes 0.5 seconds, that’s not a technical curiosity — it’s a competitive advantage measured in revenue.
For a dive shop in the Philippines serving tourists on hotel Wi-Fi, the difference between a 150KB and a 15KB application is the difference between a booking and a bounce.
When Frameworks Make Sense
We are not anti-framework dogmatists. React makes sense for:
- Complex interactive applications — dashboards, editors, real-time collaboration tools where you’re managing dozens of interdependent UI states
- Large teams — where the framework’s conventions provide guardrails and consistency across 20+ developers
- Apps with very complex state — shopping carts, multi-step forms with validation, live data streams
A business website is not any of these things. It’s a handful of pages, a contact form, maybe a blog, and some dynamic content. The browser handles this natively. A framework adds weight without adding capability.
The question is not “is React good?” — it’s “does this project need React?” For every business website we’ve built, the answer has been no.
The Real Advantage
Building without frameworks gives us three things that matter to clients:
Speed. Not just page load speed — development speed. Without a build step, without framework boilerplate, without dependency management, we ship faster. Changes are immediate. There’s no “wait for the build” step between writing code and seeing results.
Longevity. Vanilla JavaScript doesn’t have a deprecation cycle. There’s no framework upgrade treadmill. The sites we build today will work identically in five years. A React site built today will need framework updates, dependency patches, and potentially significant refactoring within 18 months.
Security. Zero third-party dependencies means zero supply chain attack surface. When the next Axios happens, our sites are unaffected. When a build tool gets compromised, our sites are unaffected. The only code running is code we wrote.
Speed, longevity, and security — not because we’re chasing a trend, but because we chose the boring technology that actually delivers.
Key Facts: The Vanilla JavaScript Approach
- Bundle size comparison: React + ReactDOM + React Router minimum: ~150KB. Our vanilla SPA: ~15KB. That’s a 10x reduction before any application code.
- Dependencies: A typical create-react-app project installs 1,400+ packages. Our sites install zero client-side dependencies.
- Browser support: Vanilla JavaScript features (fetch, CSS Grid, ES Modules, pushState) are supported in every modern browser. No polyfills needed.
- Build time: Zero. No webpack, no Vite, no compilation step. Write, save, deploy.
- Framework churn: React has had 3 major API paradigm shifts in 4 years (Hooks, Server Components, App Router). Vanilla JS has had zero breaking changes.
Frequently Asked Questions
Q: Isn’t vanilla JavaScript harder to maintain than a framework?
A: For large applications with complex state, yes. For business websites with 5-30 pages of mostly static content? No. Vanilla JS is simpler to read, debug, and modify because there’s no abstraction layer to learn.
Q: How do you handle state management without React?
A: Business websites don’t need state management. They need to fetch content and display it. A simple object cache and DOM updates handle this in a few lines of code.
Q: What about SEO without server-side rendering?
A: Google’s crawler executes JavaScript and indexes SPA content. For critical SEO pages, we also maintain static HTML versions that search engines can crawl without JS execution. Best of both worlds.
Q: Can vanilla JavaScript scale to complex sites?
A: We build full SPAs with 30+ routes, dynamic content from headless WordPress, client-side caching, image preloading, and real-time features — all in vanilla JS. The question isn’t whether it scales, it’s whether you need more than the platform provides.
Q: Why not use a lightweight framework like Svelte or Alpine.js?
A: Both are excellent and much lighter than React. But they still add a dependency, a build step (Svelte), and a learning curve. For business websites, native browser APIs do everything these frameworks do. The best dependency is the one you don’t have.
Originally published at DESIGN-R Intelligence
Top comments (0)