The Minimal JavaScript Website: Why Less Code Means More Authority

This website runs on approximately 20 lines of JavaScript.

No React. No Vue. No Angular. No Next.js. No build step. No node_modules folder. No webpack config. No hydration. No virtual DOM.

Just PHP includes, static HTML, and a nav toggle that is 4 lines long.

And it consistently outperforms JavaScript-heavy sites in AI crawlability, page speed, and structured data extraction. Not because I am a performance optimization genius. Because I did not add the problems in the first place.

The JavaScript Tax No One Talks About

Every JavaScript framework you add to a website comes with a tax. Not just a performance tax. A crawlability tax. An authority tax. A maintenance tax.

Here is how that tax works.

When GPTBot, ClaudeBot, or PerplexityBot visits your page, they do not execute JavaScript. They parse the raw HTML response. If your content is rendered client-side by React or Vue, the crawler sees an empty <div id="root"></div> and moves on. Your 3,000-word article does not exist in their index. Not downranked. Not penalized. Just invisible.

This is not a theoretical problem. According to research from Decantery and LinkFlow AI, JavaScript-heavy sites effectively exist in two versions simultaneously. Human visitors with modern browsers see the full site. AI crawlers see a loading spinner, a bare HTML skeleton, or nothing at all [1].

OpenAI's documentation confirms that ChatGPT's browsing tool uses simplified text extraction rather than full DOM rendering. Perplexity retrieves HTML snapshots without executing JavaScript. Anthropic's Claude focuses on text-based parsing [2].

The framework is not the product. The content is the product. The framework is supposed to deliver it. When it fails to deliver content to the fastest-growing category of web consumers, you have a delivery failure, not a content problem.

What 20 Lines of JavaScript Actually Looks Like

Let me show you what this site actually runs.

The entire JavaScript footprint of hibranwar.com is a mobile nav toggle. Four lines. It listens for a click on the hamburger icon, toggles a CSS class, and that is it. The navigation works without it (links are standard <a> tags in the HTML). The toggle is progressive enhancement, not a dependency.

When an essay needs a data visualization, Chart.js loads from a CDN. Conditionally. Only on pages that have a <canvas> element. If you are reading an essay with no charts, zero visualization JavaScript loads. When an essay needs an architecture diagram, Mermaid.js loads the same way. Conditionally.

That is the entire JavaScript strategy. Everything else is HTML served by PHP includes.

The result? Every page on this site is fully readable in the raw HTML response. Every heading, every paragraph, every link, every piece of structured data. An AI crawler that cannot execute a single line of JavaScript will still get 100% of the content. Because the content was never behind JavaScript to begin with.

Compare that to a typical React single-page application. The initial HTML response contains a <div id="root">, some metadata, and a bundle reference. The actual content requires downloading, parsing, and executing 600 to 800 KB of JavaScript before anything meaningful appears in the DOM.

Here is how the JavaScript payload compares across common architectures.

The difference is not marginal. It is 300x. And that 300x difference translates directly into crawl reliability.

Why AI Crawlers Penalize Complexity

Google has spent two decades building a sophisticated rendering pipeline. Googlebot runs a full Chromium instance. It executes JavaScript, waits for async calls, and indexes the rendered DOM. It is patient, thorough, and expensive to operate.

AI crawlers do not have that infrastructure. And they do not need it, because they are solving a different problem.

Googlebot is building a comprehensive index of the web. It will revisit your site next week. AI crawlers are answering a specific question right now. They fetch a page, extract the relevant text, and move to the next source. If your page requires JavaScript execution to show content, the crawler has already moved on.

As I covered in Page Speed and AI Crawlability, AI crawlers have timeout thresholds as tight as 1 to 5 seconds. A JavaScript-heavy site does not just load slower. It loads empty until the framework finishes booting. That is the critical difference.

A static HTML page that takes 120 milliseconds to serve is not just fast. It is done. The content is there. The structured data is there. The headings, the links, the paragraphs, the FAQ schema. All of it, in the first response.

A React SPA that takes 120 milliseconds for the initial response is just getting started. The browser (or crawler) still needs to download the bundle, parse it, execute it, make API calls, wait for responses, and render the DOM. That process takes 1 to 3 seconds on a good day. On a shared hosting environment or a mobile connection, longer.

The Audit: What JavaScript You Actually Need

Most websites have JavaScript they do not need. Not because the developers were careless, but because the ecosystem defaults to complexity. Install a WordPress theme and you get jQuery, three slider libraries, a lightbox, analytics, cookie consent, and a chat widget. Install a React boilerplate and you get a virtual DOM, a state management library, a router, and a build pipeline.

Here is a practical decision matrix. Every line of JavaScript on your site should fall into one of these categories.

The pattern is clear. Keep JavaScript that enhances the experience without blocking content. Remove JavaScript that sits between your content and the crawler.

The Authority Argument

This is not just about speed. It is about what kind of site you are building.

A site that depends on a JavaScript framework is a site that depends on a supply chain. React is maintained by Meta. Vue by Evan You and sponsors. Angular by Google. Next.js by Vercel. Each of these is a business with its own roadmap, its own breaking changes, its own end-of-life timeline.

When you build on a framework, you inherit its vulnerabilities. Security patches you did not ask for. API changes that break your build. Dependency trees with hundreds of packages, each one a potential supply chain attack vector. The average React project has over 1,000 transitive dependencies in node_modules.

HTML does not have dependency vulnerabilities. CSS does not have breaking changes. A PHP file that includes a header and footer will work the same way in 2036 as it does in 2026. I wrote about this durability in why static websites win in the AI era. The argument has only gotten stronger.

