Esbuild is amazing, but it’s worth mentioning SWC, which is written in Rust, even faster than Esbuild, and integrated within Deno, NextJS and other leading tools. Overall I am pretty bullish on the Rust/Js/Wasm/Typescript ecosystem.
Esbuild – An extremely fast JavaScript bundler
181–190 of 288 posts
Re: Esbuild – An extremely fast JavaScript bundler
#182Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…
God bless Evan Wallace
Re: Esbuild – An extremely fast JavaScript bundler
#183Earlier quoted context omitted.
Perhaps that is what makes them '10x developers': a great familiarity with their toolset and a deep understanding of the problems they are solving. In this sense I don't think it's bad to idolize them, as familiarity and understanding are achievable by many people, and they could all become a '10x developer'.
The thing is that people tend to appear to think it's black magic rather than familiarity with a toolset and a deep understanding of the problem.
I wish I could upvote this more, because it's proven by a couple of the other replies to my original comment.
Re: Esbuild – An extremely fast JavaScript bundler
#184Earlier 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.
Bingo. Add to it being able to work in YOUR headspace and not have to bring other people in a large-ish team along with you and you can get stuff done.
Agreed. I think most developers find themselves more productive on their side projects than they are in the workplace because there is less overhead.
Re: Esbuild – An extremely fast JavaScript bundler
#185Personally I've never found bundling speed to be a major bottleneck.
I do have some complicated Webpack setups that I don't think can be solved with any other bundler.
Re: Esbuild – An extremely fast JavaScript bundler
#186You 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.
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.
Re: Esbuild – An extremely fast JavaScript bundler
#187I've been trying to figure out how to build JS projects with the evolving tools (grunt => gulp => webpack => parcel => back to webpack) for years. I stumbled on esbuild and thought why not. Within about 15 minutes, I had solved pretty much all our build issues. Admittedly, our use case was simple-- we needed to transpile React-flavored TS to a npm package. In about 6 lines of code, I had a working bundle. There were no .esbuildrc or esbuild.config.js files, no babel dependencies, and no order of build operations to consider. The tool just worked and it was screaming fast. My first impression was that it _didn't_ work because the process closed in my terminal so quickly.
After my first experiment with it, I rewrote our hundreds of lines Cloud Functions deploy script in about 15 lines (most of which is configuration options on the `build()` method).
I'm curious to explore the tool more. Kudos and thanks to the author for an unbelievably useful contribution.
Re: Esbuild – An extremely fast JavaScript bundler
#188Earlier quoted context omitted.
Perhaps that is what makes them '10x developers': a great familiarity with their toolset and a deep understanding of the problems they are solving. In this sense I don't think it's bad to idolize them, as familiarity and understanding are achievable by many people, and they could all become a '10x developer'.
The thing is that people tend to appear to think it's black magic rather than familiarity with a toolset and a deep understanding of the problem.
Baloney. I don't think it's "black magic", but as a software engineer with some deep familiarity with my tool chain I'm not going to pretend that I could ever be as productive as some of these folks. It's like when I see another post about a Fabrice Bellard project, and I think "he gets done in a year what it would take me about a career".
I don't understand this fetishization of "everyone has nearly equal ability" in the face of tons of overwhelming evidence to the contrary.
Re: Esbuild – An extremely fast JavaScript bundler
#189Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…
This is exactly why the Elixir Phoenix team switched from Webpack to esbuild as the new default. They were spending more time responding to Webpack issues than Phoenix issues and it was an endless time sink.
Re: Esbuild – An extremely fast JavaScript bundler
#190Work on esbuild started at the start of 2020. It is primarily authored and maintained by Evan Wallace, who, in addition to making this tremendous contribution to the JavaScript ecosystem, is the CTO and co-founder of Figma . Incredible output.
Amazing. That means he does his job right! As a good CTO you shouldn't have anything to do. If you're caught up in work, you're doing it wrong.
> As a good CTO you shouldn't have anything to do.
Is this for real? I mean, yeah, I don't think a CTO should be debugging build scripts, but hiring a great team, mentoring, aligning teams with a common technical vision, meeting with other company leaders to ensure the technical direction meets the needs of the business is an immense amount of work.