Building a Vanilla Web Application

By Ryan Heisler, published February 13, 2025

I'm working on a learning exercise to build a web application using the most vanilla tech stack I can. The blog you're reading now is part of this project. I also plan to add a multiplayer implementation of Yacht Dice . My goals are:

1. to learn more about how web applications work without frameworks like React
2. to test my own ideas about using frameworks to build web apps. Over the last 8 years, I've consulted on over 40 different enterprise codebases with clients in all domains and tech stacks. I've come to believe that all the layers of abstraction we use to "go faster" are actually as slow or slower than building with vanilla JS, HTML, and CSS, and I want to put that to the test.
3. to test my own ideas about maintaining web apps: I think if I use fewer technologies that change rapidly, the application will be easier to maintain over time. I built an app in Angular once, and maintaining it now is virtually impossible. It would take inordinate amounts of time to update all the dependency versions and relearn Angular and the codebase well enough to make changes.
4. to experiment with limiting code obfuscation and minification. I believe users should be able to easily dig into the code for their own security. Since this project will encompass a blog and a game and I don't believe this this web application will require very large payloads.and I want to know what's possible with vanilla so I can be better informed when working with something like React.
5. to have fun building something from scratch! I often have to work with large, old, crufty codebases, and in an enterprise environment it almost never makes sense to throw something away and start over. I can get that idea out of my system on my own project.

As I make progress, I'll post here about issues I run into if I think the lessons learned are relevant. The tech stack I'm using is:

• A NodeJS server using Express. Express is the one dependency for production functionality that I have so far, and I'll be very reluctant to add others. Dependencies break, deprecate, or conflict with each other over time, or require significant updates to ensure continued functionality. I believe NodeJS and Express are stable enough not to change significantly or become unavailable in the next decade.
• The code for the server and frontend scripts is written in TypeScript. Having some type safety is important to my development process, and I don't expect TypeScript to change as quickly as something like React.
• I use Parcel to "build" the application, which includes transpiling to javascript, optimizing the CSS a little, and copying the files to a distribution directory to be run in production. I considered writing a script to do this myself, but it would have taken a long time and involved a lot of tedious string parsing. Using Parcel now doesn't prevent me from using another system in the future, but it does save me time now.
• I test-drive all my code with tests focused on the user experience and accessibility. My tests use Vitest as the test runner, DOM Testing Library for rendering and assertions, and Mock Service Worker to avoid mocking my own code.