Everyone who has looked at the FloppyCougar codebase has said the same thing: use a framework. React. Next.js. Astro. Something with components, a build step, a package.json with dependencies you've never heard of.
This site doesn't use one. Every page is plain HTML and CSS, built with Claude as the coding collaborator — no bundler, no node_modules, no component library. The decision was deliberate. Here's why.
The Framework Pitch
Every framework exists to solve a real problem. React exists because updating the DOM is annoying at scale. Next.js exists because server-side rendering matters for performance at serious infrastructure. These are legitimate problems.
They're not FloppyCougar's problems. This is a portfolio and consultancy site with about 12 pages. No dynamic newsfeed, no shopping cart, no real-time state management. Just text, images, and CSS that makes things look right.
Using a framework here means adding a build process, a local dev environment, a deployment pipeline, a dependency chain, and a layer of abstraction between the code and the browser. That's not solving problems — it's creating them.
The Real Reason
The goal was to be able to read the entire codebase in an afternoon. Not understand it in the "I know this codebase" sense — actually read every line of code that runs when someone visits the site.
That's not possible with a framework. React has a runtime. Next.js has routing logic and server components. You can understand the abstraction, but the code that actually runs is thousands of lines nobody wrote and can't audit. For a site that's supposed to demonstrate how FloppyCougar builds things, having opacity in the foundation felt wrong.
The Actual Stack
<style> tags. Vanilla JavaScript where necessary. Google Fonts via CDN. Images optimized manually. Deployed straight to Netlify from a folder. No build step. No bundler. No npm install.
The site is a folder of .html files. Netlify serves them. The browser renders them. The gap between what was written and what runs is essentially zero — which means it loads fast, deploys in seconds, costs almost nothing, and has no dependency security surface at all.
The Trade-offs
This approach has real costs. Navigation updates have to be made on every page — there's no shared component. Dynamic content isn't possible without a different architecture. At 12 pages, the repetition is manageable. At 200, it would genuinely break down.
These are the right trade-offs for this project. They'd be wrong for a different one.
Why Plain HTML Works Better With AI
The unexpected benefit: plain HTML is dramatically easier to work with when Claude is your collaborator.
Working on a file means handing Claude the complete file. Claude reads it, understands the design system, the layout patterns, the specific conventions in use — and adds or edits within that context. No architecture overview required. No "here's how the routing works." Just the file, top to bottom, containing everything.
With a framework, the conversation has to include: here's the routing, here's the component structure, here's how the build transforms things. That's all overhead before touching the actual work. Simpler code makes better AI collaboration possible — not despite the lack of abstraction, but because of it.
When a Framework Would Be Right
This isn't anti-framework. It's anti-using-a-framework-as-a-default. The conditions where one is clearly correct: multiple developers who need shared conventions, dynamic content that can't be maintained as static files, complex state management, sites over ~50 pages, or a team already fluent in that framework.
None of those apply here. The question isn't "should I use a framework" — it's "does this project have a problem a framework would solve." For most small business and portfolio sites, the answer is no. Most people use one anyway because it's the default, not because they've thought it through.
Think it through. Build accordingly.