Live data from Hacker News

Esbuild – An extremely fast JavaScript bundler

esbuild.github.io

201–210 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#201

Work 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.

I don't understand this perspective. Everyone only has so many hours in a day, and there's only so fast you can work. If he's writing esbuild that is taking time away from being the CTO of Figma. Either he's working a shit ton, one of the things (Esbuild or Figma) is being somewhat neglected, or his output is actually not as high as it looks.

To echo what others have said here, my role as CTO and now CEO has gone from 95% coding to about 5% these days. So some nights I code on ideas and things that have been swirling in my head, just because it’s nice to just quietly write code and solve a finite (but possibly difficult) problem without interruptions. It actually IS therapeutic.

Re: Esbuild – An extremely fast JavaScript bundler

#203
post #124
post #110

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

How is the integration with things like a dev server and tools present in create-react-app like react-fast-refresh? Also, in case of working on an Electron project: How well does it handle main/render/preload compile targets and handling of native modules and linking? Electron-forge is, for instance, the recommended toolchain for building Electron apps and the Webpack stuff is a particular pain in the ass.

Or easily write your own dev server. Once you use the API instead of the CLI, if you have any experience with Express or Connect it's trivial.

Re: Esbuild – An extremely fast JavaScript bundler

#204
post #195
post #110

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

Number 2 is a common pattern. At first developers are exploring things and changing approaches from time to time, so the most flexible solution wins (express, redux, webpack). Then they understand exactly what they need, so they can make a new tool with focus on particular set of use cases and features from the start.

Yeah, we actually went through this with Redux itself.

When Redux was first released in 2015, it was deliberately designed to be minimal and extensible. Other Flux libraries at the time had various forms of async handling built in (support for dispatching actions via promises, etc). Dan and Andrew wanted to avoid locking users in to any single form of async handling [0], so the middleware API was designed to let users pick their preferred async approach and syntax.

Similarly, the store setup process was entirely left up to users to add whatever middleware, enhancers, and other configuration users felt was appropriate. The docs were also always unopinionated about preferred file structures, how to organize logic, etc.

Over time, it became very clear that users _wanted_ more specific guidance about how to structure their apps, and wanted Redux itself to build in default setup and configuration.

As a result, we wrote a "Style Guide" docs page [1] that lists our recommended best practices, and created our official Redux Toolkit package [2] as the standard way to write Redux logic. RTK was designed to solve the most common problems and use cases we saw in the ecosystem [3], including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.

RTK has been extremely successful - we routinely get users telling us how much they enjoy using RTK [4], even if they disliked "vanilla Redux" previously.

We also recently released a new "RTK Query" API [5] [6] in RTK 1.6, which is a built-in data fetching and caching API inspired by libraries like Apollo and React Query. Again, similar theme - we looked at what users were doing and what pain points they were running into, and built an official API to help address those use cases.

[0] https://blog.isquaredsoftware.com/2017/09/presentation-might...

[1] https://redux.js.org/style-guide/style-guide

[2] https://redux-toolkit.js.org

[3] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

[4] https://www.reddit.com/r/reactjs/comments/px6kxy/redux_toolk...

[5] https://redux-toolkit.js.org/rtk-query/overview

[6] https://redux.js.org/tutorials/essentials/part-7-rtk-query-b...

Re: Esbuild – An extremely fast JavaScript bundler

#205
post #127
post #124

Earlier quoted context omitted.

How is the integration with things like a dev server and tools present in create-react-app like react-fast-refresh? Also, in case of working on an Electron project: How well does it handle main/render/preload compile targets and handling of native modules and linking? Electron-forge is, for instance, the recommended toolchain for building Electron apps and the Webpack stuff is a particular pain in the ass.

> How is the integration with things like a dev server and tools present in create-react-app like react-fast-refresh? It’s not. It doesn’t do hot reloading, and it’s one of the features the author rejected I think.

You can build very fast reloading yourself, easily. If I'm smart with persisting state on the client, I find I don't really miss "hot" reloading.

Re: Esbuild – An extremely fast JavaScript bundler

#206
post #194

Earlier quoted context omitted.

> 3. The most impressive part about esbuild development is not just that it's one guy writing it: it is the level of support and documentation he manages to provide alongside. And the one guy writing it is Evan Wallace, co-founder and CTO of Figma. I don't know how he has the time!

I guess build times were a real issue for Figma and it started as an internal project.

This seems like a pet project. Reason I say that is if it was built for work, it would likely be from figma. Instead this project is from Evan himself.

Re: Esbuild – An extremely fast JavaScript bundler

#207
post #110

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

> 3. The most impressive part about esbuild development is not just that it's one guy writing it: it is the level of support and documentation he manages to provide alongside. And the one guy writing it is Evan Wallace, co-founder and CTO of Figma. I don't know how he has the time!

Ironically, the Figma tagline is "Nothing great is made alone"

Re: Esbuild – An extremely fast JavaScript bundler

#208
Full build with Rollup on all of my bundles for my project took around 10 minutes. IDK what my KLoC count is, but it's probably in the 25 to 50K range, with very few dependencies. I had a lot of complexity in my build scripts to try to subdivide related bundles into individual build commands to get the day-to-day rebuilds down to the 1 to 2 minute range. I had to run TypeScript in watch mode separately to emit individual JS files from my TS code for each module, and then only let Rollup bundle the JS code (the available TS plugins were just too slow), so I had tons of garbage files all over everywhere and occasionally they would get out of synch. It was a mess and it was extremely difficult to explain everything to newcomers.

With ESBuild, everything, all the things, build in 0.25 seconds. Build script has massively reduced complexity, as there's no point in running any command other than "build all". There's just the TS code and the output. I'm still running TypeScript in watch mode separately to get compilation errors on the fly (ESBuild doesn't run the TS compiler itself, it has a custom-built translator that optimistically throws away type information), but I no longer configure it to emit translated code. And did I mention the build script is massively simpler?

Re: Esbuild – An extremely fast JavaScript bundler

#209
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.

And I really wish people would stop denying that there can be a massive difference in productivity from one individual to the next. It doesn't really matter what the theoretical limits are. What matters is the people you have and are hiring, and whether or not they are moving the needle.

Maybe we can put aside whether or not there is No True 10x Developer. But there are certainly 0.1x developers, and even -1x developers.

Re: Esbuild – An extremely fast JavaScript bundler

#210

Earlier quoted context omitted.

Maybe there's not much to do as the CTO of Figma. Throwing time into Esbuild doesn't mean he's neglecting his CTO duties.

In which case my last option would be relevant: > or his output is actually not as high as it looks

Frankly most of us would not be able to create esbuild even with all the time in the world.
Post reply on HN