Stop Using JavaScript Frameworks You Don’t Need

If plain HTML, modern CSS, and a little vanilla JavaScript can build your site, then a JavaScript framework for your website is a liability, not an upgrade. It costs you Google indexing, hides you from AI crawlers, slows your conversions, and stacks up maintenance debt you will pay for later. That is the whole argument, and I will spend the rest of this article proving it with real refactor numbers.

I have been building websites in Charlotte since 1998. In that time the tools have changed a dozen times over. The mistakes have not. And the most expensive mistake I watch small and mid-market business owners make right now is letting someone wrap a perfectly good WordPress marketing site in React or a badly configured Next.js hybrid because it will feel “app-like.”

Most agency posts on this topic are written by developers defending their stack. This one is written by the people who get called in to rip that stack out. Different vantage point. Different advice.

Does my website need a JavaScript framework?

Probably not. Here is the test I run before I recommend any framework or headless stack. Three questions. If you answer “no” to all three, a framework is an expensive technical trap.

1. Does the frontend need complex, offline-first application state? A real-time web app, a live dashboard, a portal that has to work without a connection. Marketing pages do not.
2. Is the same content being distributed to non-web endpoints at the same time? Native iOS and Android apps, smart displays, kiosks pulling from one API. A brochure site serves one endpoint: the browser.
3. Do you have a dedicated engineering team and at least $30,000 a year set aside just to maintain API layers and build pipelines? Not marketing budget. Engineering budget, on top of everything else.

Three “no” answers means you are looking at a headless React or Next.js build that costs more, breaks more, and buys you nothing your customers can feel. The framework is not solving your problem. It is somebody’s résumé.

Practical rule: Pick the framework for the software you are actually shipping, not for the site you are actually shipping. Those are two different projects.

What does client-side rendering do to your Google rankings?

Client-side rendering forces Googlebot to download, parse, and execute your JavaScript before it can see your content. That extra step is slow, it fails sometimes, and it demotes you when it fails. Server-rendered HTML hands Google the content immediately. No render step, no gamble.

Here is a real one. A client insisted on converting their functioning WordPress e-commerce site to a client-side rendered React frontend connected over the REST API, because their previous agency said it would feel more like an app. The results were not subtle.

• Largest Contentful Paint went from 1.6 seconds to 4.4 seconds. The browser had to pull down and run massive JavaScript bundles before it painted a single product.
• Interaction to Next Paint sat around 380ms. The main thread was blocked during component hydration, so the page looked ready and did not respond.
• Organic search traffic dropped 24% over four months. Googlebot could not reliably render the second-tier category pages, so those pages fell out of favor.

We scraped the SPA layer off, reverted to server-rendered PHP templates, and rebuilt the interactivity with native browser APIs. Core Web Vitals flipped back to green and organic traffic fully recovered within 60 days. Nothing about the business changed. Only the delivery layer did.

People will tell you Google renders JavaScript now, so this does not matter. Google does render JavaScript. It renders it in a second pass, on a delay, when it has crawl budget to spare, and it gives up when the render is heavy or slow. Betting your category pages on the mood of Google’s render queue is not a strategy. Google’s own guidance is explicit that JavaScript adds a rendering stage that can delay or block indexing.

If you want more of the myths in this category taken apart, we did that separately in 21 SEO myths debunked. “Google renders JS so CSR is fine” belongs on that list.

Why AI crawlers make client-side rendering even worse

AI crawlers mostly do not render JavaScript at all. GPTBot, ClaudeBot, and PerplexityBot fetch your raw HTML and read what is in it. If your content only exists after JavaScript executes in a browser, those crawlers see an empty shell. To an AI answer engine, a client-side rendered site is close to invisible.

This matters more every quarter. A growing share of search now happens inside AI answers instead of a list of blue links. When ChatGPT, Claude, or Perplexity build an answer, they pull from pages whose content is present in the fetched HTML. A React SPA that renders in the browser gives them nothing to pull.

So the client-side framework does not just cost you a slice of Googlebot’s patience. It quietly removes you from the fastest-growing discovery channel there is. We wrote about that shift in detail in from SEO to AEO, and the single biggest technical prerequisite for AEO is boring: your answer has to be in the HTML.

Practical rule: If a crawler that does not run JavaScript cannot read your page, your page does not exist to the AI answer layer. Server-render, or disappear.

The headless WordPress overengineering trap

Headless WordPress with a React or Next.js frontend is the wrong tool for a standard marketing site, and it is the mistake I see pitched most often. Developers sell it as “infinite flexibility” and “decoupled architecture.” What it actually delivers to a 30-to-100 page site is friction and cost.