For a practitioner building a credibility site, not a SaaS product, the calculus is simple. You do not need reactivity. You do not need client-side state management. You do not need hydration. You need text on a page that loads fast, crawls clean, and stays up.

The simplest architecture that meets those requirements is the one with the fewest moving parts.

Structured Data Without the Framework

One argument framework advocates make is that modern tooling makes it easier to manage structured data, meta tags, and dynamic content. And they are right, for applications. For content sites, it is the opposite.

On this site, JSON-LD schema is embedded directly in the HTML, inside the PHP header include. It is there in the raw response. No JavaScript execution required. Every AI crawler, every search engine, every scraper sees it immediately.

On a React SPA, JSON-LD is typically injected into the DOM by a component like react-helmet or next/head. If the JavaScript fails to execute (CDN down, browser error, crawler limitation), the schema disappears. Your structured data becomes conditional on framework execution.

That is an unnecessary risk for something as important as how search engines understand your entity.

As I discussed in the relationship between geographic signals and search, discoverability depends on multiple signals working together. Structured data is one of the most important. Making it dependent on JavaScript execution is like putting your business card inside a locked box and hoping everyone has the key.

The Conditional Loading Pattern

I am not anti-JavaScript. I am against JavaScript as a prerequisite for content delivery.

The pattern this site uses is conditional loading. Here is how it works in practice.

An essay about page speed needs a chart. The essay file includes a <canvas> element and sets a custom_js variable in the PHP config. That variable contains a script that checks if the canvas element exists, then loads Chart.js from a CDN, then initializes the chart with the data.

If Chart.js fails to load (CDN down, blocked by ad blocker, JavaScript disabled), the page still works. The essay text is all there. The headings, the key concepts, the FAQ, the references. The chart is a nice-to-have, not a must-have. The data it visualizes is also stated in the prose.

This is progressive enhancement done properly. The baseline experience is complete HTML. The enhanced experience adds interactivity. The baseline never depends on the enhancement.

Most framework-based sites invert this. The baseline is an empty shell. The "enhancement" is the actual content. That is not progressive enhancement. That is a house of cards.

What This Means for AI Citation

AI systems cite sources they can read. That sounds obvious, but the implications are significant.

When ChatGPT, Gemini, or Perplexity answers a question, they retrieve web pages, extract relevant text, and synthesize a response. The pages they can extract cleanly from are the pages they cite. If your content is locked behind a JavaScript rendering pipeline, you are not in the candidate pool.

ALM Corp's research on technical SEO for AI search puts it directly: "Crawlability gets the page seen. Extractability gets the answer used." They define extractability as "the degree to which a system can isolate the useful unit of information from the rest of the page without losing meaning" [3].

A minimal JavaScript site with clean HTML has near-perfect extractability. The useful unit of information (a definition, a comparison table, an FAQ answer) is right there in the source. No rendering required. No DOM manipulation needed. No async calls to wait for.

A JavaScript-heavy site has extractability that ranges from poor to zero, depending on how much content is client-rendered.

This is the authority argument in one sentence: if AI systems cannot read your site, they cannot cite your site. If they cannot cite your site, you do not exist in the fastest-growing discovery channel on the internet.

The Practical Migration Path

If you are running a JavaScript-heavy site and this essay is making you uncomfortable, here is the practical path forward.

Step 1: Audit your JavaScript. Open Chrome DevTools, go to the Coverage tab, and load your homepage. The red bars show JavaScript that loaded but never executed. On most sites, 60% to 80% of loaded JavaScript is unused on any given page.

Step 2: Identify content-blocking JavaScript. Disable JavaScript in your browser and reload your site. Whatever disappears is content that AI crawlers cannot see. That is your priority list.

Step 3: Move content to server-side rendering. If you are using Next.js, enable SSR or SSG for content pages. If you are using WordPress, make sure your theme does not depend on JavaScript for rendering article content. If you are building something new, consider whether you need a framework at all.

Step 4: Conditional-load everything else. Analytics, charts, interactive elements. Load them only when needed, only after the content is in the DOM.

Step 5: Test with a headless fetch. Run curl -s https://yoursite.com | wc -c and compare it to the rendered page size. If the curl response is dramatically smaller than the rendered page, you have a JavaScript dependency problem.

You do not need to rewrite your entire site overnight. But you need to understand what your site looks like without JavaScript, because that is what AI crawlers see.

The Uncomfortable Truth

The web development industry has spent a decade convincing people that they need JavaScript frameworks for everything. Blog posts. Landing pages. Documentation sites. Portfolios. Company websites.

Most of these sites are delivering text and images. That is what HTML was designed for. It has been good at it since 1993.

The uncomfortable truth is that many developers choose frameworks not because the project requires them, but because the developer is comfortable with them. React is familiar. Next.js has a nice developer experience. The tooling is good. The job market rewards framework knowledge.

None of those are user-facing reasons. None of those are crawler-facing reasons. They are developer-facing reasons. And when the developer's convenience conflicts with the crawler's capability, the site loses visibility.

I run three companies. I do not have time to debug webpack configs. I do not have time to update dependencies. I do not have time to figure out why my build broke after a minor version bump of some package I never heard of.

I have time to write content that demonstrates competence, wrap it in clean HTML, and serve it from a PHP include. That is the entire workflow. It has worked for every page on this site. It will keep working when the current generation of JavaScript frameworks is obsolete and replaced by the next one.

Simple systems survive. That is not philosophy. That is engineering.