Gil Pagefault has been building for the web since 1997, when his first project was a parts catalog for his uncle's auto shop in Kenosha, Wisconsin. He's been an individual contributor his entire career — twenty-nine years without once accepting a management title — and currently works as a staff engineer at a mid-size SaaS company in Milwaukee. He has mass in this industry the way a river stone has mass: not from force, but from staying in one place while everything else rushed past.

We spoke over video. Gil's home office has exactly one decoration: a framed printout of the W3C's HTML 2.0 specification, which he says he keeps "as a reminder that the spec used to fit in a binder." He was drinking coffee from a mug that read It Works On My Machine, a gift from a coworker who thought it was ironic. Gil does not think it's ironic.

You started building websites in 1997. What was the rendering conversation like back then?

Gil: There wasn't one. Nobody sat around debating server-side versus client-side rendering in 1997 because there was no client side. You wrote a Perl script, it spat out HTML, the browser showed it. If you wanted something dynamic, you submitted a form and the whole page reloaded.

I think about this a lot, actually. How the absence of a choice gets retroactively turned into a position. People now say "server-side rendering" like it was a camp you belonged to. In 1997 it was just... the web. Calling it server-side rendering is like calling walking "non-motorized transportation." Technically accurate. Completely misses what it felt like.

When did you first feel the ground shift?

Gil: Gmail. 2004. I opened it and thought, this isn't a webpage. The way it loaded messages without refreshing. That sounds trivial now, but every interaction on the web until that point involved watching a white screen flash while the server round-tripped. Gmail felt like someone had removed gravity. A constraint you'd internalized so completely you'd stopped noticing it, and then it was just gone.

That was a real moment. The excitement was proportional to the breakthrough. jQuery came along in 2006 and made it accessible to regular developers, not just Google engineers, and suddenly everyone could build things that felt alive. I built some of the best stuff of my career in that window. 2006 to maybe 2011. The tools were simple, the possibilities were expanding, and nobody had yet decided you needed a build pipeline with fourteen dependencies to render a contact form.

So when did it go wrong?

Gil: "Wrong" is too strong. It got ambitious in a way that lost track of the problem.

React comes out in 2013, and within two years the entire industry has decided that every website is actually an application and every application needs a component tree and a state management library and a bundler and a transpiler.

Look, React solved real problems for Facebook-scale interfaces. But the leap from "this solves a specific problem at scale" to "this is how all web development should work" happened socially, not technically. Conference talks. Blog posts. Job listings that required React for a marketing site with four pages.

There was this post in 2016, José Aguinaga's "How it feels to learn JavaScript in 2016."¹ Hit number one on Hacker News twice. Ten thousand likes on Medium.² A fake dialogue where someone tries to build a simple web page and gets buried in tooling. The reason it went everywhere wasn't because it was funny — I mean, it was funny — but because it described an experience that thousands of developers were having privately and feeling vaguely ashamed about. Like, maybe I'm just not smart enough to understand why I need all this.

I was not feeling ashamed. I was feeling annoyed.

You've now watched the industry announce three times that it's figured out where rendering belongs. What does the third time feel like?

Gil: (long pause)

The first time was Ajax. "The server is for data, the client is for presentation, we've figured it out." The second time was SPAs going mainstream. "Everything is a client-side application now, the server is just an API, we've figured it out." And now it's React Server Components and the whole server-first resurgence. "Actually the server should render the HTML, we've figured it out."

Each time, the certainty is total. Each time, there's a real technical improvement underneath the certainty. And each time, the certainty is the part that ages worst.

The current moment — the tooling is genuinely better. SSR in 2026 is not what I was doing in 1997.³ Edge rendering, incremental static regeneration, streaming. Real capabilities. I'm not going to pretend a PHP script on shared hosting is equivalent to what Next.js does.

But when someone tells me React Server Components cut initial render times by 67%⁴ — and I believe that number — my first thought is: 67% faster than what? Faster than the client-side rendering approach that replaced the server-side approach that was already fast because it didn't have to ship a JavaScript runtime to the browser in the first place.

That sounds like cynicism.

Gil: Maybe there's a thin film of cynicism. I'll own that. But what I actually feel is more like... you know when you're on a swing as a kid and you're at the very top of the arc, and for a half-second you're weightless and you can see the whole playground? Each swing deposits something real. jQuery taught us DOM manipulation could be elegant. React taught us component composition. The current wave is teaching us that you can have server performance and client interactivity without choosing. That's genuine progress.

What doesn't progress is the confidence. The confidence is identical every time. And confidence is what turns a useful tool into an orthodoxy, and orthodoxy is what makes people spend three days configuring Webpack for a contact form.

What has staying an IC for twenty-nine years taught you about these cycles that management wouldn't have?

Gil: That the fundamentals don't move. HTTP, the DOM, CSS, accessibility — I learned those in the late nineties and they're still load-bearing.⁵ Everything else is weather. Some of it's beautiful weather. Some of it's a hailstorm. But the ground doesn't change.

Management would have taught me to call each hailstorm a "paradigm shift" and write a migration plan. Staying an IC taught me to wait it out and see what's still standing.

If a junior developer asked you whether to learn the current server-first stack, what would you say?

Gil: Learn it. Use it. Ship things with it. Just don't get a tattoo.

Last question. Will the pendulum swing again?

Gil: (smiles)

Gil Pagefault is a composite character. Any resemblance to an actual staff engineer in Milwaukee with a framed W3C spec on their wall is either coincidental or evidence that the pattern really is that universal.

Footnotes

1. José Aguinaga, "How it feels to learn JavaScript in 2016," HackerNoon/Medium, October 3, 2016. ↩

2. Sacha Greif, "A Study Plan To Cure JavaScript Fatigue," freeCodeCamp, October 31, 2016 — documents the Aguinaga post's reach across Hacker News and Reddit. ↩

3. Sencha, "Server-Side Rendering Trends in 2026," March 2026. ↩

4. Performance benchmarks from React Server Components adoption alongside Next.js, as documented in Vercel's 2025 production case studies and independent SSR landscape analyses. ↩

5. DEV Community discussion, "Dealing with JavaScript Fatigue," July 14, 2025 — captures the practitioner consensus that "vanilla JS, the DOM, CSS, HTTP, and accessibility outlive tooling waves." ↩