Esbuild – An extremely fast JavaScript bundler(esbuild.github.io)
esbuild.github.io
Esbuild – An extremely fast JavaScript bundler
https://esbuild.github.io/
287 comments
Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts?
It seems there’s a feature treadmill at work here where projects inexorably bloat as they get popular. But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. I wonder if there is a middle way that can prevent the tool from giving in to the pressure to add features.
It seems there’s a feature treadmill at work here where projects inexorably bloat as they get popular. But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. I wonder if there is a middle way that can prevent the tool from giving in to the pressure to add features.
Something a lot of people don’t appreciate is that the past ten years have been an anomaly for JavaScript. They’ve been very tumultuous because there was a ton of evolving that suddenly needed to happen. And I think we’re nearing the end.
Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc. Esbuild is only possible because we’ve generally converged on TypeScript, JSX, ES modules, etc. It knows what you probably were going to configure webpack to do anyway, so it can just do it.
So I wouldn’t call it a “treadmill”, I’d call it growing pains
Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc. Esbuild is only possible because we’ve generally converged on TypeScript, JSX, ES modules, etc. It knows what you probably were going to configure webpack to do anyway, so it can just do it.
So I wouldn’t call it a “treadmill”, I’d call it growing pains
This is a great point. A "Cambrian explosion" the likes of which the JS ecosystem experienced over the last 10-15 years will slow down eventually. Curious to hear whether other folks agree or not.
I survived the JavaScript Cambrian explosion and all I got was a disenchantment with computer programming
To me, it feels like the same effect as Ruby ~15-10 years ago. Lots of chaos as good (subsequently winnowed down to preferred), patterns were discovered, and then things stabilized. It isn't sexy anymore, but to this day I've yet to discover a better tool, that lets me blast out features and make changes at rapid pace, than Ruby (and Rails on the web side).
Yeah, it’s a great point. I always assumed that there was so much tool churning just because of the nature of the front-end itself as a target for building software.
However I think the “Cambrian explosion” point here makes a lot of sense.
However I think the “Cambrian explosion” point here makes a lot of sense.
I take your point, but I think you could fairly say that JS has been going through growing pains since its inception 25 years ago. It's always been a fast-moving, inconsistently-implemented language. (E.g. Netscape / Mozilla vs. IE support for browser features).
Maybe things are going to calm down a bit? I could believe it. But I just don't see the churn stopping. The browser-as-OS is going to keep getting new features, which JS must bind to. And some users are going to use old browsers that don't support them. So the runtime is inexorably fragmented, vs. say a server-side environment where you mostly write code for a well-known runtime that you get to define.
And what about when everybody starts using wasm to compile other languages into JS? Another explosion of tooling and changes to how we do web development is just round the corner.
Regardless of whether we're coming to the end of it, I think it's more specific than just "growing pains" though - it's not just that we're fixing issues, it's that we're repeatedly throwing away old tools in favor of smaller, more-focused new tools, that then in turn grow in scope over time.
I'm not even mad at all this; I think it's a fundamental part of how software languages and communities make progress; there's no real path for a language/tool/framework to get _smaller_, so they either increase in scope or stay the same, with the latter being quite rare, and both options giving a path for some other thing to supersede them.
I just think it's most pronounced in the JS ecosystem, and find it amusing that we've come full circle on so many of these points, again - although I believe with genuine improvements on the previous iterations. (So more like a spiral; the same location in some dimensions, but with a higher elevation.)
Maybe things are going to calm down a bit? I could believe it. But I just don't see the churn stopping. The browser-as-OS is going to keep getting new features, which JS must bind to. And some users are going to use old browsers that don't support them. So the runtime is inexorably fragmented, vs. say a server-side environment where you mostly write code for a well-known runtime that you get to define.
And what about when everybody starts using wasm to compile other languages into JS? Another explosion of tooling and changes to how we do web development is just round the corner.
Regardless of whether we're coming to the end of it, I think it's more specific than just "growing pains" though - it's not just that we're fixing issues, it's that we're repeatedly throwing away old tools in favor of smaller, more-focused new tools, that then in turn grow in scope over time.
I'm not even mad at all this; I think it's a fundamental part of how software languages and communities make progress; there's no real path for a language/tool/framework to get _smaller_, so they either increase in scope or stay the same, with the latter being quite rare, and both options giving a path for some other thing to supersede them.
I just think it's most pronounced in the JS ecosystem, and find it amusing that we've come full circle on so many of these points, again - although I believe with genuine improvements on the previous iterations. (So more like a spiral; the same location in some dimensions, but with a higher elevation.)
>when everybody starts using wasm
I would say this is a far off possibility. The need to write WASM code rarely surfaces for the average SPA, and really seems like its more applicable to games or sites with heavy processing needs.
For better or worse, it's going to be JS/TS for a long while yet.
I would say this is a far off possibility. The need to write WASM code rarely surfaces for the average SPA, and really seems like its more applicable to games or sites with heavy processing needs.
For better or worse, it's going to be JS/TS for a long while yet.
Perhaps I used the wrong phrase with “just around the corner”. My prediction would be that we’ll see major SPAs in wasm in ~3-5 yrs.
This is not imminent from a developer’s perspective, but I think it is close on the “language evolution” timescale. As in, soon enough that I’m not sure we will have a long period where JS stabilizes before wasm revolutionizes it again.
Not a high-confidence prediction either way though.
This is not imminent from a developer’s perspective, but I think it is close on the “language evolution” timescale. As in, soon enough that I’m not sure we will have a long period where JS stabilizes before wasm revolutionizes it again.
Not a high-confidence prediction either way though.
I avoided this fact for years, running from JS/TS for “better languages”. After a stint with Haskell I’ve decided the grass isn’t that much greener so just accepting that JS is what it is - one of the worlds most popular languages which can run in most places and therefore worth learning.
I'm curious, what turned you away from Haskell?
ESBuild’s author and docs[1] are quite clear about its future scope:
> [… a list of features that are already done…]
> After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers.
That said, now quoting you…
> But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about.
In this respect, ESBuild’s firm stance has a major strength, and a major weakness:
- Strength: the Unix philosophy is easy to achieve, with esbuild-plugin-pipe[2]. There’s just one, simple plugin API, everything follows that same format
- Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool
1: https://esbuild.github.io/faq/#upcoming-roadmap
2: https://github.com/nativew/esbuild-plugin-pipe
> [… a list of features that are already done…]
> After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers.
That said, now quoting you…
> But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about.
In this respect, ESBuild’s firm stance has a major strength, and a major weakness:
- Strength: the Unix philosophy is easy to achieve, with esbuild-plugin-pipe[2]. There’s just one, simple plugin API, everything follows that same format
- Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool
1: https://esbuild.github.io/faq/#upcoming-roadmap
2: https://github.com/nativew/esbuild-plugin-pipe
"Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool"
I think by the time we even care about the performance of a plugin being "golang" fast, we will have rome built in rust.
Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done.
I think by the time we even care about the performance of a plugin being "golang" fast, we will have rome built in rust.
Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done.
> I think by the time we even care about the performance of a plugin being "golang" fast
I certainly care about it being faster than estree-*/babel. There are a lot of static analysis and optimization things I’d like to do that are slow enough in JS to negate a lot of ESBuild’s advantage.
> we will have rome built in rust.
> Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done.
Is Rome-Rust doing something special to optimize arbitrary AST-based plugins written in JS? I hadn’t heard that but I’d be interested if it is.
I certainly care about it being faster than estree-*/babel. There are a lot of static analysis and optimization things I’d like to do that are slow enough in JS to negate a lot of ESBuild’s advantage.
> we will have rome built in rust.
> Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done.
Is Rome-Rust doing something special to optimize arbitrary AST-based plugins written in JS? I hadn’t heard that but I’d be interested if it is.
> Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts?
Don't recall perf being the win with Webpack, Webpack was "Web-Pack" because it allowed you to use CommonJS to co-locate external assets (SVGs, CSS, etc) with code, and then being able to produce distinct bundles from that dependency graph. Grunt had no clue what your source dep graph looked like, you had to build your own pipeline (specifying dependent tasks for each task). Of course, now everybody has their own Webpack config that alters some input or output, but it's a considerably more powerful tool than Grunt ever was.
Don't recall perf being the win with Webpack, Webpack was "Web-Pack" because it allowed you to use CommonJS to co-locate external assets (SVGs, CSS, etc) with code, and then being able to produce distinct bundles from that dependency graph. Grunt had no clue what your source dep graph looked like, you had to build your own pipeline (specifying dependent tasks for each task). Of course, now everybody has their own Webpack config that alters some input or output, but it's a considerably more powerful tool than Grunt ever was.
I really don’t, webpack config was was a cluster&€@ from day 1.
Also, webpacks goal always was to do everything and the kitchen sink, much different from esbuild.
Seconding that. It’s the one reason I never started using webpack in the first place, at least not from scratch.
Angular ships with a working config out of the box, and I hope I never, ever will have to tweak that to fix a build.
Angular ships with a working config out of the box, and I hope I never, ever will have to tweak that to fix a build.
> Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts?
You're forgetting the 6 months where everyone rewrote everything with Gulp.
You're forgetting the 6 months where everyone rewrote everything with Gulp.
The Convention Over Configuration crowd has their arguments.
> 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!
And the one guy writing it is Evan Wallace, co-founder and CTO of Figma. I don't know how he has the time!
Figma's tech is mindblowing. Their entire engine is custom-built in C++ : https://www.figma.com/blog/building-a-professional-design-to...
> Instead of attempting to get one of [HTML/SVG/JS Canvas] to work, we implemented everything from scratch using WebGL. Our renderer is a highly-optimized tile-based engine with support for masking, blurring, dithered gradients, blend modes, nested layer opacity, and more. All rendering is done on the GPU and is fully anti-aliased. Internally our code looks a lot like a browser inside a browser; we have our own DOM, our own compositor, our own text layout engine, and we’re thinking about adding a render tree just like the one browsers use to render HTML.
To most people, esbuild would be a full-time job. Based on the above, it seems that to Evan it's a fraction of the work he did in Figma's early days all at once!
> Instead of attempting to get one of [HTML/SVG/JS Canvas] to work, we implemented everything from scratch using WebGL. Our renderer is a highly-optimized tile-based engine with support for masking, blurring, dithered gradients, blend modes, nested layer opacity, and more. All rendering is done on the GPU and is fully anti-aliased. Internally our code looks a lot like a browser inside a browser; we have our own DOM, our own compositor, our own text layout engine, and we’re thinking about adding a render tree just like the one browsers use to render HTML.
To most people, esbuild would be a full-time job. Based on the above, it seems that to Evan it's a fraction of the work he did in Figma's early days all at once!
He seems to like writing code
Ironically, the Figma tagline is "Nothing great is made alone"
What in the world? And some say 10x engineers don’t exist…
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.
I'm not so sure about that as you. Not all companies are like Google and "steal" the credit of work done by employees, even if done on work time but unrelated to the core business. Plenty of companies let employees work on open source and still remain the owners of the software produced.
Massively impressive!
> I have two 50K+ LOC projects using esbuild, and I would use it even if it was slower than webpack/babel/tsc simply not to worry about the build chain breaking due to an update to some obscure dependency or plugin.
This was the reason that Phoenix 1.6 switched away from webpack to esbuild, apparently half the reported issues were webpack related!
This was the reason that Phoenix 1.6 switched away from webpack to esbuild, apparently half the reported issues were webpack related!
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.
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...
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...
[deleted]
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.
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.
You can use vite for that, which is an enhanced wrapper for esbuild. I use it on all of my projects except the ones I'm forced to use webpack on for legacy reasons.
> 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.
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.
This looks promising: https://github.com/pradel/create-react-app-esbuild
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.
We're using Vite and enjoying it, would you say much of Vite could be replaced with pure esbuild?
I guess Vite provides a nice development experience but is built on esbuild.
I guess Vite provides a nice development experience but is built on esbuild.
There is a short paragraph adressing this on the "Why Vite" page: https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
I'm also a huge fan of HMR, and esbuild in the past has been anti-HMR.
I'm also a huge fan of HMR, and esbuild in the past has been anti-HMR.
I guess it depends on your project and workflow preferences. Personally, I'm not a big fan of HMR and the bundling times are negligible even without "pre-bundling" npm dependencies (as Vite puts), so I see little reason for Vite.
We switched over to Vite some time back and it's been pretty life changing. We're using react and tailwind too, so the HMR works really well for us.
The config is beyond minimal. If you're using webpack you may want to look away now :-)
The config is beyond minimal. If you're using webpack you may want to look away now :-)
import { resolve } from 'path'
import { defineConfig } from 'vite'
import reactRefresh from '@vitejs/plugin-react-refresh'
export default defineConfig({
plugins: [reactRefresh()],
build: {
rollupOptions: {
input: {
index: resolve(__dirname, 'index.html'),
}
},
sourcemap: true
},
esbuild: {
jsxInject: `import * as React from "react"`
},
resolve: {
alias: [
{ find: '@', replacement: '/src' },
]
},
})God bless Evan Wallace
Has anyone given you crap for your username? I know you had the username long before MAGA became a popular word in the american lexicon, but I'm still curious!
Yeah, the funny part is that I have never even been to US of A let alone having anything in common with the said movement. No, to be honest, I don't recall anyone mentioning it here on HN or GitHub. I don't use other social media, though, I guess it would be more of an issue there. However, I was wrongly suspended on Twitter once despite not posting (or even "liking") anything the whole decade of being there. I just used the account for OAuth subscription, one day it stopped working, I had to write a letter and wait for manual "unsuspension.
I chose my now "nom de plume" way back in zeros for its seeming originality and simplicity, when compared to my rather common and unwieldy "real" Polish name.
I chose my now "nom de plume" way back in zeros for its seeming originality and simplicity, when compared to my rather common and unwieldy "real" Polish name.
[deleted]
The process is cyclical.
Make, Cmake and autoconf offered solutions in this space, but for C/C++.
I do like what esbuild and swc are doing though.
Make, Cmake and autoconf offered solutions in this space, but for C/C++.
I do like what esbuild and swc are doing though.
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 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.
While he is certainly an excellent developer with great productivity to boot, LOC is an obtuse metric. For example there is a package-lock.json commit which is almost 20K lines. Otherwise I totally agree.
Agree, if anything it should be the reverse, less LOC produced means more efficient developer. But that's also a shit metric, as then people start cramming in as much complexity in every line as possible.
Best would be if we could actually measure "complexity" in a objective manner.
Best would be if we could actually measure "complexity" in a objective manner.
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.
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.
Ehhh no I don’t think it’s that simple.
I’ve found that in any tech company, while there are many people that write good code and do a great job, there are always a handful (even at a place like Apple) that truly push the industry forward and in certain directions, partly because of how they see years ahead, partly because they are supremely talented, and partly because they attract other really good talent just to work with them.
And we know many of their names. Folks like Brian Cantrill, Yehuda Katz, Fabrice Bellard, John Carmack, Bret Taylor.
They aren’t just good programmers. They’re constantly dwelling in uncharted territory.
I’m not advocating worshipping them, just stating that their talent and output is hell of a lot more than even 10x.
I’ve found that in any tech company, while there are many people that write good code and do a great job, there are always a handful (even at a place like Apple) that truly push the industry forward and in certain directions, partly because of how they see years ahead, partly because they are supremely talented, and partly because they attract other really good talent just to work with them.
And we know many of their names. Folks like Brian Cantrill, Yehuda Katz, Fabrice Bellard, John Carmack, Bret Taylor.
They aren’t just good programmers. They’re constantly dwelling in uncharted territory.
I’m not advocating worshipping them, just stating that their talent and output is hell of a lot more than even 10x.
I understand what you're saying, but I'd still argue that they're supremely familiar with their toolchain, and have a deep understanding of the problems they're trying to solve. My comment said they've usually solved the problem at least once already, but I don't discount people solving new problems.
[deleted]
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.
I don't understand this fetishization of "everyone has nearly equal ability" in the face of tons of overwhelming evidence to the contrary.
I don't believe everyone has the same ability. What I do believe is that performance is explainable and there's a practical upper limit to raw output.
I made a side project that I spent 1-2years building on and off and had people saying "wow I could never build that". That's bullshit. If they were of similar intelligence and put in a similar amount of time and effort I'm sure they'd be able to replicate what I did.
The luxury of being able to spend ample amounts of time on a project or idea is also massively overlooked.
I made a side project that I spent 1-2years building on and off and had people saying "wow I could never build that". That's bullshit. If they were of similar intelligence and put in a similar amount of time and effort I'm sure they'd be able to replicate what I did.
The luxury of being able to spend ample amounts of time on a project or idea is also massively overlooked.
That's not all it is. Some people are just better than others. No matter how hard every tries to be the best football or basketball player, only an extremely small set of people even have the chance to make it. There are physical traits they'll never have and mental fortitude to use those traits. You can't grow yourself to 7 ft tall and you never will be able to. What makes you think the brain is any different.
If you take the perspective that some people are "just better" than others, why are we idolizing these people?
Being born with high intelligence and favourable traits is not an achievement.
Being born with high intelligence and favourable traits is not an achievement.
> If you take the perspective that some people are "just better" than others, why are we idolizing these people?
Good question. Take it up with the people wearing jersey's with Lebron James' and Aaron Rodgers' names on them.
Good question. Take it up with the people wearing jersey's with Lebron James' and Aaron Rodgers' names on them.
lol, yeah. I don't idolize them. I'm just aware of my limitations.
I wish I could upvote this more, because it's proven by a couple of the other replies to my original comment.
No more than people think making it to the Olympics is "black magic".
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.
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.
I totally agree with you, but I also love the context of this quote with your username ;)
Sure, like anyone can be Usain Bolt if they are familiar with their body and has a deep understanding of running.
> 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? 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).
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).
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.
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.
I dont think the parent is just about LOC, but the quality of those LOC.
There are people producing JS bundler and are comfortable and familiar with their toolset along with deep understanding of the problem. And they dont even come close to what is being described here.
There are people producing JS bundler and are comfortable and familiar with their toolset along with deep understanding of the problem. And they dont even come close to what is being described here.
Being proficient in your tech stack helps your output sure but it's only one part (and a small one IMO) of the equation for creating something like esbuild. The author of esbuild surely has a strong knowledge of computer architecture, data structure and algorithms, operating systems and some math.
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.
"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.
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.
I would. Languages aren’t as important as you would think. Certain people can pick up the new idioms quickly and run with it.
Look at someone like Yehuda Katz. Substantial contributions in ruby (merb, bundler), JS (jQuery core team, created Ember.js), and rust (created cargo).
But trying to elevate him or make him uncomfortable (he’s also a really humble dude), but just saying there are examples of polyglots that make substantial contributions.
Look at someone like Yehuda Katz. Substantial contributions in ruby (merb, bundler), JS (jQuery core team, created Ember.js), and rust (created cargo).
But trying to elevate him or make him uncomfortable (he’s also a really humble dude), but just saying there are examples of polyglots that make substantial contributions.
But isn’t what you said a bit of a straw man too? Back in the music comparison, no one would expect an excellent guitarist to take up playing piano and still be a virtuoso.
And yet… we do recognize that some people are impressively better than others at playing piano, running yards, fighting, and all sorts of other narrowly specific tasks.
It’s just that the more creative the task, the harder it to measure how much better someone is.
And yet… we do recognize that some people are impressively better than others at playing piano, running yards, fighting, and all sorts of other narrowly specific tasks.
It’s just that the more creative the task, the harder it to measure how much better someone is.
Calling people "webshits" is not really in the spirit of HN imo.
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.
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.
and he's building tools to optimize his teams.
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.
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.
As someone that ran a company while working on side open source projects, don't underestimate the therapeutic value of writing code. (As a CEO, my job had almost no coding, and working on my opensource projects made me happy, and restored a lot of my energy.)
CTO and lead developer on a focused project are very different jobs - my guess would be he relaxes from the very strategy and soft-skill heavy day job by diving into a challenging problem that keeps his dev chops up and lets him focus on a finite problem.
So working a shit ton then.
No idea on Evan Wallace's perspective but there is a possibility that it isn't seen as work. It would like be me solving sudoku or some of my friends building LEGOs or solving extremely hard jigzaw puzzles
I understand that because it's often how I feel when I'm doing programming work. However, I would still consider that time spent working.
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.
Same
The tool is likely helping Figma pretty directly by cutting developer build times.
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.
Sounds like he solved his own problem?
Surprise, I didn’t know who was the maintainer and was still unheard of back then until I shared on HN and it was a like wildfire.
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 linked tweets. I do not know the author or am I in anyway affiliate with Bun. )
I am also wondering how much of those optimisation could be used on ESbuild. Since Rails 7 and Phoenix 1.6 will be using esbuild and not Webpack.
[1] https://twitter.com/jarredsumner/status/1390084458724741121
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 linked tweets. I do not know the author or am I in anyway affiliate with Bun. )
I am also wondering how much of those optimisation could be used on ESbuild. Since Rails 7 and Phoenix 1.6 will be using esbuild and not Webpack.
[1] https://twitter.com/jarredsumner/status/1390084458724741121
The numbers seem cherry picked though, I don't like this type of 197.96432100004x faster claims.
I’m pretty sure ESBuild’s creator has agreed that Bun’s performance claims are probably correct, and that there’s still more room for optimization of/beyond both.
Granted, those stats are for JSX, but it’ll be interesting to check out for sure.
I'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.
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.
> My first impression was that it _didn't_ work because the process closed in my terminal so quickly.
We switched to an esbuild/vite/rollup stack mid year and had the same experience, it's black magic compared to web pack et al
We switched to an esbuild/vite/rollup stack mid year and had the same experience, it's black magic compared to web pack et al
ESbuild is getting fantastic traction. It’s the default in Phoenix from 1.6 and comes as a default option in the current alpha of Rails 7, which you can get with a simple
rails new your_app -j esbuild
The only sort of issue I’ve had with it so far is you can’t use it with Inertiajs[1] as it does not support dynamic imports out of the box. Although I’m hesitant to call it an issue if its not in the scope of the project. Perhaps there are plugins I can use.
[1] - https://inertiajs.com
rails new your_app -j esbuild
The only sort of issue I’ve had with it so far is you can’t use it with Inertiajs[1] as it does not support dynamic imports out of the box. Although I’m hesitant to call it an issue if its not in the scope of the project. Perhaps there are plugins I can use.
[1] - https://inertiajs.com
Esbuild w/rails 7 is nice, but if you’re using rails, check out vite_ruby [1]. I used it in a side project and it comes with plugins for views HMR + all the good stuff that comes built into vite.
1: https://github.com/ElMassimo/vite_ruby
1: https://github.com/ElMassimo/vite_ruby
Yes 100% - I’m actually using Vite Ruby in a project as I really wanted to use Inertia + React and that was by far the easiest way to get everything up and running.
I’d go so far as to say I wish -j vite was an option in js-bundling :)
I’d go so far as to say I wish -j vite was an option in js-bundling :)
Does it not support dynamic imports at all, or does it just not support “dynamic dynamic imports” i.e. dynamic imports where the module path is not constant?
If it’s the latter, you could have your Inertia page resolver be a giant switch statement of every possible page, where each case is a dynamic import call with a constant module name.
Kind of a pain but I think I’d prefer that if it meant I never had to write a webpack config again.
If it’s the latter, you could have your Inertia page resolver be a giant switch statement of every possible page, where each case is a dynamic import call with a constant module name.
Kind of a pain but I think I’d prefer that if it meant I never had to write a webpack config again.
You can use esbuild to your existing rails apps via the gem jsbundling-rails https://github.com/rails/jsbundling-rails
It works really well
It works really well
Why is it so fast? Mainly because:
- It's written in Go and compiles to native code. [...] While esbuild is busy parsing your JavaScript, node is busy parsing your bundler's JavaScript. By the time node has finished parsing your bundler's code, esbuild might have already exited and your bundler hasn't even started bundling yet. [...] Go is designed from the core for parallelism while JavaScript is not.
- Parallelism is used heavily.
https://esbuild.github.io/faq/#why-is-esbuild-fast
- It's written in Go and compiles to native code. [...] While esbuild is busy parsing your JavaScript, node is busy parsing your bundler's JavaScript. By the time node has finished parsing your bundler's code, esbuild might have already exited and your bundler hasn't even started bundling yet. [...] Go is designed from the core for parallelism while JavaScript is not.
- Parallelism is used heavily.
https://esbuild.github.io/faq/#why-is-esbuild-fast
Even in single threaded mode it’s fast. I think the main idea is that it creates an AST only a couple of times and then caches it so that the AST can be reused. Webpack on the other hand gets engulfed by its plugins which often do so multiple times.
We recently switched on a few of our project from Webpack and the difference is incredible. Running a watch using this is practically instantaneous compared to our previous setup. I've been recommending it to all my colleagues and we're replacing Webpack slowly but surely.
The main draw for me is the simplicity of the config too. Webpack config (even using things like Symfony's Encore) is pretty convoluted and confusing to track. This, at least in my experience, has greater readability and is simpler to understand.
The main draw for me is the simplicity of the config too. Webpack config (even using things like Symfony's Encore) is pretty convoluted and confusing to track. This, at least in my experience, has greater readability and is simpler to understand.
Webpack is a bane of webdev existence.
Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself
Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself
>Webpack is a bane of webdev existence.
Modern Web Dev is the cause of Webpack though. Over complicated things.
Modern Web Dev is the cause of Webpack though. Over complicated things.
I cannot count the days I've spend on webpack config breakage during the last years at work. It's never really been good at all either. The gulp setup we had before worked faster, better and didn't break once a month. Webpack really only is a pet project of the idiocratic React-community. Facebook not only screws your personal data over, also your dev workflow!
what are you talking about, webpack has nothing to do with Facebook or React.
esbuild is fast but it has a lot of place you have to figure out yourself and get into your way of doing thing.
1. dev server: you have to write a bit of code for this server to act as webpack dev server 2. scss: need to install plugin, and plugin cannot use from command line then you need to write a bit of JavaScript 3. global function: if you do `process.env` now you need to inject into build script 4. node package: if the package use node stuff you have to define thing like `fs/stream` into package.json
very quickly it get into your way of doing thing.
However, once you get past that base line, the cost is constant, the complexity just stop right there and not adding up.
Plus, the speed is amazing.
1. dev server: you have to write a bit of code for this server to act as webpack dev server 2. scss: need to install plugin, and plugin cannot use from command line then you need to write a bit of JavaScript 3. global function: if you do `process.env` now you need to inject into build script 4. node package: if the package use node stuff you have to define thing like `fs/stream` into package.json
very quickly it get into your way of doing thing.
However, once you get past that base line, the cost is constant, the complexity just stop right there and not adding up.
Plus, the speed is amazing.
This is exactly what I found when I tried esbuild a few months ago. I gave up and went with Parcel 2 at the time as I found it easier to get going (although there were teething problems with Parcel being beta at the time).
I need to give esbuild another go I think.
I need to give esbuild another go I think.
esbuild is partially [0] used in Vite [1] where you get a dev server et al.
- [0] https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil... - [1] https://vitejs.dev/
- [0] https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil... - [1] https://vitejs.dev/
How is the SCSS performance? I've tried just about every trick in the book in an attempt to get our bootstrap-based SCSS projects to compile faster, and I'm at my wits end with it.
Any chance you can share your config?
Any chance you can share your config?
My project is small and it's amazing fast to me as well. It's basically just outsource its job to another cli. I used esbuild-plugin-sass
This is the gist https://gist.github.com/v9n/c40a6ad2078d09dd86117924b415b7fb
As far as I know, esbuild has no intention to integrate with CSS and will outsorce it to plugin.
I used
This is the gist https://gist.github.com/v9n/c40a6ad2078d09dd86117924b415b7fb
As far as I know, esbuild has no intention to integrate with CSS and will outsorce it to plugin.
I used
Thank you so much for sharing!
I'll give this a shot really quick
I'll give this a shot really quick
3. You can inject anything you want without a plugin with `inject`.
4. You can just use `target: node` (or node12, node14.6, etc)
4. You can just use `target: node` (or node12, node14.6, etc)
See also SWC, something similar to esbuild but written in Rust. NextJS uses SWC as well as Deno.
Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.
Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.
The announcements from NextJS has been really confusing. I don't think they are using SWC yet. They are just working on it. The reason for the confusion is because they write about the progress in the release notes, making it look like they are using it.
SWC in NextJS is still in canary with experimental settings, but it took me 3 lines of code yesterday to make it work on a fairly large app ( https://labelflow.ai ). Hot reload times instantly went from 10s to 1s. Twitter discussion here https://twitter.com/vlecrubier/status/1448371633673187329?s=...
Overall I’m pretty bullish on Rust tooling and integration within the JS/ Wasm ecosystem !
Overall I’m pretty bullish on Rust tooling and integration within the JS/ Wasm ecosystem !
could you provide a link on how to enable this experimental setting ? thank you.
https://github.com/swc-project/swc/discussions/2097#discussi...
- Run yarn add next@canary
- Add to your next.config.js:
- Run yarn add next@canary
- Add to your next.config.js:
experimental: {
swcMinify: true,
swcLoader: true
}It's being using to bundle some parts of nextjs itself, but not quite ready to replace babel for users rn afaik
May be in next release we get swc in nextjs?
I'm using this to compile typescript lambda functions for AWS with great success.
Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.
I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors.
Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradiction to using Typescript so I set up a Webpack build using the standard ts compiler.
I've been out the loop of client side stuff a couple of years so to start was bit of a rabbit hole. Grunt/Gulp had gone and now Webpack seems common with a growing fanbase for ESbuild because of it's speed.
Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradiction to using Typescript so I set up a Webpack build using the standard ts compiler.
I've been out the loop of client side stuff a couple of years so to start was bit of a rabbit hole. Grunt/Gulp had gone and now Webpack seems common with a growing fanbase for ESbuild because of it's speed.
Consider TypeScript like a linter. ESBuild doesn't run ESLint for you either - you can run it separately, or in parallel.
This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.
This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.
First, forgive my ignorance of the JS/TS and bundler ecosystems.
> while in parallel checking for type errors.
Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invoke an external resource, tsc?
Would it not make sense to have two development bundlers then? One for getting your code up and running quickly, and a second that outputs a dummy build artifact, but allows a more thorough production-like build that includes type checking (or other long running activities)? That way you get all the verification you would like, but don't pay a price on waiting for your code to deploy?
> while in parallel checking for type errors.
Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invoke an external resource, tsc?
Would it not make sense to have two development bundlers then? One for getting your code up and running quickly, and a second that outputs a dummy build artifact, but allows a more thorough production-like build that includes type checking (or other long running activities)? That way you get all the verification you would like, but don't pay a price on waiting for your code to deploy?
You can absolutely run it during development! In fact, many people will use an editor that automatically does this and highlights any potential errors - which means you don't need your compiler to display them (or even block compiling) as well.
And yes, type checking is relatively slow, and also strictly extra work, since it's not required to make your code runnable.
You'll often see that people do still do a more thorough production build in their CI systems, but not necessarily by using a bundler that includes type checking; rather, they just run type checking and bundling as separate tasks. That way, you do indeed get all the verification you would like without having to delay deployment.
(To make it somewhat more confusing, a project like Vite does use a fast bundler (ESBuild) during development and a more thorough one for production (Rollup), but that's independent of type checking. It's more about the latter doing more optimisations, and the former merely making the code runnable by the browser.)
And yes, type checking is relatively slow, and also strictly extra work, since it's not required to make your code runnable.
You'll often see that people do still do a more thorough production build in their CI systems, but not necessarily by using a bundler that includes type checking; rather, they just run type checking and bundling as separate tasks. That way, you do indeed get all the verification you would like without having to delay deployment.
(To make it somewhat more confusing, a project like Vite does use a fast bundler (ESBuild) during development and a more thorough one for production (Rollup), but that's independent of type checking. It's more about the latter doing more optimisations, and the former merely making the code runnable by the browser.)
Not blocking on typecheck failures is one of my favorite features of TypeScript -- you can rapidly test/debug/iterate on code with "broken" or incomplete types while in the prototyping stages of feature development.
This is pretty common if you're looking for build performance. E.g. typecheck as a lint step with tsc, build with babel removing your typescript (it doesn't typecheck either), etc. It's true that tsc on its own can replace a build step for some folks, but you'll quickly find it limiting both in the options to rollup or combine files and in its ability to be extended with plugins (unlike Babel), etc. On the other hand, tsc and its language server is a first-class type-checker when run with no-emit. ;-) I haven't played as much with esbuild yet but it's on my todo list.
Practically, it isn't an issue if you use VSCode which has the Typescript language server built in to catch type errors for you.
If you want, your build script can include
If you want, your build script can include
`tsc -noEmit`
Only if a project is pretty small.
Change in one place, especially if it's a reusable code, might ruin code in multiple different places and IDE will not recompile the whole project on every change, it will only watch your currently opened files and, maybe, some files in opened folders.
Did you reply to the wrong comment ? The --noEmit does not have the issue you talk about.
yes, sorry
By "supporting typescript" it parses typescript code and won't fail. That is what a bundler promises. Bundler doesn't have to do the typechecking. It is actually conventional to set it up that way for any bundler. In my job we have webpack bundling typescript with babel in the "build" step. We could've use ts-loader but we want hot reload to be fast. Then in the "check" step we have ts, linter, unit tests. Those run on CI.
You're likely literally doing the same thing with Webpack. There is only one complete implementation of the TS compiler in existence, so you have to use that to typecheck, it doesn't matter what bundler tool is used. If you need the type definitions as part of the output (eg you are distributing a library), then you have to involve the compiler to construct the output definition files, but for the code itself, it doesn't really matter because you're just generating JS. The TS compiler is very slow (and in any case is not designed to produce code bundles - it just dumbly translates all the TS to JS), so the standard way to speed this up is to use a module bundling tool that ignores the types and compiles the code as JS, and have the TS compiler set to not emit any files itself.
Nothing in the above precludes using the compiler to typecheck the code, that's the primary usecase & what sibling is saying about thinking of it as a linter: if typechecking fails, don't build
Nothing in the above precludes using the compiler to typecheck the code, that's the primary usecase & what sibling is saying about thinking of it as a linter: if typechecking fails, don't build
`eslint && tsc --noEmit && esbuild` or something like that, just simple process chaining. Means you can build something you know is going to be illegal to the TypeScript compiler, but you want to very quickly test an assumption, for example.
Great job on the landing page — that simple animation tells an incredibly simple and compelling story all in 800x200 pixels.
I wish more products had landing pages that looked like that.
I wish more products had landing pages that looked like that.
It is very easy to be misleading though: https://github.com/evanw/esbuild/issues/669
I don't think rejecting a comparison with an uncomplete nightly build is unfair. It looks like it was added a little after this issue was closed because the blocker was fixed.
Parcel 2 was released as stable yesterday though and Evan has already updated comparison.
https://github.com/evanw/esbuild/commit/186446eae8cc8c7439eb...
Parcel 2 was released as stable yesterday though and Evan has already updated comparison.
https://github.com/evanw/esbuild/commit/186446eae8cc8c7439eb...
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 and the build time went from 7 minutes on CI to 1 second. Kinda stupid really. Anyway, here's to the future, let's hope it works out this time!
I just switched to esbuild on our main project and the build time went from 7 minutes on CI to 1 second. Kinda stupid really. Anyway, here's to the future, let's hope it works out this time!
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 appreciate it's UX/DX.
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.
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.
You're right about the community being mostly dead.
There are a lot of bugs and performance issues in the underlying libraries, and Gulp's developers have not been able to get the upstream updates integrated.
I just redid our Grunt stuff in Gulp. It was painful - difficult to find up-to-date information, and the result was not that great. I expected a much greater SCSS compilation performance increase compared to FS-based tooling. Maybe I'm doing something wrong.
I'd switch to something like ESBuild and leave SCSS for dead, but it's not an option for me yet :(
I just redid our Grunt stuff in Gulp. It was painful - difficult to find up-to-date information, and the result was not that great. I expected a much greater SCSS compilation performance increase compared to FS-based tooling. Maybe I'm doing something wrong.
I'd switch to something like ESBuild and leave SCSS for dead, but it's not an option for me yet :(
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.
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.
I'm interested to know who you know spends 20% of their time on tooling issues... I use node, npm and webpack pretty regularly (albeit parcel has mostly replaced webpack for me) and other than setting up some npm scripts and a tsconfig to output the right js for my node version at the start of a project, I barely interact with them.
I think it's more like 80% of time at the start of any project, and then trickles down to no time, then up to 80% again when there's a new feature/config/incompatibility with tooling.
In larger projects and in orgs, you often have legacy choices that you have to deal with, that you can't remove or spend time replacing.
With all due respect, that measurement doesn't make a lot of sense! I spend 100% of my time waiting for my editor to open at the start of the day :)
>build time went from 7 minutes on CI to 1 second
I never jumped into that bandwagon and my build times are instantaneous using regular scripts ...
I never jumped into that bandwagon and my build times are instantaneous using regular scripts ...
5 if you include grunt.
6 if you include bash/make for using manual scripts to productionize your yui / jqueryUi / mooTools code with uglify/browserify/gcc/etc
6 if you include bash/make for using manual scripts to productionize your yui / jqueryUi / mooTools code with uglify/browserify/gcc/etc
Don't forget bun and swc
> 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?
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)
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)
Probably not an exaggeration. My build times aren't that long, but I've seen similar speedups in switching the esbuild (our smaller codebases currently build in less than 0.1 of a second with esbuild)
I have not done web development. Please forgive my ignorance. How is this different from Angular and React?
[deleted]
What I need is a similar speedup for my Typescript and eslint checks. Bundling isn’t my main issue.
> Bundling isn’t my main issue.
This.
Bundling, and even barreling, have pretty much been solved problems for a while. Right now I feel that unit test frameworks, linters, and type checkers are by far the main bottlenecks in the development workflow.
This.
Bundling, and even barreling, have pretty much been solved problems for a while. Right now I feel that unit test frameworks, linters, and type checkers are by far the main bottlenecks in the development workflow.
Yeah, Jest is the slowest thing in my build pipeline.
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.
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.
For our quite big JS codebase on React + typescript, we switched from Webpack to esbuild earlier this year.
It actually changed our daily lives !
The watch rebuild time went from 3-5s (actually a lot when you save your code very often) to something like .5-1 s
The full build time went from 120s to less than 5s
The watch rebuild time went from 3-5s (actually a lot when you save your code very often) to something like .5-1 s
The full build time went from 120s to less than 5s
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?
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?
Esbuild actually made writing frontend bearable for the first time in years. It alone reduced our iterative build times from 45 seconds to something like .5 seconds.
Are there any tools that transform HTML and other files? For example, lets say I have an <img> tag with a src attribute that points to a local image. Can I automatically replace that with a <picture> tag with various formats (jpg, webp, avif) and sizes?
I think Parcel[0] is what you want for that use-case.[1]
[0] https://parceljs.org/
[1] https://parceljs.org/recipes/image/
[0] https://parceljs.org/
[1] https://parceljs.org/recipes/image/
Rehype is an HTML processor with an ecosystem of plugins: https://github.com/rehypejs/rehype/
In ESBuild you’ll need a plugin for this. The plugin API is really simple but you’ll likely be gluing other tools together to achieve it.
SGML can transform HTML and all other forms of markup, though it's neither limited to that use, nor does it readily bundle image converters/compressors even though that sure has always been a plausible use case for SGML-based pipelines.
Check out PostHTML: https://github.com/posthtml/posthtml
Such a shame that Angular doesn't benefit from using such tools:
https://github.com/evanw/esbuild/issues/42#issuecomment-9339...
So I'm currently stuck with a build that takes minutes, even though in principle it should require only seconds.
https://github.com/evanw/esbuild/issues/42#issuecomment-9339...
So I'm currently stuck with a build that takes minutes, even though in principle it should require only seconds.
I switched to it on all of my personal (TypeScript) projects after upgrading to Phoenix 1.6 (where it is required). I normally have a separate lint step during production builds so its lack of type checking isn't an issue during development as VSCode catches and highlights type errors anyway.
It is crazy fast. It feels like the Turbo Pascal 3 of web development.
It is crazy fast. It feels like the Turbo Pascal 3 of web development.
I had ignored this space for a while as I didn't see any need to fiddle with it. But there does seem to be quite a lot of movement now on Webpack alternatives. The speed improvements do look very interesting, though I'm not so sure how much of the delays I'm seeing with Webpack/Create React App are from the Typescript checking. I mean Typescript is awesome, but it's also not all that fast in building and type checking.
Vite seems to be one of the more interesting CRA alternatives. Though it uses esbuild only for development, and Rollup for production builds. It'll be interesting to see how this develops, and if the fast bundlers keep catching up in terms of features without getting slower.
Vite seems to be one of the more interesting CRA alternatives. Though it uses esbuild only for development, and Rollup for production builds. It'll be interesting to see how this develops, and if the fast bundlers keep catching up in terms of features without getting slower.
I think vite is using esbuild only for TS transpiling in development and esbuild & rollup for production.
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.
Does esbuild support scss directly yet? I see on the site it mentions css. This is an important limitation for me.
I use the esbuild-sass-plugin[1] in my Phoenix 1.6 project, using the build script they give in the doc[2] and it works for me.
[1] https://github.com/glromeo/esbuild-sass-plugin
[2] https://hexdocs.pm/phoenix/asset_management.html#esbuild-plu...
Maybe it'll help someone, one difference from the plugin doc was using:
const { sassPlugin } = require("esbuild-sass-plugin");
Instead of:
import { sassPlugin } from "esbuild-sass-plugin";
After all, it would not be Javascript without some import syntax shenanigan ;)
[1] https://github.com/glromeo/esbuild-sass-plugin
[2] https://hexdocs.pm/phoenix/asset_management.html#esbuild-plu...
Maybe it'll help someone, one difference from the plugin doc was using:
const { sassPlugin } = require("esbuild-sass-plugin");
Instead of:
import { sassPlugin } from "esbuild-sass-plugin";
After all, it would not be Javascript without some import syntax shenanigan ;)
Same! I am struggling with SCSS tooling. SCSS/SASS itself even seems like it is in dire need of maintenance and direction.
Personally I'd rather not use it at this point, but it's not viable yet
Personally I'd rather not use it at this point, but it's not viable yet
That's old news or? For complex projects moving to esbuild from say Webpack is not necessarily easy.
For complex projects moving to esbuild from say Webpack is not necessarily easy.
Why would things be easy in a complex project? If you've built complexity into your project it seems a little unreasonable to expect someone else's tool to fix that for you. At some point you need to accept that building things that are simple is your own responsibility. But building things that are simple is incredibly hard so don't be too down on yourself if your project is complex. Software complexity is like entropy; it's very easy to add complexity to a system, and very hard to remove it.
It's also worth noting that you probably don't really want a tool to make your complex project appear more simple. That would only hide the complexity from you, but it would still be there. If your project is complex then your best approach to solving that is a lot of documentation, a lot of testing, and a lot of refactoring.
Why would things be easy in a complex project? If you've built complexity into your project it seems a little unreasonable to expect someone else's tool to fix that for you. At some point you need to accept that building things that are simple is your own responsibility. But building things that are simple is incredibly hard so don't be too down on yourself if your project is complex. Software complexity is like entropy; it's very easy to add complexity to a system, and very hard to remove it.
It's also worth noting that you probably don't really want a tool to make your complex project appear more simple. That would only hide the complexity from you, but it would still be there. If your project is complex then your best approach to solving that is a lot of documentation, a lot of testing, and a lot of refactoring.
its also surprisingly easy, much easier than you'd expect
see comparison with swc: https://swc.rs/docs/benchmark-transform
While useful, it should be noted TypeScript ≠ JavaScript and this build tool is for TypeScript. Many of us are using different compile-to-JS languages, or no language at all.
So swc is faster in almost all scenarios
It's not the same thing though, SWC is a different category of tool.
Edit: though I guess if you include the sibling project swcpack, it covers the same ground. SWC itself doesn't though.
Edit: though I guess if you include the sibling project swcpack, it covers the same ground. SWC itself doesn't though.
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. :-)
I am currently using Parcel 2, I like it because I don't have to bother with any configuration. From what I've seen, with esbuild you still have to fiddle with configurations and loaders for specific filetypes? Can I just give it an entry point and let it figure out everything (update production HTML file with bundle links, import external images, target last X browser versions, etc) ?
[deleted]
I've been actively moving all my projects from rollup to esbuild where possible. You have to do a bit more plumbing to get a lot of the niceties provided by the rollup/webpack ecosystem, but the resulting simplicity, speed, and size of esbuild make it worth it.
Isn't the browser also an extremely fast Javscript bundler?
How many scripts does a site need to make it feel faster when bundled?
When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so.
How many scripts does a site need to make it feel faster when bundled?
When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so.
> How many scripts does a site need to make it feel faster when bundled?
It's because people are using these huge frameworks with a lot of bloated code, it's too big, now devs are forced to do tree shaking and what not to trim the fat... front end JS development has become a madhouse of unnecessary complexity, because of node.js as well...
I hope that with the help of DENO that doesn't suffer from all that cargo culting, front-end development can become a healthier ecosystem...
Yes, some apps are complex, but 99% of front-end UI aren't.
It's because people are using these huge frameworks with a lot of bloated code, it's too big, now devs are forced to do tree shaking and what not to trim the fat... front end JS development has become a madhouse of unnecessary complexity, because of node.js as well...
I hope that with the help of DENO that doesn't suffer from all that cargo culting, front-end development can become a healthier ecosystem...
Yes, some apps are complex, but 99% of front-end UI aren't.
I just saw an (internal) presentation where presenter predicted that in a few coming months we will see a lot more RxJS being used in ReactJS projects. Cannot wait to see it included on webpages which would be just fine with zero JS.
What ESBuild offers over plain ESM is:
- fast TypeScript/JSX compile
- bundling shared code to reduce request waterfall/splitting to reduce redundancy
- bundle optimization (tree shaking/dead code elimination; minification is actually faster than not using it)
- a simple plugin system for use cases like other compiled frameworks like Vue or Svelte, or whatever else you might want in a build pipeline
- fast TypeScript/JSX compile
- bundling shared code to reduce request waterfall/splitting to reduce redundancy
- bundle optimization (tree shaking/dead code elimination; minification is actually faster than not using it)
- a simple plugin system for use cases like other compiled frameworks like Vue or Svelte, or whatever else you might want in a build pipeline
On the downside, it will put all the code into one giant script that has to be downloaded upfront.
While a website that loads scripts per page will only load the scripts that are needed on the current page.
While a website that loads scripts per page will only load the scripts that are needed on the current page.
Unless your site is made of 4 files/modules, you simply must bundle. ESM will download the files in series, as each dependency is discovered. Then compression doesn’t work as well as it will be per-file. Then of course you can’t tree-shake dependencies from npm, so good luck downloading the whole of lodash on your client.
In short you lose the advantages of only download what you need pretty quickly.
In short you lose the advantages of only download what you need pretty quickly.
> good luck downloading the whole of lodash on your client
I never felt the need to use loadash. But even if a site would do that, it does not seem like a big issue. It is 71k. A Twitter profile page is over 5MB. 70 times the size of that loadash library. An appartment page on AirBnB is over 9MB. An Instagram profile page is over 9MB too.
I never felt the need to use loadash. But even if a site would do that, it does not seem like a big issue. It is 71k. A Twitter profile page is over 5MB. 70 times the size of that loadash library. An appartment page on AirBnB is over 9MB. An Instagram profile page is over 9MB too.
ESBuild does support code splitting, in case you weren’t aware.
I like Snowpack (https://www.snowpack.dev) because it doesn't actually do any bundling, it just makes sure that the files are in the right place to be loaded (it does compile Typescript files). Because the only thing I actually care about during development is that all the inter-package dependencies are resolved. I don't actually need a fat heap of JS that needs to be rebuilt every time I change something.
Yes, that's why ES modules and import maps are a thing. For example Deno uses them, and they're the new default on Rails 7.
> How many scripts does a site need to make it feel faster when bundled?
Depends on what you're building. If you have many nested dependencies, you need to bundle them, and not rely on the browser to resolve them at runtime and do dozens of roundtrips to the server to fetch them.
Depends on what you're building. If you have many nested dependencies, you need to bundle them, and not rely on the browser to resolve them at runtime and do dozens of roundtrips to the server to fetch them.
That contradicts my experience and what I just described. In my experience, sites do feel instant even if they load dozens of scripts.
If your dozens of scripts are top-level (on the html itself) then you can fetch all of them in parallel — so you wait your connection speed roughly twice (roundtripped).
If they’re nested dependencies (where you don’t identify the next necessary js until you have the first one in hand), the dependency won’t start getting fetched until the predecessor is retrieved. So you wait your connection speed multiplied by depth (x2; roundtripped)
The goal of the bundler is to take the second scenario and turn it into the first scenario.
If they’re nested dependencies (where you don’t identify the next necessary js until you have the first one in hand), the dependency won’t start getting fetched until the predecessor is retrieved. So you wait your connection speed multiplied by depth (x2; roundtripped)
The goal of the bundler is to take the second scenario and turn it into the first scenario.
If they are not waterfalling then yeah. But when a depends on b and b depends on c you will be fetching those serially.
The bundler will have those preprocessed and bundled together.
The bundler will have those preprocessed and bundled together.
There will definitely be an inflection point, and it's very dependent on many factors: number and size of scripts, how much of the initial content is SSRed, network bandwidth and latency etc.
Browsers are good at caching JavaScript files, so it depends if the scripts are already cached or not.
I thought HTTP 2 fixed the problem of multiple downloads of small files/dependencies?
The creator of Rails talks about it here: https://world.hey.com/dhh/modern-web-apps-without-javascript...
The creator of Rails talks about it here: https://world.hey.com/dhh/modern-web-apps-without-javascript...
Khan Academy did a great writeup on their experience (including thoughts about HTTP/2) with various strategies for serving JS, such as:
- Single bundle
- No bundles (all separate files)
- Hybrid
https://blog.khanacademy.org/forgo-js-packaging-not-so-fast/
- Single bundle
- No bundles (all separate files)
- Hybrid
https://blog.khanacademy.org/forgo-js-packaging-not-so-fast/
You can use the Network tab of your preferred browser to see the waterfall. HTTP2 did improve a lot, but it can’t magically resolve N-deep transitive imports without additional information. It was originally designed to have that information provided at the server level, but HTTP Push has been dead for a while. There are physical limitations at work, optimizing requests on the wire is still important.
> When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so
Then they'll be faster doing only one request, this is regardless of ssr or spa
Bundling also gives you slatic analysis (typescript and linting), and frees developers from developing in the dark, like keeping track in their brain what component in what script exposes what global.
Then they'll be faster doing only one request, this is regardless of ssr or spa
Bundling also gives you slatic analysis (typescript and linting), and frees developers from developing in the dark, like keeping track in their brain what component in what script exposes what global.
> Bundling also gives you slatic analysis (typescript and linting),
No it doesn't do that, typescript compiler does the static analysis and whatever linter does the linting, you don't need a bundler for that, a bundler just takes many source files and bundles them into one.
No it doesn't do that, typescript compiler does the static analysis and whatever linter does the linting, you don't need a bundler for that, a bundler just takes many source files and bundles them into one.
Although esbuild has been out for a while now, I think it's relevant today because the benchmarks have been updated to include Parcel 2, which was just released earlier today.
Both Rails 7 and Phoenix 1.6 is going off Webpack by default and I am so looking into the esbuild future. I never really liked Webpack to be honest.
I already replaced Webpack in my Phoenix project (you can compare default steps for building a release here https://nts.strzibny.name/12factor-elixir-phoenix-releases/) and cannot wait to do the same in Rails.
I already replaced Webpack in my Phoenix project (you can compare default steps for building a release here https://nts.strzibny.name/12factor-elixir-phoenix-releases/) and cannot wait to do the same in Rails.
Deno is using this: https://github.com/swc-project/swc
How does esbuild compare to Bun, snowpack, Vite, and any other JS bundles? In performance, reliability, and extra features?
Snowpack uses esbuild under the hood:
"Snowpack already uses esbuild internally as our default single-file builder for JavaScript, TypeScript and JSX files."
https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0#built...
"Snowpack already uses esbuild internally as our default single-file builder for JavaScript, TypeScript and JSX files."
https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0#built...
What’s the catch? Do they really have a secret sauce or are there limitations in esbuild to achieve these speed ups?
Some section titles from the FAQ[1]:
> Why is esbuild fast? > - It's written in Go and compiles to native code. > - Parallelism is used heavily. > - Everything in esbuild is written from scratch. > - Memory is used efficiently.
> Production readiness > - Used by other projects > - API stability > - Only one main developer > - Not always open to scope expansion
1: https://esbuild.github.io/faq/
> Why is esbuild fast? > - It's written in Go and compiles to native code. > - Parallelism is used heavily. > - Everything in esbuild is written from scratch. > - Memory is used efficiently.
> Production readiness > - Used by other projects > - API stability > - Only one main developer > - Not always open to scope expansion
1: https://esbuild.github.io/faq/
Well not being written in JS does help -a lot-.
Esbuild is written in GO.
Esbuild is written in GO.
I'm sure it helps. It doesn't help 100x
It helps to get 80% of the way there, on a logarithmic scale. The remaining 20% is evanw saying no to adding any kind of option, feature and the kitchen sink to this project, which is one of the reason Webpack/Babel & co. are some of the heaviest objects in the universe.
[deleted]
It doesn't always work in situations where 'require' can't be statically evaluated at run-time (webpack would work in this situation) - for example I filed a bug recently[0]
Even though the bug was closed I was impressed with the thorough and timely response from the esbuild developers which explained the reasoning behind it. For me it was worth changing my project just so I could continue using esbuild, it really is that good!
[0]: https://github.com/evanw/esbuild/issues/1619
[0]: https://github.com/evanw/esbuild/issues/1619
The catch is that they focus on modern builds (I.e. not IE) it also doesn’t do type definitions, so if you want type defs you’ll need to compile with typescript anyway.
The catch is the person behind it cares about performance
esbuild is a pleasure to use. Because of its speed you no longer need to separate test/release build for simple libraries. I am using esbuild for transpiling my new TypeScript projects.
However, I am still have to use TSC to generate declaration files(dts). Are anyone aware of esbuold-like tool to do that job?
However, I am still have to use TSC to generate declaration files(dts). Are anyone aware of esbuold-like tool to do that job?
I am using ParcelJS v2 (nightly), and my builds are really fast for a medium-sized project. It takes about 5s from scratch (no-cache) and <500ms to update after a change.
Do I recommend Parcel? Not sure, it feels like every time I update the package something breaks (in their defense, it is still in Beta).
Do I recommend Parcel? Not sure, it feels like every time I update the package something breaks (in their defense, it is still in Beta).
I have to note that the project is a TypeScript project.
Well, I spent few days to move large vue.js codebase from webpack 4 to Vite (esbuild). You know what? It isn’t as fast as that benchmarks shows us, even buggy and laggy.
So upgraded to webpack 5 with caching to filesystem (I bet no one know) and it became even faster than Vite! I’m happy.
You knew how to speed up webpack 5-10 times by setting cache.type = 'filesystem', right?
> Both Go and JavaScript have parallel garbage collectors, but Go's heap is shared between all threads while JavaScript has a separate heap per JavaScript thread.
It actually implies that JS GC can be faster because it doesn’t require global locks and can collect garbage in parallel.
It actually implies that JS GC can be faster because it doesn’t require global locks and can collect garbage in parallel.
Personally 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.
I do have some complicated Webpack setups that I don't think can be solved with any other bundler.
It stings being in webpack and there isn't much I can do about it in my current situation
How is it possible to be so fast?
Answered in the FAQ:
Why is esbuild fast? https://esbuild.github.io/faq/#why-is-esbuild-fast
- It's written in Go and compiles to native code
- Parallelism is used heavily
- Written from scratch with performance as a goal
- Efficient use of memory
Why is esbuild fast? https://esbuild.github.io/faq/#why-is-esbuild-fast
- It's written in Go and compiles to native code
- Parallelism is used heavily
- Written from scratch with performance as a goal
- Efficient use of memory
It also doesn't include type checking for typescript. It just transpiles sources to javascript
> It also doesn't include type checking for typescript.
If you use `@aws/sdk`, you are going to have bad time with Typescript. Resolving its types can easily take >50% of compilation time for small projects.
If you use `@aws/sdk`, you are going to have bad time with Typescript. Resolving its types can easily take >50% of compilation time for small projects.
1. It does a few things and does them really well (not taking on the complexity of ie Webpack)
2. It’s written in Go
2. It’s written in Go
esbuild is awesome! The level of detail in the release notes [1] always impresses me.
[1] https://github.com/evanw/esbuild/releases
[1] https://github.com/evanw/esbuild/releases
Is this the only popular JS build tool written in something other than JavaScript
SWC, Bun are other examples. And I'm sure there are even more
So is esbuild vs parcel a bit of an accidental proxy battle between go and rust?
I've used it for a TypeScript project and it just worked.
A bit like Parcel, but faster.
A bit like Parcel, but faster.
also kudos to the esbuild team to have an official mention of deno usage and support. it works great and turned out to be much simpler, flexible and reliable than the current Deno.emit .
Yep, moved from webpack to esbuild + postcss. Great results.
has anyone used this in react-native ?
Pretty sure the Expo folks are working on this!
ah - apparently ESBuild cannot be used for transpilation in React Native. But can be used for minification.
https://www.npmjs.com/package/metro-minify-esbuild
https://www.npmjs.com/package/metro-minify-esbuild
Looks awesome! I'm gonna use it!
Anyone able to compare this to Vite?
Vite uses Esbuild for development builds, and they have an answer for why they don't use it for prod builds here https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
Vite uses esbuild I think. But the concepts are different.
from my PoV Vite.js is much more mature project than esbuild
What do you think of the importmap approach propagated by dhh on rails 7?
I'm using it right now, it's fantastic. Also been playing around with Deno, importmaps are also used there, it's so much nicer than the bundle and compile everything workflow. It's the direction everyone should be going since it actually uses the browser and browser standards to their potential.
Also if people don't want to use CDNs both Rails and Deno do allow you to serve ES modules from your server.
Also if people don't want to use CDNs both Rails and Deno do allow you to serve ES modules from your server.
I think it’s a fantastic default. I’d argue most server rendered applications can get away with it. And if you ever need ESBuild you can install the js-bundling gem or pass “-j esbuild” for new Rails 7 apps.
the only problem with this is that it's an option.
As a rails dev, I want one, strong opinion on what the default/best approach is. I don't want to configure anything
As a rails dev, I want one, strong opinion on what the default/best approach is. I don't want to configure anything
No importmaps are the new default in Rails 7.
The menu is still omakase. In case you have different requirements you can use options.
salu2
I must say that this got to be a new standard. Es build is what we need. Great thing. Huge thanks to creators!
I would rather use Parcel.
what is the point of the comment? It reads: I have an opinion (and here it is, but who gives a shit if you don't elaborate)
I don't think context (JS build tool) is missing here.
If someone has open mind, they can also google what is Parcel.
If someone has open mind, they can also google what is Parcel.
“What is” is a vague question with no clear details in the answer. For example, parcel may have the middleware mode while esbuild may not. But then it’s parcel 1, but not 2, where it was removed to streamline plug-in development, so I better stick with 1 for a while. That is the context. By not providing it, the root comment has zero value, because an interested reader cannot learn at least some of the whys by simply reading the frontpage. Almost everyone knows it and thus will not follow your “open mindness” advice, because it’s pointless in this case.
Most people who care to read the comments to a post about esbuild will know what Parcel is. Why do you prefer it?
On another thread were I said I don't like build tools/compilers in the same language as they work on, when the language is slow, I got voted down.
Here everyone: JS build tool in Go? Great!
+1 for parallelism of esbuild. I have a12 core machine and many tools either use one core or when forced to not benefit from more cores.
I also wish they would waste more memory, I have 32gb which re mostly unused even by large projects.
I stand by my opinion: dev tools should make it pleasant for developers not the tool writers.
Here everyone: JS build tool in Go? Great!
+1 for parallelism of esbuild. I have a12 core machine and many tools either use one core or when forced to not benefit from more cores.
I also wish they would waste more memory, I have 32gb which re mostly unused even by large projects.
I stand by my opinion: dev tools should make it pleasant for developers not the tool writers.
Yet another one of these...
I'm sorry, but the node.js community needs to stop producing these stuff... it doesn't do anything better than all the webpack vs gulp vs parcel vs snowpack vs rollup vs how many bundlers again?
I'm sorry, but the node.js community needs to stop producing these stuff... it doesn't do anything better than all the webpack vs gulp vs parcel vs snowpack vs rollup vs how many bundlers again?
I recently switched to esbuild and I am delighed. My build time dropped from 30s to 2s and I was able to remove a lot of dependencies. So IMHO they need to continue producing these stuff to push the innovation forward.
I agree with you in principle, but your comment makes it clear that you didn't actually look into this one at all. This one is actually good.
> I agree with you in principle, but your comment makes it clear that you didn't actually look into this one at all. This one is actually good.
People have said say that same thing each time a new one pops up since Grunt 10 years+ ago.
If you're going to use a JS bundler written in Go, just stick to MAKEFILE...
People have said say that same thing each time a new one pops up since Grunt 10 years+ ago.
If you're going to use a JS bundler written in Go, just stick to MAKEFILE...
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 plugins, ask yourself whether you really need to inline css in jsx in png while simultaneously optimizing it for IE 4.0, realize you don't, through out the whole thing, and use esbuild instead.
I have two 50K+ LOC projects using esbuild, and I would use it even if it was slower than webpack/babel/tsc simply not to worry about the build chain breaking due to an update to some obscure dependency or plugin.
2. It is fast because it's written from scratch to do a set of particular things and do it fast, not just because it's Go and parallelized.
If you look at the commit log you will notice a lot of performance tweaks. If you look into the issues, you will find a lot of requests for additional features rejected, often due to possible negative performance impact.
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.
The release notes alone are a good course into nitty-gritty details of the web ecosystem: all the addressed edge cases are explained in detail. To top it all off--all opened issues, no matter how uninformed they seem, find a courteous response.