• It doubles your infrastructure. Now you run two hosting environments: a WordPress host for the CMS backend and Vercel or Netlify for the frontend. Two things to break, two bills, two on-call surfaces.
• It breaks the parts of WordPress you actually use. Live page previews, Gutenberg block styling, visual page builders, and clean SEO plugin integration all stop working the way non-technical staff expect.
• It adds $500 to $1,200 a month in server overhead and developer maintenance for zero benefit your visitors will ever notice.

Read those bullets back. You are paying more, breaking your editing experience, and adding failure points, in exchange for an architecture your customers cannot see and your marketing team cannot use. That is not flexibility. That is a tax.

The editing experience point is the one owners underrate. On a normal WordPress build, someone on staff updates a team profile or adds a case study in five minutes. Break the CMS with a headless layer and that same edit becomes a developer ticket. Now you are paying a person to do what a plugin used to do for free.

Framework versus no framework: the honest comparison

Here is the tradeoff laid out flat, for a typical marketing or small e-commerce site. Not a web application. A site.

Framework versus no framework for a typical marketing or small e-commerce site.

If you are choosing a platform for a store rather than a brochure, we go deeper on the same reasoning in the Charlotte ecommerce website design guide. Short version: the storefront that loads fast and indexes cleanly outsells the one that feels “app-like” and stalls on mobile.

Case study: stripping JavaScript bloat to quadruple performance

A regional manufacturing client came to us with a custom site built on an overengineered Vue.js frontend sitting on top of WordPress. It felt sluggish, it was failing mobile usability tests, and lead generation had flatlined. The owner could feel that something was wrong. They just could not name it.

The diagnosis was blunt. The site forced every visitor to download 1.8 MB of JavaScript across 14 compiled assets before it would reveal basic text and product catalog pages. People were staring at a blank layout while a Vue build pipeline warmed up to show them a paragraph.

The refactor was to dismantle the Vue build entirely. We re-architected the layout in native WordPress templates and rebuilt every interactive piece (the filtered galleries, the accordion spec sheets, the modal quote forms) with plain HTML, modern CSS grid and flexbox, and 12 KB of vanilla JavaScript. No library. No build step.

• JavaScript payload: 1.8 MB down to 12 KB. A 99% reduction.
• Total load time: 4.2 seconds down to 800 milliseconds.
• Bounce rate: 61% down to 34%.
• Quote-request conversion rate: up 42% within 90 days.

The project took 35 hours of development effort, roughly $4,500, and paid for itself in new pipeline value inside two months. That is the dollar link between speed and conversions, stated plainly. Slow sites lose money. Fast sites make it. Studies on Core Web Vitals repeatedly tie faster load and lower interaction delay to lower bounce and higher conversion, which is exactly what these numbers show.

Notice what did not happen. We did not add features. We did not redesign the brand. We removed weight. The framework was the problem, and deleting it was the fix.

Practical rule: Every kilobyte of JavaScript is a tax the user pays before they see your offer. On a marketing site, aim for kilobytes, not megabytes.

What a mid-market Charlotte business actually needs

Most small and mid-market businesses in Charlotte do not need a reactive state tree. Law firms, commercial HVAC providers, industrial distributors, financial advisors, specialty healthcare practices. I have built for all of them. None of them needed React to book a consultation.

What they actually need is four things.

1. Sub-second page loads on 4G and 5G mobile. Most of your local traffic is on a phone, standing in a parking lot, deciding whether to call you.
2. Flawless local schema and technical SEO structure. So Google and the AI engines both understand who you are, where you are, and what you do.
3. Bulletproof form submissions wired into the CRM. HubSpot, Salesforce, whatever you run. A lead that does not reach the CRM is a lead you paid for and lost.
4. An editing experience your staff can use without a developer. Add a case study, update a bio, publish a service page, in five minutes.

WordPress core plus native PHP plus modern vanilla JavaScript handles 98% of that effortlessly. Vanilla JavaScript already does mobile menu toggles, async AJAX search bars, tabbed interfaces, and modal forms with no library and no build step. The web platform got good. A lot of framework code exists to solve problems the browser now solves for free.

This is the backbone of how we approach Charlotte web design and WordPress development. Build light, index clean, convert fast. Contractors specifically can see the same logic applied to lead generation in our guide for Charlotte contractors.

When you SHOULD reach for a framework

A framework is the right choice when you are building actual in-browser software, not pages. That is the honest line, and I will not pretend it is never crossed.

The times I do recommend React or Vue look like this:

• An interactive 3D product configurator where the user rotates, swaps, and prices a product live.
• An enterprise mortgage calculator with dynamic charting that recomputes as inputs change.
• A multi-tenant client portal dashboard where logged-in users manage real state across sessions.

Those are software. They have complex client-side state, real interactivity, and a reason to run logic in the browser. A framework earns its weight there. That work lives under web application development, and it is a different discipline from building a website.

The key move is separation. Build the software feature as a contained application and mount it inside a fast, server-rendered marketing site. Do not turn the whole site into an application because one page needed to be one. That is the error underneath most of the messes we clean up.

