With more tools, libraries, and frameworks than ever, it’s understandable that people might reach for the latest trend when building a new project. After all, new projects are a great opportunity to learn new technology. But in my career, doing this has often backfired and ended up wasting my time.
This is not to say there’s no role for using a library or framework; but it’s remarkable what you can accomplish with plain HTML, CSS, and JS these days—especially with Web Components available.
The benefit of building with simple technologies is that they are generally low in complexity, highly maintainable, and easy to manipulate. This lets you focus on what you are building, rather than how you are building it.
Of course, at a certain scale or level of complexity, you’ll eventually run into limits or frustrations and might wish you had leveraged something more modern. That’s fine—but wait until you reach that point, if you reach it at all. This is especially true when prototyping.
The truth is, many frontend frameworks and libraries are cumbersome and poorly designed or implemented. This is largely a function of the frontend ecosystem, where new “hot” tools appear almost weekly—but it’s also influenced by factors like resumes, branding, and the widespread adoption of flashy frameworks and libraries.
Don’t get me wrong: some libraries are focused and a delight to use. They do what they promise—and they do it well. They take hard or frustrating problems and make them easier to manage, removing a lot of manual labor. They have well-defined boundaries, are stable, well-documented, and battle-tested across the web. For certain problems, you’d be a fool not to use them. (This blog, for example, uses Jekyll, which compiles into a static HTML site.)
But there’s something to be said for having few-or no—dependencies to track or manage when building something. A splash of tasteful HTML and CSS, augmented with a sprinkle of JavaScript, can do a lot on its own.
Much of my career has been spent removing complexity and overengineering: converting specific technical decisions to generic ones, removing build steps, and optimizing the development experience for juniors.
If you can achieve your goals with the basics, there are many wins to be had. Knowing when to lean into simplicity and when to reach for something more powerful takes a pragmatic balance that can’t simply be conveyed—but embracing and celebrating simplicity wherever possible is an evergreen value worth upholding.
