#web 10 minute read

A farewell to Web Development

The web used to feel simple, playful, and human. Somewhere along the way it turned into pipelines, configs, and abstractions. This is a quiet reflection on how that shift changed everything.

I started developing for the web, in a professional manner—that is, making money—around 2010. By then, I was about to finish my degree and found an excellent way of keeping myself evolving through a web development position that had just opened in the same school I was studying. Today, around 15 years later, I think it’s time to reflect on what I have been doing and why I may not want to keep doing it.

Back when I started

Developing for the web in 2010 was very different from what it is nowadays. Modern HTML5 was only widely adopted around 2014. CSS flexbox and grid, which we heavily rely on for just about any layout these days, became widely usable around 2012 and 2017, respectively.

Even npm was just taking its first steps around 2010. So, as you can imagine, it was far from being the default it is today.

When I started, I didn’t even use git. Not because it didn’t exist—because it did—but rather because I wasn’t even aware of it for a long time. The need for versioning was already there. Our team used Dropbox-synced folders to make sure we all had the same version of the files. Sometimes we still had to double-check and ask out loud in the office if someone was already editing a certain file, just to avoid resolving conflicts in a non-git manner. It wasn’t fun, let me tell you.

Since modern layout tools like flexbox and grid weren’t a thing—or weren’t supported in most browsers—we used floats most of the time.

Actually, when I really started playing with HTML documents around 2003, I used tables instead of floats. I didn’t even know what CSS was—there were a bunch of HTML attributes that allowed for element styling.

Then came JavaScript

Even before my web development journey, there was already a scripting language that kept me interested in this thing that is writing instructions for a machine to do what you want, and that was mIRC Scripting.

At the time, I used mIRC clients to talk with my friends—there was no Facebook Messenger, WhatsApp, Telegram, Signal, or whatever you use nowadays. A mIRC client could easily be seen as a terminal app from a graphical point of view, although it wasn’t.

At some point, I realized I could use its scripting language to modify the look of the client (themes) and also develop bots. That was very interesting and rewarding to watch, especially when you gave them useful capabilities that brought value to other users.

That’s where my scripting life actually started. So when JavaScript came along, I naturally tried to port all the concepts I knew from mIRC Scripting to it. They’re both scripting languages, so there was a good amount of overlap. And truthfully, I was a very junior developer.

This is fun!

Over the years, I learned one thing after the other and started to realize the potential in the knowledge I had acquired. I was now able to develop—and later, design—entire websites from scratch. JavaScript allowed for user interactions that would be impossible otherwise, especially when dealing with forms, validation, and dynamic fields.

Developing a website at the time was mostly about putting together HTML and CSS files in a text editor like TextMate, adding some images, and pushing everything through FTP to a server.

Fonts were not a thing back then—we were stuck with system fonts. Icons were achieved with sprites: one big image containing multiple icons that would be cropped using coordinates. Tricky, but clever.

After pointing your domain to your server—and waiting for DNS propagation—your website was live. It was that easy.

The fun turned complex fast

As much fun as this was, new concepts eventually came along that turned web development into a whole new creature.

Endless pipelines, npm scripts, pre- and post-processors, preview environments, CDNs, CORS, APIs, packages, CLI commands, bundlers, transpilers, linters, formatters, testing frameworks, environment configs… a maze that never ends.

Don’t get me wrong, I can see the value in all of these. But even though this isn’t an extensive list, I still believe not every website needs the benefits that all of them bring.

I believe the fun started to fade when we—developers—assumed that making things overly complex would be fun. Project owners later started pushing specific setups that forced even more complexity. But the truth is that we are the tinkerers. We love to fiddle with computers.

Nowadays, you can’t just point another developer to a project and assume they’ll know how to update a simple sentence on a website. There are no standards. Every project is built differently. It makes sense—but it also makes our lives harder.

Still, I adapted. And even though we all know how PMs and POs feel about spending time on testing, I can say my skills have evolved dramatically because of all this.

Skills are a good thing to invest in!

For example, my confidence with the command line was close to none when I started. Today, I feel comfortable enough that switching to Linux wasn’t the dreadful experience it would have been years ago. I value that a lot.

This makes no sense

During my first job, we discovered AngularJS. Until then, we were building websites and web apps using Ruby on Rails, and we were happy with it. But we wanted a challenge, so we decided the next project would be done with AngularJS.

The project happened to be an in-house online bookstore. A storefront to sell books authored by people close to my employer. We didn’t actually need AngularJS. Ruby on Rails alone would have been perfect.

But we went ahead anyway.

And it was still fun. We weren’t doing it because we had to. We did it because we wanted to explore a modern approach to JavaScript and rethink how we built things.

We even implemented WebSockets so the cart would update across multiple tabs. That was fun.

But now we had two repos: a frontend and an API.

Did we need the API for anything else? No.
Could this have been a single Rails repo? Yes.
Was it overkill? Absolutely.

Fun, but overkill.

JavaScript everywhere

Today, most frontend jobs require deep knowledge of at least one JavaScript framework.

I did a quick exercise on Himalayas, searching for fully remote frontend roles. These were the first five relevant results:

The pattern is obvious.

Websites and web apps are two different things.

They both run in a browser, but they serve different purposes. Developers who enjoy logic often don’t care much about HTML semantics or CSS. Developers who care about structure and layout may not enjoy the steep learning curve of JavaScript frameworks.

And even if you sit somewhere in between, websites don’t need—and probably shouldn’t have—the same runtime JavaScript requirements as apps.

Company websites, blogs, job boards, portfolios, documentation, landing pages—none of these need to be apps. A static website is cheaper to maintain, easier to scale, safer, and simpler to update.

I guess I’m the one who is wrong

It sometimes feels like I’m the wrong one here.

Some companies—like 37signals—still believe in web standards and simplicity. But most of the industry doesn’t. Serving a static HTML file feels almost old-fashioned now.

Computers keep getting faster, and that reduces the pressure to keep things lean. Performance becomes someone else’s problem.

This makes job hunting frustrating. It feels like nobody wants someone who “just builds websites” anymore. Everyone wants apps.

This is only the second time in my career I’m actively looking for a job without already having one.

I still love designing and developing for the web. I probably always will. But it’s no longer what keeps me interested.

Besides, it does feel like nowadays stacks matter more than skills.
It’s like you either use Phillips screws, like the rest of us, or if you prefer torx, you’re out of luck. Look elsewhere.

Because of that, I’m actively exploring roles where I can use my technical background to help teams or users more directly—project management, technical support, or similar paths. I believe I’d be happier there than building websites with frameworks designed for web apps.

Let’s see how that pans out.

Takeaways

Web development didn’t suddenly become bad—it became different. More powerful, more complex, and often further away from the joy that made many of us start.

The early web rewarded a solid understanding of fundamentals instead of mastery over tools. Over time, complexity crept in, often without a clear need, until it became the default. Websites and web apps slowly blurred together, even though they solve very different problems. Through all of this, one thing stayed true: strong skills outlast any stack. And sometimes, the healthiest move isn’t forward, but sideways.

Photo of Pedro
Pedro Pinto
Developer by trade • Designer at heart