Résumé-driven development is not your problem to fund

I will tell on myself. In the mid-2010s, when the modern JS frameworks exploded, I built a custom Vue.js product filter for a small industrial supplier. Not because the project needed Vue. Because I wanted to run Vue in production. Résumé-driven development, and I was the one doing it.

It worked fine at first. Two years later the Node dependencies had updated, the build tools had deprecated, and the client was stuck with a broken build pipeline for what was, in the end, an interactive menu. I spent eight unbillable hours fixing build errors just to change a minor styling bug. Eight hours. On a filter that 25 lines of standard JavaScript would have handled, forever, with no pipeline to rot.

That is the maintenance debt nobody quotes you up front. A framework build is not a one-time cost. It is a subscription to somebody else’s release schedule. The dependencies keep moving whether your business needs them to or not.

So we made a rule for every client project.

Zero Build Step First policy: Developers on our projects may not introduce NPM packages, build tools like Vite or Webpack, or external JS frameworks unless they submit a one-page business justification proving native Web APIs cannot achieve the exact same outcome.

If a developer wants to learn a trendy framework, they do it on a side project. Not on a client’s production site, where the client inherits the technical debt and pays the maintenance bill for years. Your website is not a training ground for someone else’s next job interview.

This is also why vetting matters when you hire. Ask a developer why they chose their stack. If the honest answer is “it’s what I like to build in,” keep interviewing. If you need help running that conversation, the web developer vetting checklist gives you the questions to ask before you sign anything.

How to tell if a framework is quietly hurting your site right now

You do not need a developer to spot the symptoms. Here are the first checks I run when an owner suspects their build is working against them.

1. View the page source, not the rendered page. Right-click, “View Page Source.” If your headlines and body copy are not in that raw HTML, your content depends on JavaScript to appear, and crawlers may not see it.
2. Run the URL through PageSpeed Insights. Look at the JavaScript payload and Total Blocking Time. Megabytes of JS on a brochure page is a red flag.
3. Check your indexed pages in Google Search Console. If second-tier pages like categories or service detail pages are dropping out of the index, rendering may be the cause.
4. Test on a real phone on cellular, not office WiFi. If the layout hangs blank before content appears, your visitors feel that every time.
5. Ask who edits the site. If every content change is a developer ticket, a headless or heavily-framework build has already cost you your independence.

Do not rip anything out based on a hunch. Confirm the problem first. We keep a working list of tools for exactly this in the best website audit tools roundup, and if you want a human read on the results rather than a raw report, that is what a second opinion audit is for.

Practical rule: Diagnose before you demolish. Confirm the framework is the cause, then remove it deliberately, one interaction at a time, so nothing that worked stops working.

What removing a framework the right way looks like

Ripping out a framework blindly is how people turn one problem into three. A clean strip-out follows an order, and the order protects your rankings while you work.

1. Inventory the interactivity. List every dynamic thing on the site: menus, filters, tabs, modals, forms. Most of them have a vanilla equivalent that already ships in the browser.
2. Rebuild content pages as server-rendered templates first. Get the words into the raw HTML so crawlers and AI engines can read them before you touch anything fancy.
3. Replace interactivity with vanilla JavaScript, one piece at a time. Menu toggle, then search, then tabs, then modals. Ship and verify each one.
4. Preserve URLs and redirects religiously. This is where migrations lose rankings. Map old to new before launch, not after.
5. Recheck Core Web Vitals and indexing after launch. Confirm the green scores and watch Search Console for pages coming back into the index.

Step four is the one that bites people. Changing your delivery layer is a migration, and migrations kill rankings when redirects are sloppy. We wrote the field guide for that in WordPress site migration without losing SEO rankings. Read it before you move a single URL.

And once the site is fast and clean, keep it that way. A light build stays light only if the next person to touch it respects the same rules. That is what ongoing website maintenance protects: the discipline that made the site fast in the first place.

The honest bottom line on frameworks for your website

Short version. A JavaScript framework for your website is a business decision, not a technical preference, and for most marketing and small commerce sites the business case runs against it. You lose Google’s reliable indexing. You vanish from the AI crawlers that do not render JavaScript. You slow the page and shrink the conversion rate. You inherit a maintenance subscription you will pay in unbillable hours later.

Reach for a framework when you are shipping real in-browser software. For everything else, WordPress plus PHP plus a few kilobytes of vanilla JavaScript will beat it on every metric that pays your bills.

Your next step is simple. Run the five checks above on your own site today. If your content is missing from the page source, or your JavaScript payload is measured in megabytes, you already have your answer. When you want a second set of eyes on what to do about it, reach out to us. We have been stripping the excess off Charlotte websites since 1998, and we will tell you honestly whether your site needs a framework or just needs to lose the weight.