This is how most of the FrontendMasters.com website is made. Go/Hugo templates and vanilla JavaScript. People are always shocked at how fast our website is. Write the code necessary for the job at hand.
With some patterns they can follow, vanilla js does indeed scale so well that it becomes boring. There’s no longer any code to rewrite for the latest and greatest frameworks. No dependencies to manage. It just becomes almost too easy at some point, at least in my experience with many projects I’ve led.
I’ve made millions and millions for major brands, including my own company, and customers go “wow how is your site so fast!!” All. The. Time.
The biggest pressure I’ve found is from the engineers themselves. Not all engineers like to go counter culture and learn browser APIs and JavaScript. They would simply like to use what everyone else is using. They tend to argue against vanilla using canned arguments read off of framework websites that don’t apply much or aren’t even problems in the actual codebase.
Agreed, esbuild is nice. And adding TypeScript at some type of scale probably makes sense. Not sure where that line is, but in this simple example I’m trying to avoid all external tools.
There's sort of a "Maslow's Hierarchy of User Needs" that exists in software though. So long as the user can do something, and their immediate needs are met, performance concerns are just a small annoyance. And generally they will continue to ask for more features rather than performance improvements as long as the app remains usable.
I did this style to mimick modern framework code — taking the state (todos) and render the state of the world every time. If the browser had a DOM diffing api this would be more efficient and we would be there. So for a larger project I might using something like Lit’s html stand-alone package or fastdom to get the DOM digging functionality without much dependency code.
