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…
Esbuild – An extremely fast JavaScript bundler
161–170 of 288 posts
Re: Esbuild – An extremely fast JavaScript bundler
#162Bun [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…
Re: Esbuild – An extremely fast JavaScript bundler
#163Earlier 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.
"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
#164Re: Esbuild – An extremely fast JavaScript bundler
#165What I need is a similar speedup for my Typescript and eslint checks. Bundling isn’t my main issue.
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
#166You 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…
The fastest code is no code.
Re: Esbuild – An extremely fast JavaScript bundler
#167Earlier 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)
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
#168Earlier 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.
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
#169Earlier 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.
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
#170You 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?
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)