How (The Heck) Did We End Up Here?!

Web development has changed dramatically in the past 25 years and even though I now work as a software engineer at JetBrains, I like to remind myself that it was about 15 years ago when I started with JavaScript and PHP. Fasten your seatbelts and join me on a ride down the memory lane back to where I started with web development.

Nowadays there is a plethora of IDEs available but back then there was no PHP store and I remember having the choice between either Dreamweaver and Eclipse. As a teenager without money the choice was fairly easy and I definitely didn't get a correct version of Dreamweaver so I picked Eclipse. However this screenshot here isn't really representative of the past because there was no dark theme unfortunately.

Let's start by writing a simplified version of a guest book smooshed into a single file. First we need a classic HTML form that users can fill out with their comments. Next we need to fetch existing comments from a database using MySQL queries and then we need to iterate over them to display them. So far so good. Finally we need to handle the user actually submitting the form and writing the new comment into the database. Of course nothing in this code was type safe or safe against any injections to begin with but it did the trick but it did the trick and it did allow me to brag in front of my friends. Interestingly enough without my glasses I couldn't really tell the difference between this code and a remix application since both use the same structure separating action handler, loader and actual content. Running this locally was easy using XAMP which was a convenient way to run Apache and MySQL locally. Deploying this guest book was as easy as uploading a file via FTP. Everything was fairly easy, unlike today's workflows unfortunately.

So let's check out modern web development in comparison. First we have to select our UI library or framework of choice be it vanilla react or a flavored framework such as next, remix or something different such as solid. Of course there are other options available if you happen to be working with clients who haven't really caught up just yet. For our architecture we have a front-end that needs to be deployed somewhere, preferably Vercel or CloudFlare to circumvent dealing with AWS or GCP directly. The front-end will require persistent data stored in a database for which we have multiple serverless providers depending on your choice of flavor, with Planetscale being my absolute favorite. Type safety and a desire for decent developer economics have led to ORMs and query builders such as Prisma, Drizzle or Kiesli which will be our tools to communicate with the database. In the era of serverless we also have to be conscious about using classic database connections or using serverless drivers which are supported in edge environments. Yet another thing to keep in mind. Despite all the talk about serverless there are certain workloads such as long-running tasks that don't really work in these environments which require a classic stateful backend which we can host on fly.io or railway. It goes without saying that these will also exchange data with the database using our orm or our query builder. We're still not done though. There are many more capabilities that applications have nowadays such as authentication, logging, real-time updates and more. For everything imaginable there is some useful platform or service but compared to uploading just a single php file or at least a few of them to a single server i really wonder how the heck did we end up here. The answer is quite simple money. I see way too often that companies try to save hundreds of dollars by coming up with custom solutions and neglecting that the time it takes developers to troubleshoot devops issues far outweighs the savings. Let's just focus on delivering products and not deal with too many devops issues along the way shall we. That's all I've got for today.