Weekly Tech Report #2 - Bundler-free Frontend Development
Analyzing current news that can make a difference from a Full Context perspective
The (re)emergence of developing JavaScript projects without build tools and the forgotten value of bundlers
Couple of different authors wrote recently about their workflows and tools to deliver modern frontend projects using the latest browser standards to avoid the added complexity of build tools.
Julia Evans - Writing Javascript without a build system
Kofi Gumbs - Modern SPAs without bundlers, CDNs, or NodeJS
Brandon Foley of Vue.mjs, - Simple, Modern JavaScript
I highly recommend checking them if you are interested in the technical details. What I will focus on here is how and when this approach can bring value, when to avoid it and what it teaches about the often overlooked benefits of bundlers.
Now before you get overly excited let me answer the question you might have: Awesome, can I go bundlerless right away? No, most likely not!
Julia makes a solid case for what’s the right situation for this approach:
easily make changes to old tiny websites
The old part is not strictly necessary in the equation. She and the other articles name the same main motivation for adopting this approach: bundlers are too much hassle to set up and sometimes it’s hard to get old projects to build correctly.
I completely agree with the problem and the example situation. In general I think this can be a beneficial choice for
small scale projects that don’t require heavy JavaScript based functionality,
that will be maintained by one or two person
won’t require a lot of updates
and won’t utilize other non-browser-standard tools (pre and post processors, build optimizers)
doesn’t meant to build reusable components
you already know or don’t want to learn modern tools
It makes sense. The lack of extra tooling is justified because it wouldn’t be used really anyways. However what if the project starts to grow? When you want to automate more complex tasks like pre and post processing or build optimizations you would walk down the road of the FE tooling evolution of the last 14 years on your own. Adding a task runner? Build tools? Filesystem watcher? It won’t be easy, pleasant, or even justified. Your choices for building design system and reusable components are also much more limited.
So if your project is to grow even a bit larger than the above, this approach will only make your life unnecessarily harder.
Is it possible to go bundlerless now? Yes, surely it is, it’s even more performant and convenient that before thanks to new browser features.
But it doesn’t scale.
What about bundlers?
The overlooked benefit of bundlers - even with all the pain to set them up - is exactly that, scalability!
Bundlers unify the way teams handle the tooling and tasks around building, optimizing and delivering FE projects.
They enable organizations to predictably replicate the configuration of the tooling across time and projects. All of these are huge-huge benefits which we take for granted nowadays, maybe even forgot to appreciate.
Now’s the time to use the Full Context System to get a relative sense of the impact this approach makes. If you are not familiar with it, you can read a short summary in one of my older blog posts here.
In summary:
Who should go bundlerless? Small one person projects, tiny landing/static pages unlikely to change, maybe even minor projects of web-dev studios.
The impact in the optimal case is still small as the scale of the work is small and I neglect the fact that by using JavaScript instead of TypeScript you already miss out on a couple of DX improvements:
Business Opportunity - Increased time to value
Productivity - Time saved at the project start
Who should avoid the bundlerless approach? Anybody else really.
The impact of adopting it in an unfitting, large environment can be devastating:
Business Opportunity - Wasted time means a smaller chance for building successful products and business relationships
Productivity - Reinventing the wheel, a huge and complex wheel can ruin the productivity of the developers
Utilization - Time spent elsewhere instead of delivering value, and sitting on available but not adopted solutions means bad utilization of both mental and financial resources.
Customer Experience - You will miss out on the cutting edge performance optimizations that even Vite recommends to use by not bundling your code. Meaning your users will also get a subpar experience.
Costs - Low productivity, utilization and missed business opportunities will affect the financial results way more significantly and negatively, than the little you save on the surface level, build-vs-buy cost reduction.
What about TypeScript?
I don’t think it’s possible to pull off the same stunt with TypeScript sadly. You need a compile step to turn TS into actually usable JS either way. Or… wait a minute! Deno! I would love to do a full context analysis of Deno in a follow up post as it offers an interesting set of pros and cons with possibly huge business implications. Let me know if you are interested!
I’m super happy that you read (or scrolled) till the end! If you enjoyed the article and/or found it valuable please consider sharing it with your friends and colleagues.
I’m at a very early stage of building this Substack publication so even the smallest extra visibility can make a huge difference. My wholehearted thanks if you help with that!
See you in the next one!
Joe @fullctxdev