Live data from Hacker News

Esbuild – An extremely fast JavaScript bundler

esbuild.github.io

161–170 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#161
post #151

Bun [1] is a JS bundler based on esbuild’s source, but written in Zig. And it is about 3x faster than esbuild. I think its author Jarred is on HN as well. Probably worth a submission on its own but I am just waiting till it is fully open source. Edit: ( Deleted those Stats, since it may not be a fair comparison and it was probably not meant to be a fair benchmark in the first place. The details are still in the linke…

The numbers seem cherry picked though, I don't like this type of 197.96432100004x faster claims.

Re: Esbuild – An extremely fast JavaScript bundler

#162
post #151

Bun [1] is a JS bundler based on esbuild’s source, but written in Zig. And it is about 3x faster than esbuild. I think its author Jarred is on HN as well. Probably worth a submission on its own but I am just waiting till it is fully open source. Edit: ( Deleted those Stats, since it may not be a fair comparison and it was probably not meant to be a fair benchmark in the first place. The details are still in the linke…

Granted, those stats are for JSX, but it’ll be interesting to check out for sure.

Re: Esbuild – An extremely fast JavaScript bundler

#163
post #91

Earlier quoted context omitted.

I came here too say this. The man authored in the neighborhood of 100k LOC in a year, just on this. There's a living 10x dev, it's not a myth. What is ridiculous is to think someone can 10x a normal developer, it's more like the difference between the top few percent and the bottom 10-20%. Evan Wallace is a beast, no doubt.

I really wish people would stop idolising so called '10x' developers. Anyone that is comfortable and familiar with their toolset (e.g. go, .NET, Java, C++) and has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster than an onlooker.

10xer is not about churning out code.

"Why is DJ Bernstein so great? I too can churn out CRUD apps very fast in ruby rails" - some webshit says this every day on HN.

Re: Esbuild – An extremely fast JavaScript bundler

#164
I started with webpack using create react app, I tried parcel, I tried esbuild. I tried parcel 2. I use esbuild. As a sole developer it takes no thought, and it still lets me do odd things pretty easily - like I have a particular process for dealing with odd cases in mdx files. Not a ringing endorsement or an exhaustive analysis. I'm just happy I don't have to spend time thinking about it. :-)

Re: Esbuild – An extremely fast JavaScript bundler

#165
post #8

What I need is a similar speedup for my Typescript and eslint checks. Bundling isn’t my main issue.

For ESLint:

https://eslint.org/docs/user-guide/command-line-interface#ca...

For TS, tsc has an —incremental flag. ts-fork-checker-plugin is non-blocking for the rest of the build too.

Re: Esbuild – An extremely fast JavaScript bundler

#166
post #113

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…

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.

Re: Esbuild – An extremely fast JavaScript bundler

#167
post #159

Earlier quoted context omitted.

I really wish people would stop idolising so called '10x' developers. Anyone that is comfortable and familiar with their toolset (e.g. go, .NET, Java, C++) and has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster than an onlooker.

> has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster Is this a bad thing to discourage? Perhaps one way to increase your output as a developer is to narrow your focus (rather than jumping on the latest framework or build system which require constantly re-learning new solutions to the same problem)

> Is this a bad thing to discourage?

No. It's what I encourage people in my team to do all the time. In fact it's something I was also encouraged to do.

The full quote was:

"Become an expert in at least one thing in your job or preferably career, and do it while you have the time" (e.g. when you're junior and expectations are low, or not a manager).

Re: Esbuild – An extremely fast JavaScript bundler

#168

Earlier quoted context omitted.

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 apprecia…

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.

Re: Esbuild – An extremely fast JavaScript bundler

#169

Earlier quoted context omitted.

I really wish people would stop idolising so called '10x' developers. Anyone that is comfortable and familiar with their toolset (e.g. go, .NET, Java, C++) and has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster than an onlooker.

10xer is not about churning out code. "Why is DJ Bernstein so great? I too can churn out CRUD apps very fast in ruby rails" - some webshit says this every day on HN.

That's a bit of a strawman. My full comment is that being familiar with your language of choice, and having a deep understanding of a problem means that can produce a solution faster than someone that doesn't. I used the phrase 'churn out', I could have simply said 'produce'.

I've worked in the industry for almost 30 years, and I've worked with a lot of people in that time. Those that you might qualify as '10x', all have had both of the qualities I mention.

I would not expect any of those people to switch languages and fields and still be a '10x' developer.

Re: Esbuild – An extremely fast JavaScript bundler

#170
post #126
post #113

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…

> 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)

Post reply on HN