I learned HTML from a website called Funky Chickens.
This was 1999. The site promised to teach you “the special codes that make your website colorful, cool, and professional looking.” It had a page dedicated to explaining what the <blink> tag did. I thought this was the height of web development. I was eight.
My pages lived on freewebs.com, expages.com, geocities.com, angelfire.com, and tripod.com—whichever free host hadn’t yet suspended me for exceeding my 5MB storage limit with GIFs. I was active on buddy4u. The pages were objectively terrible. Tiled backgrounds that induced migraines. Visitor counters that I refreshed myself to feel popular. Guestbooks where I left my own comments under fake names. <marquee> tags on everything. I thought horizontal scrolling text was what separated amateurs from professionals.
But here’s the thing: I understood every line. The feedback loop was immediate. Type something, hit refresh, see what you made. No build step. No bundler. No node_modules folder the size of a small planet. Just a text file and a browser.
I didn’t know what a server was. I didn’t need to. The mental model was simple: write HTML, see HTML. A child could do it. A child did do it. That child’s websites were hideous, but they worked.
When I was nine years old, I tried to build an authentication system. Username field, password field, submit button. I couldn’t figure out why it didn’t work. I had the form. I had the inputs. I’d even added type="password" so the characters showed up as dots, which felt very professional. But when I clicked submit, nothing happened. The page just refreshed.
I didn’t understand that forms needed somewhere to go. That there had to be something on the other end to receive the data, check it against something, and decide what to do next. I thought the HTML was the whole thing. I thought you could authenticate users with markup alone.
It took me an embarrassingly long time to realize you needed a server—years. I just kept adding more HTML, convinced I was missing a tag.
The classroom moment
A few years ago I was doing a workshop with a class of high schoolers. Most had some experience with JavaScript—and you guessed it, React. This is like learning to drive in a Formula 1 car and then being confused by a bicycle.
I built a small demo app. Server-rendered HTML. Click a link, the server sends back a new page. The browser loads it. Done.
They looked at me like I’d performed a magic trick. Not the good kind—the kind where you’re not sure if the magician is very clever or has simply lost his mind.
One of them asked how the page knew to update without JavaScript. Another asked where the state was being managed. A third asked if I’d forgotten to include the frontend.
The state was being managed by the URL. The page “knew” to update because that’s what browsers have done since 1991. The frontend was the HTML. I had not, in fact, forgotten it—it was the only thing there.
I showed them a form submission. A real one—method POST, action pointing to a route, the browser handling the redirect. No e.preventDefault(). No fetch(). No seventeen useEffect hooks to manage loading states.
Someone asked if this was a legacy pattern.
I briefly considered finding a bridge.
The overcorrection
Here’s what happened: somewhere during the 2010s, we collectively decided that single-page applications were the future. And they were—for Gmail. For Google Maps. For highly interactive applications where the user never leaves the page and the data changes constantly.
React was built for Facebook. When I (briefly) used Facebook’s ad manager—a genuinely complex interface with dozens of interdependent states, real-time updates, and interactions that would be nightmarish to manage with jQuery and manual DOM manipulation—I was like, “okay, this makes sense why they’d use React.” That’s a real problem, and React solves it well.
I haven’t had that feeling since.
Here’s the thing: you don’t have Facebook’s ad manager. Almost nobody does. The level of UI complexity that justified React’s creation exists at maybe a dozen companies. The rest of us are building forms that submit data and pages that display it.
For a blog? For a marketing site? For the vast majority of CRUD applications? React adds complexity that doesn’t pay for itself. Yes, React has improved—server components are a thing, bundle sizes have shrunk, the hydration story is better. But the fundamental issue isn’t React’s weight. It’s that reaching for a component framework before understanding what the browser provides for free creates developers who can’t debug without React DevTools.
The bootcamps taught React because React was in demand. React was in demand because companies used React. Companies used React because that’s what candidates knew, or wanted to use because it was the new hot kid in school. The snake ate its own tail and called it an ecosystem.
Somewhere in this loop, we stopped teaching what the browser actually does. We taught abstractions on top of abstractions on top of a rendering engine that’s been perfectly capable of displaying documents since before most of these developers were born. We taught people to hydrate before they knew what they were hydrating. We taught them to manage state before they knew there was no state to manage.
The result is a generation of developers who genuinely don’t know that you can submit a form without JavaScript. Who think a full page reload is a bug, rather than a feature that browsers have been providing for free since the Clinton administration. Who’ve never written a <form> with a method and an action and nothing else—and when they see one, they assume something is missing.
What we lost
I’m not nostalgic for dial-up. I don’t miss waiting three minutes for a single image to load line by line. I don’t think we should return to table-based layouts, and my <marquee> days are firmly behind me.
But we lost something when we stopped teaching fundamentals.
We lost the understanding that HTML is a complete delivery mechanism. That browsers are absurdly capable on their own. That most of what we build doesn’t need a virtual DOM, or client-side routing, or a build pipeline that takes thirty seconds to start, or a state management library to track whether a button has been clicked.
The developers in that classroom weren’t stupid. They were taught wrong. They learned tools before they learned what the tools replaced. It’s like teaching someone to use a calculator before they understand arithmetic—technically it works, but when the calculator breaks, they’re helpless. Except in this case, the calculator is a JavaScript bundle and a build pipeline, and “breaking” means the user has JavaScript disabled, or a slow connection, or the CDN is down, or any of a dozen failure modes that HTML handles gracefully by default.
The Funky Chickens curriculum
What Funky Chickens taught me—without meaning to, because it was just some person’s hobby site from 1999—was how the web actually works. Not how React works. Not how webpack works. How the browser works. How HTTP works. How a request becomes a response becomes pixels on a screen.
You write a file. A server sends it. A browser renders it. That’s it. Everything else is optimization, or complication dressed up as optimization.
I’m not saying we should send junior developers to a website from 1999 that teaches the <blink> tag. Funky Chickens noted that some of its code didn’t work on expage.com, which tells you something about the level of browser compatibility hell we were operating in. The whole thing was probably built in Microsoft FrontPage.
But maybe—before we teach developers how to avoid page loads—we should make sure they understand what a page load is. Before we teach them to manage state, we should show them applications that don’t need state. Before we hand them React, we should give them a text file and a browser and see if they can make something ugly and functional and entirely their own.
Yes, some applications genuinely need client-side interactivity. Real-time collaboration. Complex form validation that would be painful to round-trip. Drag-and-drop interfaces. I’m not arguing against JavaScript. I’m arguing against teaching JavaScript frameworks before teaching what JavaScript is replacing.
The marquee tags were bad. The guestbook comments I left for myself were sad. But the fundamentals were solid, and twenty-five years later, I still haven’t found a better feedback loop than “type, save, refresh.”
Funky Chickens understood something we’ve forgotten: the web is simple until we make it complicated. Though, to be fair, at one point I did bootstrap an SPA to serve this entire site and use Jekyll to generate a bunch of JSON…