Netlify? Vercel? AWS? What are those?

Platforms as a Service or even Software as a Service were not a thing when I started working in the industry 20 years ago.

That’s how different it was to develop software. In fact, the idea that “there is an API for everything” was not real back then. Having a service up and running required a lot of work and money, so nobody did it unless they had a very good reason for it.

On top of that, the tools we had were different, Node.js wasn’t a thing, so frameworks like Next.js weren’t available. I started working with PHP 4, which did not come with the ability to create your own web server like Node.js (and others) do now. Instead, we had to install Apache Web Server, or if you were a risk-taker, Internet Information Service, which was (is?) Microsoft’s option if you wanted to have a Windows-based web server (which back in the day wasn’t ideal).

The interesting bit about this way of working was that your application was a set of scripts that would get executed every time a request was received by the server. This meant that you had no “running app” on the server. Every new request turned into a new process running inside your server. Which meant servers had to be powerful to handle lots of requests, because every request was a parallel process taking up a piece of its memory and CPU time.

And of course, database connections (and to other services) had to be established and closed during the lifetime of the script (i.e the duration of the request).

If you wanted to scale, “auto-scaling” wasn’t an option. I remember the pain of having to estimate the amount of server power your e-commerce site would need for a particular holiday. And of course, always falling short and having to do some emergency fixes during the weekend (like rebooting dead databases, or cleaning up log files that grew too big and filled up the disk).

And the front-end stack was a lot simpler

The front-end scene was very different back then as well for a couple of reasons:

1. The most important one, I think, is the fact that HTML, CSS and JavaScript were less standard back then. Especially the latter, every browser implemented their own version of it, following their own guidelines and not really caring about the others. It was a race, not a collaboration. So you had functions that were available in Chrome, but neither Firefox nor IE had, and vice-versa. This meant that building something that could be used by anybody had to have a lot of code just to deal with those gaps.
2. There were no UI frameworks back then, there were just libraries. To me, that distinction is important, because nowadays, frameworks like React and Vue provide you with an architecture that defines a set of tools and patterns for you to follow. And if you build on them, as Next, Nuxt and others do, then they provide you with a path for you to follow. Back in the day, we had jQuery, underscore (which later was almost replaced by lodash) and Mootools. They were all fantastic libraries, but they wouldn’t really impose a way of working, which lead to thinking that front-end development didn’t require the use of any advanced development methodology or techniques. Heck I remember thinking that JavaScript was meant for adding form validation and some silly animations to an otherwise, static site.

You have to remember, “back then”, we couldn’t even load data asynchronously. It wasn’t until the term AJAX got popular that we found out about this ability (and learned the concept of asynchronous behavior). That was a shift in our working paradigms, something that today is very common.

Now it’s a lot easier

Now deploying an application is a lot easier. Which is great, don’t get me wrong!

You can now hook up your Github account with a Netlify (or similar) account and auto-deploy your application somewhere in the world. Heck, you can take advantage of services like Supabase, or AWS DynamoDB where you don’t even have to worry about maintaining your database or your authentication service.

There are even services that will centralize your logs, like Loggly and Splunk, so you don’t have to worry about filling up the disk space if your log-rotation configuration wasn’t optimal.

Being a one-man band back then was a lot harder, now you can really get close to working truly alone (if you’re willing to pay for it).

And the front-end became harder, which is good

The front-end ecosystem is quite large right now, React, Vue, Svelte and even Angular power, or have inspired, the creation of many frameworks that are pushing the front-end to the next level.

Let me put it this way, back when I was getting started, the “motto” of web development used to be “slim clients, fat servers” or “keep your clients dumb” or variations of those ideas. Essentially, your client code is simply presentational, you were not supposed to be doing anything “hard” in there because the browser wasn’t ready for it. Instead, we kept our “complex” logic in the back end and used JavaScript to show pretty colors and some alert boxes.

We’ve come a long way since then. Of course, that hasn’t happened without a price. Back then our “bundler” was a set of script tags we would add at the top of our HTML and that was it.

Now the amount of JS to power a modern app has grown so much that the ecosystem of tools developed to optimize it has grown accordingly.

Now you need:

1. A transpiler if you’re not using pure JavaScript.
2. A bundler to put all your code together, remove the unnecessary bits, optimize it for transfer and deliver it in a way that is less “expensive” to the user.
3. A linter to make sure every one of the 100k lines of JS is following the same standards across your team.
4. A webserver with hot-reload and file monitoring to make sure your development experience is optimized, otherwise changing a single line of code can take quite a long time to refresh.
5. A package manager, because as developers we’re done re-inventing the wheel.
6. A version control system (usually Git + Github but there are alternatives to both) to make sure teams can easily collaborate on the same project.
7. A test runner, because yes, now your front-end business logic is so complex (which is great BTW) that you need a way to make sure everything works as expected.

And I bet you can probably think about a few more. It can be a little bit overwhelming for someone just getting started.

I know it was for me when getting back on the horse after years of not coding.

Thankfully, the industry is still evolving. While they’re still new and trying to break in, tools are being developed specifically designed to simplify the stack once again, while keeping the power and capabilities of today’s complex solutions.

The future of the web development tooling ecosystem

This journey isn’t over, and that’s good.

If you think about it, we do this with our code as well:

1. We write a simple solution to our problem.
2. We realize it’s not covering all potential edge cases, so we keep adding more code on top of it until it works as it should.
3. We realize it’s a damn Frankenstein of code, unmaintainable and hard to understand so we start refactoring and simplifying.

Our toolchain is going through the same process. We’re starting to see step #3 by now. We’re seeing tools like Bit, from bit.dev trying to centralize all the tasks around the development cycle.

In fact, with Bit, you can version your code, lint it, and publish it as individual packages. Heck, you can even manage a full monorepo with it without having to worry about any other tool.

Granted, it’s not like the tool does everything for you, in fact, it “just” manages the whole ecosystem of tools you’d usually have to worry about yourself. And that is a smart way to go about it if you ask me.

Additionally, tools like bundlers are starting to see a trend where they’re not exactly needed anymore. Hear me out, I interviewed Michele Riva (he’s a Sr. Software Architect from Nearform) for the 20MinJS podcast, which I host, and on his episode, Michele mentions how new bundlers like Vite are taking advantage of browsers’ new ability to use the ECMA Script import statement, and load files asynchronously, thus improving the loading speed of JavaScript (instead of having to load one or few very big bundled files).

So if you ask me, the future is looking bright. There is still a lot to work on, but the days of worrying about having to manually set up the platform for our application are long gone. The tooling ecosystem is evolving to a point where we can quickly prototype and deploy ideas and then grow them into full-blown applications without having to change much other than the services we use or the tiers we’re paying for. And if we want to scale them up, because they turned out to be a success, that is also accessible within our reach as long as we’re ready to pay for it.