This is a fantastic article from Julia Evans about duking it out with modern front-end tooling. Julia has made a bunch of Vue projects and typically uses no build process at all:
I usually have an
script.jsfile, and then I do a
<script src="script.js">and that’s it.
Which I think is awesome and probably means those projects will last a damn long time. But, I understand a desire to move into some more modern dev tools, if nothing else to unlock the whole npm ecosystem. Basically, Julia wanted to do:
import Vue from 'vue';
That straight up implies npm and a bundler, because that syntax is bundler-specific (it’s invalid ES modules syntax). This used to pretty much imply webpack, rollup, or Parcel, but that’s starting to change and heavily suggest Vite instead.
But Julia didn’t want to reach for tooling that did too much ():
But I stopped using those tools and went back to my old
<script src="script.js">system because I don’t understand what those
viteare doing and I didn’t feel confident that I could fix them when they break. So I’d rather stick to a setup that I actually understand.
So, with Vite being too much, Julia reached for esbuild. I can’t say I understand the details, but Vite uses esbuild internally for some things:
Vite uses esbuild instead of Rollup for dependency pre-bundling. This results in significant performance improvements in terms of cold server start and re-bundling on dependency invalidations.
So reaching for esbuild directly is a bit of a step down the complexity ladder.
It was so close to being a home run, but of course the dang complex nature of the front-end ecosystem struck again. The assumed copy of Vue that esbuild grabbed from the
import Vue from 'vue'; was
vue.runtime.esm.js, which is the version of Vue designed to be run in the browser, not the version that includes a compiler. Ughghk. Feels like they should be two separate packages or something. But Julia ultimately battled through that and it was a win:
I don’t understand everything
esbuildis doing, but it feels a lot more approachable and transparent than the [webpack]-based tools that I’ve used previously.
All this is one more reason I’m still bullish on Skypack. You can use modern
import statements like that and still not need a build process at all.