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.
Esbuild – An extremely fast JavaScript bundler
201–210 of 288 posts
Re: Esbuild – An extremely fast JavaScript bundler
#202Re: Esbuild – An extremely fast JavaScript bundler
#203Often 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.
Re: Esbuild – An extremely fast JavaScript bundler
#204Often 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.
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
#205Earlier 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.
Re: Esbuild – An extremely fast JavaScript bundler
#206Earlier 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.
Re: Esbuild – An extremely fast JavaScript bundler
#207Often 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!
Re: Esbuild – An extremely fast JavaScript bundler
#208With 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
#209Earlier 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.
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
#210Earlier 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