Varun Kumar

October 3, 2023

The Plumbing of the Web

I wasn't around for the early days of the internet. I didn't see the wrangling between programmers over conventions and didn't see the development of key technologies that make any of this possible. Instead, the web for me has been a source of shiny new tech that is supposedly "revolutionary" (if a revolution happens every few months, are they all really revolutions?)

APIs with GraphQL instead of REST. Web 2 to Web 3. Client-side rendering, noSQL databases, microservices, etc — all this new tech promised to rewrite how the web works and replace the older, clunkier way of doing things.

When I started programming, I was eager to learn them all. I didn't want to fall behind or be stuck using some unemployable framework that the community had moved past. However, no matter how much I tried, it seemed like there was a new fold of complexity I had to learn every week. A new JS framework that was better and newer than React. New ways to do convoluted things that I didn't understand, like server-side React or Gatsby.js (still don't know what the point of it is). On top of this was a whole world of frontend tooling, including JS bundling and transpiling, CSS compiling, and the rest. I felt woefully inadequate in my programming knowledge and unable to catchup no matter how hard I tried.

Even when I learned the basics in school about how servers and clients worked, how the web itself was a technology developed around HTML, CSS, and Javascript, the underlying message was that building modern web apps with these native tools was like trying to build an iPhone with a wooden stick. No wonder companies and people touted the use of a "modern MERN stack" — modern web apps in my head were hard things to build that required more complexity than any one person could understand.

It was only once I started learning Rails that I realized that most web apps do very similar things, no matter how fancy they look. They read and write from a database (SQL usually works just fine). They might queue some jobs up to run somewhere. Parts of the screen change via HTML and CSS, responding to user input or some other process. Where the server used to respond with HTML, it now responds with JSON and the logic of the screen has been left to the mangled mess of frontend tooling and client-side rendering.

With Rails 7, I also realized the web itself is a product that is constantly improving. Things like ES6, import maps, and CSS nesting all allow for new ways to think about the frontend. A return to uncompiled, raw HTML, JS, and CSS from the server that result in the kind of high-fidelity web apps we expect today. There's a real turn to how things used to work with vanilla JS and server-side rendering. I didn't even realize that the effort to render React from the server was a return to how things were done before, not some fancy new advance in web tech! A return to the way I imagined things worked in the early days of the web, with one person writing and running a whole web app.

All this has made me realize that the web works in a certain way that isn't likely to be overwritten anytime soon. SQL databases, server-returned HTML, raw JS, and CSS, and RESTful APIs work just fine. Things can be built on top of this but how the plumbing works won't change. The reason I like Rails is that I don't have to build a faucet and evaluate the dynamics of plumbing systems every time I want to make some hot tea.

As a part of the generation of programmers brought up on React and microservices worship, this is a breath of fresh air. The web works just fine and it's becoming possible again to work in its native tools. I don't feel the constant pressure to update to the latest, greatest serverless framework, build pipeline, or noSQL database to feel like a modern programmer.

About Varun Kumar

See more about me at varunkumar.com