Hey there!

In my last series of articles, I built an entire single page application in a single HTML file. But, that file ended up being pretty unwieldy by the end— over 500 lines of code! We all know that those concerns are just begging to be separated. But, I wanted to do more than simply splitting the code into multiple files.

So, I decided to devote each chapter in this series to a different, emerging web API or tool that I think will play a major role in the future of web development. For context, we will spend the next chapter splitting our files up the old fashioned way— with script tags. This will be in it’s own chapter so we can see some of the problems that arise when we do this, and so we can talk about some of the decisions to be made in terms of file structure and naming conventions.

Then, we’ll be using ES6 modules to split our code into individual files. Just by adopting this new standard, we will be given a whole host of new features that will make our code more maintainable and composable. On our way, we’ll discuss the twisting history of module systems in JavaScript on their road to the browser with ES6.

In the chapter after that, we will further our discussion on client-side routing by adopting the new Navigation API. It’s only really available in Chrome for now, but it’s so much better than the history API that I felt the need to include it. It completely simplifies the complexities explored in the last series, and it lowers the overhead necessary for a single page application experience.

In the same spirit, chapter five will be about the new View Transitions API— also only available in Chrome for now. This API will allow us to easily animate between each page. It plays nicely with the Navigation API, and it is really impressive what the two can do with just a few lines of code! Any MPA can become a slick SPA with just one meta tag and a few CSS rules.

Chapter six will be all about types, which may be making their way to JavaScript. At this point, our application will split in two. Modern web development has grown to a point where it seems impossible to create a website without a build step. I want to test the limits of this necessity.

So, with one version of our app, we’ll start by exploring JSDOC type annotations powered by the TypeScript compiler. However, we will build another version of our app where we fully convert our codebase to TypeScript as well. With this version of the app, we will be introduced to the concept of build tools and compilation.

So, we’ll discuss bundling in chapter seven. We’ll compare and contrast Parcel, Webpack, esbuild, Rollup, and more! In our uncompiled app, we’ll explore the new import maps standard which may make bundling less necessary in the future.

Chapter eight is about Deno and Astro. To fully take advantage of the new import maps standard, our unbundled app needs a runtime that fully understands the concept of remote packages. This will also increase the effectiveness of our JSDoc types.

The compiled app, on the other hand, will be converted to an MPA running in Astro to fully compare and contrast this to the unbundled SPA that we have built so far. I consider Astro to be a keen example of a framework taking full example of a build step to provide a better experience for both developers and users. So, this should help highlight the benefits that modern tooling can provide.

The theme of this series will be incremental change. I don’t plan on doing a lot to the app with each chapter, but I think that you will be surprised by how much we can accomplish with just a few lines of code each time. Enough talk, let’s get started!