React Summit

React Summit 2023

<p><span>Web development has changed significantly over the past 15 years, and we'll take a satirical look at how daunting it is for newcomers to get started nowadays. In doing so, we'll discuss what is necessary to build a full web application, and I will be going over most of the technology I personally like to use for that.</span></p>

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 cracked 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 guestbook 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 and it did allow me to brag in front of my friends. Interesting 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. Deploying this locally was easy using XAMPP, which was a convenient way to run Apache and MySQL locally. Deploying this guestbook 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 frontend that needs to be deployed somewhere, preferably Vercel or Cloudflare to circumvent dealing with AWS or GCP directly. The frontend 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 ergonomics have led to ORMs and query builders such as Prisma, Drizzle or Keasley, 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. Here is my Twitter handle and enjoy the rest of the conference.
