Why are there so many JavaScript build tools? Gulp, Grunt, Webpack, Laravel Mix, Rollup.js, and now Vite. And these are just the ones that I've worked with. Haven't we solved this problem? And why build a new tool? Why not improve existing tools?
I think about predecessors like GNU Make. Sure, it's old, but it's tried and true. The invocation is consistent and has been for years: make [command].
How different would the world be if the Node.js ecosystem adopted Make as the preferred mechanism for running scripts, instead of npm run [command]? I guess we'd be seeing a lot more Makefile's around.
Top comments (13)
What is Make going to solve? Make is just an tool to create CLI commands. You still need the tools to do the actual work.
How is Make going to replace Npm?
Mix is an opinionated Webpack config, and Rollup is a part of Vite. So it are just tools that build on each other; it is up to you to select the build tool that fits your project or team.
I'm confused about the point of this rant?
True. The point of the rant is that there's too many tools. We devs reinvent the wheel A LOT. Do you agree?
I only speak of Make because it was the first that came to mind.
I think the amount of javascript libraries is due to fact that it is the only language that is build in browsers. So there are a lot of developers who have ideas about doing things.
The developers want to fix something in library A, but the maintainers don't allow it, so library B is created and so on.
I don't think reinvention is a bad thing, that is how we learn what works and what doesn't.
I always been wary about the move to generate the html with javascript, and I still don't find it a good default. And now with frameworks like NestJS and Astro the javascript community is back where the backend language frameworks were all that time. But with the component based building of html. And that is something the backend language frameworks are more aware of now.
I'm not saying I'm smarter, I just am stuck in my ways because progressive enhancement was the hype when I started with websites. And over the years I learned that highly interactive applications benefit from generating html in the browser.
We all learn from using new concepts and experience how they break down or excel in different situations.
You are right, so much build system ... so much pain. For example vite is much faster compared to webpackage. But webpackage is able to use proposal-pipeline-operator which is missing from JS.
A first that we need to learn again is a clean HTML/CSS/JS code which is run without any build.
I do it, and that is lead much more clearer picture. If you give a time for explore that way, you will be more faimiliar what is does the building system.
After pure works my code will grow to a certain pont when build will be handy. I try to keep the good part of react: JSX which is wroten in a single JS function instead using any framework. Then my prefered build system setup for use that function, and thats all, everything working as expected and don't need to use FW. But in this situation vite is very helpful.
Can you check my solution (fare from battle tested): dev.to/pengeszikra/javascript-grea...
Other place where build system is important the write of npm module, my really minimal type safe react state handler writen in JSDoc / vite is a good example for that:
npmjs.com/package/jsdoc-duck
But much better to simple copy that index.js into your code to use instead use as package.json dependency because that is solva any later problem of versions ( I don't think to improve it - because after creating that module I decide to move to pure JS direction. ) So long live Burrowing instead use as module.
Just like JavaScript build tools, game art services in India keep innovating and bringing new updated to meet new requirements . While some prefer reliable old tools, others innovate for better workflows. Whether it’s Gulp vs. Vite or classic vs. modern game art, the goal is the same—efficiency and quality.
This is a sign of innovation and the Hype curve. Most stacks early on spark interest and this motivates builders to keep building stuff. In PHP for example, there was a time before Laravel, you had frameworks popping up every few months. No clear winner.
Then commercial interests kick in, a winner is picked and the tools that didn't win run out of funding or the creators loose interest and they die off.
JavaScript is taking longer than usual time to mature because it's such an easy language to master, just about anyone can build a library, but seems like TypeScript, React + Next.js, Vite and Angular are winning this race and will slowly kill off all these other tools.
Similar thing is happening in the AI space.
I would give it two years; the shiny new syndrome will wear off.
same, i keep ending up back at square one every year with new tools popping up or breaking - you think it’s just hype cycles or something deeper pushing folks to keep making new stuff?
I think it's a bit of hype and a bit of ego. Everyone wants to be the next big open source tool. It's glamorous. Just my opinion, though.
In C language, you have more 10 compilateur, it's the same everywhere.
and npm is created by node director, so... go to yarn :)
This has all happened before and it will happen again 😂
Great!
Fe-dev truly needs unification.
agreed. Instead of many tools, we only end up with many Makefiles.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.