Framework-Brained

Or: the most important question in web development is one most developers don't know to ask

Could this be a static page?

It's the most important question in web development. And most developers don't know to ask it. Not because they're dumb—because they learned from the top down.

The bootcamp path starts you six abstraction layers up. Rails isn't taught as "one particular way to handle HTTP requests and render responses." It's taught as the thing itself. The primitives are hidden so thoroughly that most developers don't know they exist.

Which means when the framework breaks, or when you need to do something it didn't anticipate, or when you're trying to understand why something isn't working—you have nothing to fall back on. You can't think below the abstraction because you never learned there was a below.

This mattered less when humans were writing all the code. It matters a lot more now.

I learned backwards.

Not by design. By necessity. ADHD wouldn't let me tolerate the cognitive load of frameworks. SQL looked terrifyingly complicated to my brain, so my early public records sites were literally millions of individual static HTML pages—generated once, uploaded to S3, served forever. No database. No state. No complexity to manage.

That sounds primitive, and it was. But those pages still work. A decade later, zero maintenance.

A static file either exists or it doesn't.

There's no ORM bug, no caching layer to invalidate, no schema migration to fail. It's so simple it barely counts as software.

When I eventually needed something more dynamic, I reached for Sinatra—Ruby's minimal web framework. Not because I understood it was "close to the metal," but because it was the only thing I could hold in my head. One file. Routes that looked like what they did. Request in, response out.

DynamoDB instead of Postgres, because key-value had a simpler mental model than relational. Redis because it clicked instantly. Always reluctantly upward, always knowing what I was trading away.

The constraint that looked like limitation was actually an epistemic advantage. I learned there was a ground to stand on.

I once tried to teach web development to a junior by starting where I started: static files, S3, DNS, one-file-per-page PHP. The actual primitives.

It didn't land. He wanted to "learn to code," and to him that meant React, maybe Node, certainly not this. Static hosting wasn't "the basics"—it was some other category entirely, something you'd maybe use for a landing page but not real development.

That's when I realized how unusual my path was. He couldn't see static pages as a starting point because his mental model of web development didn't have a floor. Frameworks were the floor. You stand on Rails or React or Next.js, and below that is dragons—or nothing.

"Framework-brained" isn't an insult. It's a perfectly rational outcome of how most people are taught. A description of a cognitive orientation, not a character flaw.

When you learn top-down, you develop a way of reasoning that only operates at framework altitude. Every problem looks like a framework problem. "How do I do X?" means "what's the Rails way to do X?" or "what React hook handles X?" The possibility that X might not need a framework—that it might be a static page, a shell script, a single SQL query—doesn't enter the solution space.

The question "could this be simpler?" becomes hard to even formulate, because simpler means fewer abstractions, and fewer abstractions means entering territory you've never mapped.

Here's the thing about frameworks: they were a human accommodation.

Like types. Like extensive test suites. Like the dependency ecosystem. Frameworks exist to manage cognitive load—to let teams coordinate without everyone holding the whole system in their heads, to enforce structure that humans need but machines don't care about, to provide guard rails for the ways humans typically fail.

This made sense when humans were writing all the code. Teams needed conventions. Codebases needed structure. "Don't repeat yourself" prevented the bugs that happen when humans copy-paste and forget to update one of the copies.

But what happens when your collaborator is a linguistic intelligence that can hold full context, doesn't get tired, and can regenerate code faster than you can navigate a framework's documentation?

The abstractions that helped humans coordinate become walls that block AI collaboration. The framework's opinions become friction, not guidance.

Claude doesn't need Rails for the reasons humans do. It can reason about HTTP directly. It doesn't need React's component model to manage UI state. It can write vanilla JavaScript that does exactly what's needed, nothing more.

The framework was scaffolding for human limitations. When those limitations aren't the binding constraint anymore, the scaffolding just gets in the way.

So what does "back to basics" look like when the basics have evolved?

This is why I keep coming back to the Cloudflare stack. It's not nostalgia for simpler times. It's that Cloudflare built primitives for the modern web—and primitives are exactly what you want when framework overhead stops paying for itself.

• Workers: A function that takes a request and returns a response. That's it. That's the primitive. No framework opinions about routing or middleware or lifecycle hooks—just the fundamental unit of web interaction, deployed globally.
• D1: SQLite. The minimum viable relational database. Not Postgres with its hundred configuration options, not an ORM abstracting away the queries—just SQL, the actual language, against a file that happens to be distributed.
• KV: Key-value storage. Get a thing by its key. Put a thing at a key. Global, fast, simple. The data structure every programmer understands on day one.
• R2: Files. Bytes with names. Not a "blob storage abstraction layer"—just files, like you'd have on a filesystem, but available everywhere.

This is what primitives look like in 2026. Not a return to 2003, but the same philosophy: give me the building blocks, not the building. Let me compose them into exactly what I need. Don't hide the reality behind six layers of abstraction.

The irony is that my "backwards" path—primitives first, reluctantly upward—is becoming the forwards path.

Not because everyone will have ADHD forcing them toward simplicity. But because AI collaboration rewards the same things my constraints forced me toward: transparency over abstraction, explicit over implicit, code that can be understood by reading it rather than by knowing the framework's conventions.

Framework-brained developers will struggle with this transition. Not because they're less capable, but because their entire way of reasoning assumes the framework floor. Learning to think below it is genuinely hard when you've never had to.

But the ones who can ask "could this be a static page?"—who can think in primitives, who know what they're trading when they reach for abstraction—they're going to build things that actually last.

What's the simplest thing that could work?

Most developers don't know to ask. The ones who do will build things that last.