Hacker News Reader

Comment by swhitf | Hacker News Reader

You know you are getting old when you watch the arrival of the fourth JavaScript build tool of your career. I still remember when everyone was waving goodbye to Gulp in favour of Webpack. Webpack was going to save us all from the hell of massive convoluted gulp.js files. Fast forward five years and it's the same mess it was supposed to avoid. Slow, bloated and confusing.

I just switched to esbuild on our main project and the build time went from 7 minutes on CI to 1 second. Kinda stupid really. Anyway, here's to the future, let's hope it works out this time!

View on HN

I always found it amusing going from Grunt (unwieldly huge object based config) to Gulp (config is code, pipe transformations together in a simple unix'y way) to being told webpack is the future (huge unwieldly config objects again). Definitely felt like a step backwards although I appreciate the power webpacks gives to people building boilerplates like Create-react-app. I rarely use Gulp anymore but I still appreciate it's UX/DX.

I felt the same, the industry's shift away from the gulp way of doing things was a real loss.

I feel like Gulp sort of shot itself in the foot.

As someone who liked Gulp (SOOO much more than Grunt/Browserify) the transition from v3 to v4 felt really, really bad. Lots of unknowns around release timing, poor community support for the new version, "beta" tags sticking around forever long after it should have been released, maintainer turnover, etc...

It was enough at the time to get me to jump to Webpack, since it seemed like gulp was dying, and if I had to pick a configuration based tool it wasn't going to be Grunt.

Now I'm actually swinging back towards a combination of Gulp and ESBuild on my personal projects. I honestly debated trying a mix of Make and ESBuild (Since Gulp still feels pretty dead, and hasn't had a real release in 2+ years), but Make has enough subtle gotchas that I stuck with something familiar.

You're right about the community being mostly dead. There are a lot of bugs and performance issues in the underlying libraries, and Gulp's developers have not been able to get the upstream updates integrated.

I just redid our Grunt stuff in Gulp. It was painful - difficult to find up-to-date information, and the result was not that great. I expected a much greater SCSS compilation performance increase compared to FS-based tooling. Maybe I'm doing something wrong.

I'd switch to something like ESBuild and leave SCSS for dead, but it's not an option for me yet :(

I remember when we just served the javascript we wrote. Of course we are back to that. You can just write es6 in as many files as you would like and serve it over http/2 without any webpack/esbuild/babble/etc.

The fastest code is no code.

Indeed, the best build chain is no build chain at all. I've been ridiculed at work for not using node, npm, web pack etc -- but I'm not spending 20% of my time on tooling issues.

I'm interested to know who you know spends 20% of their time on tooling issues... I use node, npm and webpack pretty regularly (albeit parcel has mostly replaced webpack for me) and other than setting up some npm scripts and a tsconfig to output the right js for my node version at the start of a project, I barely interact with them.

I think it's more like 80% of time at the start of any project, and then trickles down to no time, then up to 80% again when there's a new feature/config/incompatibility with tooling. In larger projects and in orgs, you often have legacy choices that you have to deal with, that you can't remove or spend time replacing.

With all due respect, that measurement doesn't make a lot of sense! I spend 100% of my time waiting for my editor to open at the start of the day :)

>build time went from 7 minutes on CI to 1 second

I never jumped into that bandwagon and my build times are instantaneous using regular scripts ...

5 if you include grunt.

6 if you include bash/make for using manual scripts to productionize your yui / jqueryUi / mooTools code with uglify/browserify/gcc/etc

Don't forget bun and swc

> I just switched to esbuild on our main project and the build time went from 7 minutes on CI to 1 second.

Is that an exaggeration or did it really get 420x faster?

I would say that's within a believable range of improvement (although on the high end).

We're playing with ESBuild at work, TS/React build that takes 45+ seconds to run with webpack cold, 8 second for a rebuild. With ESBuild/Gulp, the full gulp watch task will refresh in about 1.2 seconds, of which ESBuild ran for about .4 seconds.

So the builds are ~100 times faster with ESBuild, and we're just running it cold every time because it's so fast.

---

It's also really exciting for run-time based compilation. I've been playing around with a server-side React rendering project, and I literally just run esbuild in the controller action in development (some prebuilding for releases) and it's wonderful. Live updates in roughly .6 seconds on average, even for relatively heavy components.

plus, if you're careful with your react code, you can build a react codebase that will actually run if client-side JS is disabled (you can render it all serverside)

Probably not an exaggeration. My build times aren't that long, but I've seen similar speedups in switching the esbuild (our smaller codebases currently build in less than 0.1 of a second with esbuild)

I have not done web development. Please forgive my ignorance. How is this different from Angular and React?

Reply on news.ycombinator.com