Yes, yes, yes! Webpack was written by astronaut architects who were obsessed with making things possible but not with actually solving problems. In practice, it meant that even though no one actually has interesting bundling requirements, everyone ends up writing their own bundling logic for some reason. Parcel and ESBuild also got this right.
I experimented with Vite for awhile recently and I definitely came away with a good impression. I love the index.html default entry point for quick demos/examples and prototypes. I haven’t found motivation to use it in a real project yet, but I agree that Vite gets a lot of things right. I’m all for rejecting unnecessary complexity.
I gave up on Webpack a looong time ago. Actually to be honest, I don’t think I ever picked it up. I had to use it at work on a couple of projects we inherited. One of those was a fairly simple headless ecommerce website and the Webpack build took 20 seconds (incremental builds around 500ms). I felt dirty every time I worked on that project. I just can’t believe people willingly signed up for that experience, especially when the likes of esbuild came along, but these kinds of low standards have been pretty common in the wider web development community unfortunately (see bundle sizes, 10,000 dependencies, etc.). I’m hopeful that trend is reversing and we’ll see a push towards greater efficiency in our tools and workflows.
Dear gods yes. I think I first used Vite when trying to get Webpack to upgrade from 4->5. No matter what I tried, our large (but not that large for Webpack) config went from about a minute or so for build to >1 hour (I gave up eventually). Tried many different options, couldn’t get it to a more reasonable number. Then I plugged in Vite. Our config was a bit longer than the one from the article, but cold build time was down to a handful of seconds, which was just excellent, and having actual fast-reloads again was just perfect.
This is just part of the Javascript tool treadmill. First there was Bower, but it didn’t compile the assets together, so we needed Grunt, which was based on Maven, but that was too much configuration and (like Maven) too hard to reason about, so we got Gulp, which was more like Make, and it was extensible and could do anything! But of course it was inefficient and anyway, now there is Webpack which just does the things you want it to do, but it’s pluggable! But oh wait, it takes a lot of lines of code to make it go, so look, a new one Vite, and thankfully it’s opinionated and the configuration is small!
And in two years either it will have grown a bunch of plugins and will require many lines of code, or there will be some reason to prefer a less opinionated tool like Gulp (but newer, and different) that lets you do arbitrary things… and then the cycle will repeat.
Yes, yes, yes! Webpack was written by astronaut architects who were obsessed with making things possible but not with actually solving problems. In practice, it meant that even though no one actually has interesting bundling requirements, everyone ends up writing their own bundling logic for some reason. Parcel and ESBuild also got this right.
I experimented with Vite for awhile recently and I definitely came away with a good impression. I love the index.html default entry point for quick demos/examples and prototypes. I haven’t found motivation to use it in a real project yet, but I agree that Vite gets a lot of things right. I’m all for rejecting unnecessary complexity.
I gave up on Webpack a looong time ago. Actually to be honest, I don’t think I ever picked it up. I had to use it at work on a couple of projects we inherited. One of those was a fairly simple headless ecommerce website and the Webpack build took 20 seconds (incremental builds around 500ms). I felt dirty every time I worked on that project. I just can’t believe people willingly signed up for that experience, especially when the likes of esbuild came along, but these kinds of low standards have been pretty common in the wider web development community unfortunately (see bundle sizes, 10,000 dependencies, etc.). I’m hopeful that trend is reversing and we’ll see a push towards greater efficiency in our tools and workflows.
Dear gods yes. I think I first used Vite when trying to get Webpack to upgrade from 4->5. No matter what I tried, our large (but not that large for Webpack) config went from about a minute or so for build to >1 hour (I gave up eventually). Tried many different options, couldn’t get it to a more reasonable number. Then I plugged in Vite. Our config was a bit longer than the one from the article, but cold build time was down to a handful of seconds, which was just excellent, and having actual fast-reloads again was just perfect.
When will someone make this for C/C++? XD
(Is it actually already Nix? Whatever happened to Guix?)
This is just part of the Javascript tool treadmill. First there was Bower, but it didn’t compile the assets together, so we needed Grunt, which was based on Maven, but that was too much configuration and (like Maven) too hard to reason about, so we got Gulp, which was more like Make, and it was extensible and could do anything! But of course it was inefficient and anyway, now there is Webpack which just does the things you want it to do, but it’s pluggable! But oh wait, it takes a lot of lines of code to make it go, so look, a new one Vite, and thankfully it’s opinionated and the configuration is small!
And in two years either it will have grown a bunch of plugins and will require many lines of code, or there will be some reason to prefer a less opinionated tool like Gulp (but newer, and different) that lets you do arbitrary things… and then the cycle will repeat.