Get the top HN stories in your inbox every day.
maga
theptip
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.
brundolf
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
dgritsko
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.
theptip
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.)
eyelidlessness
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
spartanatreyu
"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.
imbnwa
> 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.
Epskampie
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.
josteink
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.
tengbretson
> 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.
shakezula
The Convention Over Configuration crowd has their arguments.
praveenperera
> 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!
btown
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!
brailsafe
He seems to like writing code
chipsambos
Ironically, the Figma tagline is "Nothing great is made alone"
Cyph0n
What in the world? And some say 10x engineers don’t exist…
sesm
I guess build times were a real issue for Figma and it started as an internal project.
_fat_santa
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.
kyawzazaw
Massively impressive!
lawn
> 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!
brightball
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.
sesm
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.
acemarke
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...
undefined
baxuz
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.
brainbag
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.
Aeolun
> 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.
hashkb
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.
magerleagues
This looks promising: https://github.com/pradel/create-react-app-esbuild
hashkb
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.
antihero
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.
Rapzid
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.
maga
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.
aidos
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 :-)
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' },
]
},
})seumars
God bless Evan Wallace
CodeIsTheEnd
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.
eloff
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.
mr_pinnen
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.
capableweb
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.
DrBazza
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.
atonse
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.
depr
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'.
moron4hire
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.
BiteCode_dev
Sure, like anyone can be Usain Bolt if they are familiar with their body and has a deep understanding of running.
cj
> 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)
leetrout
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.
ksec
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.
Scarbutt
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.
marton78
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.
hn_throwaway_99
> 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.
winrid
and he's building tools to optimize his teams.
ZephyrBlu
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.
zeroxfe
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.)
betageek
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.
ZephyrBlu
So working a shit ton then.
atonse
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.
xal
Same
pixelrevision
The tool is likely helping Figma pretty directly by cutting developer build times.
Aeolun
Sounds like he solved his own problem?
todotask
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.
ksec
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
chakkepolja
The numbers seem cherry picked though, I don't like this type of 197.96432100004x faster claims.
eyelidlessness
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.
beckler
Granted, those stats are for JSX, but it’ll be interesting to check out for sure.
imjared
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.
oliyoung
> 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
louissm_it
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
d3nj4l
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.
louissm_it
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 :)
deergomoo
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.
dorianmariefr
You can use esbuild to your existing rails apps via the gem jsbundling-rails https://github.com/rails/jsbundling-rails
It works really well
qwertox
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.
jamra
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.
dom111
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.
baybal2
Webpack is a bane of webdev existence.
Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself
ksec
>Webpack is a bane of webdev existence.
Modern Web Dev is the cause of Webpack though. Over complicated things.
enjikaka
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!
intruder
what are you talking about, webpack has nothing to do with Facebook or React.
kureikain
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.
Sheepsteak
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.
rwieruch
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/
pineconewarrior
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?
kureikain
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
pineconewarrior
Thank you so much for sharing!
I'll give this a shot really quick
eyelidlessness
3. You can inject anything you want without a plugin with `inject`.
4. You can just use `target: node` (or node12, node14.6, etc)
satvikpendem
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.
o_m
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.
crubier
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 !
alfonsodev
could you provide a link on how to enable this experimental setting ? thank you.
forsakenharmony
It's being using to bundle some parts of nextjs itself, but not quite ready to replace babel for users rn afaik
cute_boi
May be in next release we get swc in nextjs?
phillu
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.
tiew9Vii
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.
Vinnl
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.
chrisjc
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?
EugeneOZ
It's not a linter, far from it.
acid__
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.
lstamour
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.
kitd
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
`tsc -noEmit`
EugeneOZ
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.
nsonha
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.
RobertKerans
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
dkdbejwi383
`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.
petethepig
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.
gyosko
It is very easy to be misleading though: https://github.com/evanw/esbuild/issues/669
iruoy
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...
swhitf
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!
have_faith
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.
whoisthemachine
I felt the same, the industry's shift away from the gulp way of doing things was a real loss.
horsawlarway
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.
jacobsenscott
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.
btbuildem
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.
h0h0h0h0111
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.
moralestapia
>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 ...
ep103
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
alvarlagerlof
Don't forget bun and swc
koolba
> 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?
horsawlarway
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)
nicoburns
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)
hi41
I have not done web development. Please forgive my ignorance. How is this different from Angular and React?
undefined
Get the top HN stories in your inbox every day.
Often overlooked things when discussing esbuild here:
1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right.
That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of 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.