Esbuild 0.9 | Hacker News Reader

Esbuild 0.9

github.com

254 pointsswyx116 comments

esbuild has flipped the JS community on its head. Not only as an impressive JS bundler, but through all the next gen tooling esbuild is powering.

For example, you can now speed up your Webpack build with esbuild by replacing babel-loader/ts-loader/Terser: https://github.com/privatenumber/esbuild-loader

(It also blows my mind that Evan is the CTO is Figma. How is he so productive!?)

i said on twitter that esbuild is the best possible ad for working for figma that they could have ever done. (if this is what they do for fun... imagine what they do at work, etc).

arguably he's doing his job just working on this thing all by himself

> (It also blows my mind that Evan is the CTO is Figma. How is he so productive!?)

When Evan first joined Figma, he saw how much time the engineers spent on waiting for webpack and fighting JS configuration files. Then one time, during an outage, the developers tried to push a fix but the build was failing because babel-deduplicate-int had changed their API interface but only did a minor version bump when published to NPM, and Figma engineers are at the edge of technology so they use version ranges, not fixed versions.

When Evan heard this he pored up some whisky and created esbuild in two nights. And the JS developers rejoiced. Now the developers were so productive, that Evan already had nothing to do. No one was fighting, all engineers were happy and playing ping-pong like any everyday was Friday.

So now the only thing keeping all the JS engineers happy at Figma, is the continued success and improvement of esbuild. So Evan just spends his time with esbuild now.

(This is all fictional, of course)

Yeah that's a red flag "all work stops while executive does x then all processes must change to revolve around x"

It worked out ok for linux and git.

> (This is all fictional, of course)

Haha, you really had me going with that first paragraph. Felt so real.

Is this pretty much a drop in replacement for babel-loader or does it lack certain features?

Edit: Kind of. It was really simple to switch over and build. But the optimizer example actually makes my output much larger than the webpack default settings. Also it can't seem to handle the "implicitly assume I have React in scope for each JSX file."

It felt maybe twice as fast, but not 10-100x to really game change my dev loop.

We switched two weeks ago and the drop was a bit more than half the total time we had with Webpack in development and a bit bigger drop in production builds.

Our bundle got noticeably smaller, but we chalked that up to esbuild not polyfilling for as early a target as we had been with babel-loader.

Hell yes, esbuild is an amazing tool. I not only use it in most CRA projects (where it replaces webpack and builds everything at least two times faster), but it's also easy to use for plain HTML pages to add some interactivity without writing thousands of lines of webpack black magic:

  esbuild App.tsx --define:process.env.NODE_ENV=\\\"production\\\" --bundle --minify --target=es6 --outfile=out.js

where App.tsx is your entry point. Include out.js into the page and you're done.

This is exceptional - what’s the downside when using it with CRA?

do you have instructions for integrating with cra

Unfortunately it's not officially supported (as usual in CRA world), so you have to resort to one of the config rewriters. I've been using this⁰ and only had one problem with numeric enums in TypeScript. I don't remember the exact issue, but it was caused by my own stupidity, and was easy to fix.

[0] https://github.com/pradel/create-react-app-esbuild/tree/main...

esbuild can be a good alternative to Webpack in some cases, but Webpack solves a lot of edge cases well. For example, just today I debugged an issue where a library had used `require` in an ES module instead of `import`, and that broke the build with esbuild. So I had to fork the library to fix that issue. Webpack handles that case without problems.

I can think of at least a few cases like that where Webpack works better, but esbuild is (hopefully) going to catch up. It'd be ideal if Webpack and other bundler tools ditched their homegrown build tools and replaced them with esbuild.

> Webpack solves a lot of edge cases well

I would quibble with the word "solves". Webpack is a tool building tool. With Webpack, you can build a tool to solve your edge case problem, as long as you're willing to spend a lot of time and dig through random Github issues for your dependencies. Webpack itself however does basically nothing.

> Webpack itself however does basically nothing

This is not the case. I love esbuild and hope to see it go far, but Webpack does out of the box most of what esbuild (today) does as well, with the notable exception of TypeScript /jsx transpilation. For more advanced scenarios, like dealing with css modules, you do need plugins -- but esbuild doesn't support most of these scenarios today at all.

It's like saying VS Code does nothing: you probably want extensions to help you out and let you do more complex things more easily, but it doesn't "do nothing" out of the box.

"webpack does basically nothing"

https://bundlers.tooling.report/

webpack: 43.5/48

rollup: 40.5/48

parcel: 31.5/48

That website is a complete waste of time. Noting that Webpack can do something is like noting that JavaScript can do something. Yeah, sure, but unless you show me the actual code, the knowledge that JS could do it useless to me.

Let's be concrete. How do I do dynamic imports in Webpack?

> Webpack was one of the first bundlers to use Dynamic Imports as a signal for creating code-splitting boundaries.

> Unlike multiple entries, split points created using Dynamic Imports consistently result in a separate bundle being created without customizing optimization.splitChunks.

Okay, but what does that mean? How do I make it work? What are the actual configuration settings? The site gives you no clues.

All right, let's go to https://webpack.js.org/guides/code-splitting/#dynamic-import... and read the docs.

Haha, okay, yes "Webpack" can totally do dynamic imports. All you have to do is read 50 pages of confusing docs first and craft a perfect config file. If you're familiar with Webpack, it shouldn't take more than 1 or 2 hours (my serious, no joking estimate).

Or you could use a bundler tool instead of a bundler tool tool.

I switched my pet project (about 15000 lines of code) from Webpack to esbuild, and reduced the build time from 30 seconds to 2 seconds.

The trickiest part was to make Tailwind CSS work. I used to do that via postcss plugin, but just running that plugin even without Webpack takes 15 seconds. Finally, with some modifications in my CSS I made it work, and purged the unused styles just by using PurgeCSS API manually.

The setup got a bit hairier than with Webpack, but it builds damn fast now.

I believe the Tailwind team are currently working on addressing the performance issues. The project lead was recently tweeting about the new approach [0]; instead of building a huge CSS file and stripping out the unused classes, the new version will only generate the used classes to begin with.

[0] https://twitter.com/adamwathan/status/1366514152517337089

Mind sharing some details? I've been working on this myself and I don't have much JS ecosystem experience. I found the same issue around using tailwindcss as a postcss plugin (it basically tripled my build time), so would love to hear alternative solutions.

As soon as esbuild gets react hot reloading capabilities I’m jumping ship. Although that might be out of scope and there is Vite. I’m hoping to avoid vite and go pure esbuild. Fantastic tool. It will make JavaScript distribution a much more pleasant experience across the board when it gets wider adoption.

Think that's out of scope - doesn't snowpack (which uses esbuild) cover this though? https://www.snowpack.dev/

Snowpack uses ESM for development which allows really fast HMR. And ESBuild is used for production builds. Best of both worlds.

He said in the past that he's not interested in implementing HMR[0]

[0] https://github.com/evanw/esbuild/issues/97

Makes logical sense from a library/unixy perspective. They offered similar reasoning for not including a file watcher at first but they eventually added that.

HMR is pretty much the last missing piece to make this the only JS bundling and dev tool you need. It would be a bad decision to omit it.

Check out tools like vite or snowpack, which use esbuild internally. They're the HMR developer experience you're looking for.

I'm actually very happy that esbuild doesnt have HMR by default. Despite the fact that most frontend devs loving/hyping HMR, I prefer live-reloads more because it refetches data/makes network calls and run my route hooks without any additional step. This is particularly important when you run your application tests in the browser(thats better than running app tests in CI btw) and change these test files constantly. The fact that most frontend devs favor HMR over live-reload signals something that I really dislike.

I’ve been a f/e dev for around a decade and I don’t trust HMR. I end up refreshing manually anyway just so I know I’m not seeing issues that don’t exist due to event bindings not refreshing properly, or app state getting messed up between loads. It’s fine for styling, but worries me when there’s too much complexity involved

That and the fact that unless you have two monitors often as you save the refresh happens out of view, when you’re not seeing the page, so you lose the immediate visual feedback of what actually changes. When you make minute touches to a design it’s annoying. When I hit F5 myself I can look at exactly what I’m interested and see if it shifted some pixels, if the font size is a bit better or worse...

> unless you have two monitors

Or have your editor and browser window tiled next to each other? Given how often FE development dabbles with design, using at least one decently sized monitor seems requisite.

And aren't FEers generally tweaking design in the DOM via a browser's developer tools when they're not sure what they want yet, copying back over into source once the design is finalized? Seems downright unpleasant to modify styling in the way you've described, and odd given there's a fantastic IDE in every major browser for styling exploration.

It's often much faster to make the change in the code directly than in the dev tools. For instance, I can very quickly apply a LESS mixin to an element, which would require knowing and making those specific changes to the raw CSS via the browser. The same goes for pretty much anything that's more than a one-value change.

Yes, I agree for what you’re describing, but that’s not the scenario I was referring to: the one where you don’t know how far over, how tall, how opaque, etc something should be and there’s no existing pattern to reach for off-the-shelf, like a mixin. Iterative exploration of design space.

IIRC, HMR in webpack has an issue when you add/remove/possibly reorder imports in JS; the imports are cached in memory by their index (or something like this), so when you remove a fifth import, suddenly the previously-sixth import statement will refer to the wrong module after HMR.

Took me a good while to understand the issue is with HMR and not my code. I restart the dev server many times a day just to be sure or when things inevitably explode.

Agree I hope Vite has a way to easily turn it off. Never understood the appeal. Way more fun to "see" what you’re going for in your mind and write more at once and see what happens, then react compulsively to a tight feedback loop. I think these features sometimes don’t make us better developers. I’m sure it has some good uses, personally never needed it.

You bring up a good point. Wondering if there can be some way to have both side by side. When I’m working on markup or css I definitely want HMR. But when I’m in the script section I’ve run into issues where I needed to reload the page.

> some way to have both side by side

Yes, just hook up to the reloading event of HMR on the client-side and call `window.location.reload()` when that happens, now you have traditional "live reload".

We now use it to build Yarn, and it's been working very well. Still some rough edges that prevent us from adopting it at work (like the lack of dynamic imports when the import expression references variables), but I'm slowly making progress in implementing workarounds for that through loaders, and the first results are encouraging. At its worst, with a Webpack/Esbuild hybrid approach, we get at least 2x better perfs.

ESbuild is excellent for using with TypeScript and Node.js. We were previously using Nodemon to restart the server on changes. ESbuild is fast enough that rather than having to change our workflow and run a tsc --watch process in addition to Nodemon (which would be rather a pain given that we have 5-6 microservices), we simply use ESbuild to recompile the entire service before restarting the code (it takes about 0.1 seconds to compile everything, so it effectively doesn't impact our workflow at all).

Amazing stuff, I was thinking of doing pretty much exactly this this morning.

Out of interest, if you’re bundling with Esbuild before running, how do you cope with native dependencies?

We don't use esbuild's "bundle" (--bundle) option, which means that our files get processed one-by-one and end up as separate files in the `dist` directory that we output to and that dependencies aren't processed at all and are just `required` like normal by our transpiled code.

Our build command (in a bash script file to avoid string escaping issues) is:

    find src -type f \( -name '*.js' -o -name '*.ts' -o -name '*.sql' \) -print0 \
      | xargs -0 ./node_modules/.bin/esbuild --platform=node --format=cjs --outdir=dist --loader:.sql=text

Thanks for sharing, I’ve just given it a go with one of my larger projects and WOW!! Typescript incremental compilation was taking around 2 seconds on every save, then Nodemon would restart etc.

I’ve plugged in Esbuild, I have used bundle mode though to see what it’s like, it works fine if I external all of my node modules, it builds in 0.23 seconds (approx 350 source files in my project).

Nodemon now watches for TS file changes and exec’s the esbuild on every start.

Thank you for the pointer to this as this will be a much needed productivity boost!

I’ll try bundling some node modules when I have some time but it will take more work as I use Yarn PnP (I’ve found a plug-in so will definitely try that)

You can instruct nodemon to run "tsc" by itself when there are file changes, so you don't have to separately run tsc in watch mode.

Yes, but tsc is super-slow if you don't use watch mode (and to be honest even if you do). The advantage of using esbuild is that it doesn't slow down the edit-test workflow.

esbuild makes it pretty clear that writing the JS ecosystem in JS is a bad choice*.

now we need to rewrite tsc/babel/npm/eslint/etc... in a language that compile down to native binary that is also cross platform (like go or rust),

to gain the same performance improvements across the entire JS tool-chain.

* based on the benchmark on their landing page.

I think this comment undervalues the quality of engineering that Evan has put into esbuild. It’s not only quick because it’s written in golang, but also due to the decisions taken in architecture and an opinionated tool that does mainly one thing well.

I don’t read OP as devaluing Evan’s work. Presumably the TypeScript/Webpack/etc teams are also doing great engineering work — but because they’re writing in JS, the performance ceiling is significantly lower.

I don’t know about that. Just look at the performance difference between NPM and Yarn: both built with JS, but for me at least Yarn is way, way faster.

I’m sure it would make sense to rewrite certain things in Rust or Go (then possibly pull them into Node as native modules) but they’re not magic. Good engineering will win out no matter what.

Good engineering is definitely key, but I think interpreted languages are a bad fit for developer tools (though they are extremely popular for writing developer tools). On the surface, writing JS tools in JS is good because hey, you definitely know JS, right? But in practice it is bad because I don't want the JS I am writing in any way constrained by the JS you wrote.

The problem with any interpreted language is that to run the tool you need all the source and all the dependencies plus the interpreter in something like their intended versions to be present in the right locations on disk. This is a huge PITA, and if you're say writing JavaScript targeting ES5 but your tools are targeting ES2020 or vice versa, there can be painful yak shaving sessions getting everything on the same page.

Essentially all developer tools should be static binaries.

Would I be right in guessing that most of your experience with dynamic languages comes from Python?

1) Modern JITed JS is fast. It's closer to Java than it is to what we typically think of as "interpreted languages".

2) "something like their intended versions to be present in the right locations on disk"; Node packages really just depend on the user having a new-enough install of Node and NPM, somewhere in the path. Any dependencies that live on npm will install to the local directory to ensure against conflicts or permissions issues. The only exception I can think of is that occasionally (looking at you, node-sass) npm dependencies will have to do a native build of something and require a local C/++ compiler somewhere in the path. This is pretty rare in my experience, and isn't a super brittle dependency anyway.

3) "if you're say writing JavaScript targeting ES5 but your tools are targeting ES2020 or vice versa, there can be painful yak shaving sessions getting everything on the same page"; this really doesn't happen in any distributed NPM dependencies I've worked with. The great majority are written for the least-common-denominator of environments; if they use ES2020 internally, they'll do their own transpilation step to make sure you can use them in older environments. Also, "or vice versa" really doesn't apply because all ES versions are 100% backwards-compatible. You just need a Node version new enough to cover the newest features that any of your code or dependencies is using. Dependencies will be as compatible as they can be; your own code is under your control. Virtually never an issue.

1. My complaint is not about speed.

2. Node is much better than Python because the correct location on disk is pretty much project/node_modules. However, it is still that case that e.g. Babel was broken by Node 12.17.0 [1] last year, which necessitates something like NVM. I don't want to deal with that for my build tools. I just want a binary that is known to work to continue to work until it is replaced.

3. Yes, conventionally everything in Nodeland was written out to dist as ES5. This also sucks ass because now you end up shipping a bunch of ES5 crap to your end users even though you aren't targeting ES5. It is very hard to build an actual ES2020 module unless you're willing to not use external dependencies at all. Snowpack et al are shifting this slowly, but it has barely even begun as a trend.

[0] https://nodejs.org/en/blog/release/v12.17.0/ https://www.google.com/search?q=babel+compat+data+corejs3+sh...

> Modern JITed JS is fast.

The caveat here is that it's not nearly as fast for code that isn't properly warmed up, even in the face of herculean efforts to make it so.

Speaking of Yarn in particular since I maintain it, I strongly believe that more than speed we (package managers) need a good polish. And to do that, we need a community that feels empowered to make changes when they feel frustrated about something - which makes using JS / TS critical. By contrast, the UX of a bundler / linter is fairly straightforward (compared to Yarn's 46 builtin commands), so making external contributions easier isn't really necessary.

Agreed regarding yarn and npm comparison. During my development of React Native, I was using Yarn and I was blown away at the rate of installing the packages. Since then, I've pretty much used yarn over npm for all my React and React Native projects.

One of the main benefits of Esbuild (if I recall correctly) is that all passes share a single AST. Whereas in a traditional setup your linter, transpiler, formatter, and sometimes even bundler and minifier all do their own totally independent passes on the source which means parsing it from scratch each time. So this would be a classic case of integrating everything into a monolith for a boost in efficiency.

I don’t think so. I’d bet that a JS solution that followed esbuild’s architecture would be in the same order of magnitude of performance.

Now, you could argue that JS encourages complex, inefficient abstractions and over engineering and Go encourages the opposite. That, I’d believe.

The JS & frontend world is _seriously fun_ right now. If you blew it all off as a quagmire of complexity, sketchy engineering, treadmill of tools, etc... it's time to re-evaluate everything. I have more fun and feel more productive working on modern frontend stuff with tools like esbuild than any other GUI programming I've done in 30 years.

Yep, I tried front-end way back and hated it. Can you mention some other tech that should be covered in my re-evaluation?

TailwindCSS, Svelte, and Snowpack are probably worth a shot, all pretty much bleeding edge

The problem with front end development is that it's all bleeding edge and nothing that's stable and is improved for more than one hype cycle.

Suggesting more bleeding edge tech is not a good argument to demonstrate that front end development got better.

In my experience, it changed, it improved on many aspects, but it's still a pile of unstable crap running on the power of hype and over-enthusiastic junior engineers.

I get your frustration (and shared it a year ago), but you're really doing something like react a disservice by dismissing it like that as just hype. On the contrary react has evolved significantly over the years, introducing things like JSX (templating HTML + JS in the same file, now standard in every other component system), build tooling like create-react-app (zero config tooling, now standard in every JS build tool), functional component model with hooks (now copied by every other component library), and on the horizon stuff like server-side components. It has only gotten more stable, more proven, and easier to use over time.

I am not dismissing it. I appreciate what React is doing, and it is indeed revolutionary.

My point is that there has been a lot of evolution and improvement, but developer sanity is one of the few things that have just gone worse.

It is dishonest to look only at the bright side of modern frontend coding and forgetting the node_modules nightmare, the incredibly obtuse language, the slow compilation times, the myriad of CSS frameworks that are invented because CSS is an absolute pain in the arse for modern design, etc., the fact that every JS tool either is core to the whole circus and is maintained by a stressed out, underpaid person in the middle of nowhere, or has a minimum of 5k Github issues and a major version released every 3 months, and every time you get a problem you're told "haven't you tried the new alpha release of the big rewrite we've just started?".

It is absolute madness, not just frustrating. But yeah, React is cool.

I'm really biased as I am building it myself: Starboard Notebook puts literate programming into the browser without a lot of magic.

It's amazing what browsers can do these days without any build step!

[0]: https://starboard.gg

React & next.js are worth evaluating. It's a super powerful full stack with everything from server side rendered data (REST APIs even) all the way to complete client-side SPAs, all using the same react components. It's a slick little swiss-army knife that can make anything from a basic blog with markdown content, to a static marketing page, to a full client-first PWA experience. There is sadly almost nothing else really like it right now.

MDX is another neat step, it's markdown + react components and fits in very well with next.js: https://github.com/hashicorp/next-mdx-remote

Vue, and Svelte to just get an idea of what other components systems are like. They're all equally capable and just have different tradeoffs and styles. Keep an eye on Svelte in particular as its next.js-like system (SvelteKit) is working on a major revamp to be serverless-first and is quite interesting. Once you learn one component system it's easy to switch between them all--they're all cribbing and building on top of each other's ideas. The whole space is innovating in a great way.

Web components are good to learn and compare to component frameworks above. It's still a changing space but points to a nice future where we can all just publish and share components.

Yet none of the stuff you mention here will live beyond the next two years. Fun is as much as i would describe the js ecosystem, for more boring corporate use banking on these is the equivalent of getting a trojan horse in the application portfolio.

React won't live past two years? What?

I'd be willing to stake money on React, Vue, next.js and Svelte surviving at least 2 more years - roughly in descending order of probability, though all three well above 50%.

React was released in 2013, that’s 8 years.

While that’s true, code using React in 2021 often bears little resemblance to code using React in 2013, and the ecosystem around it looks very different too.

It’s easy to forget that hooks were only introduced in React 16.8, which was released just over two years ago. And yet today, if you visit popular forums for React devs like /r/reactjs, you’ll find no shortage of people who will tell you that class-based components are ancient history and anyone who isn’t using hooks for everything today is a dinosaur.

This year, I’ve noticed a spate of online discussions about state management within the React ecosystem. Just like the hooks vs. classes debate of yesteryear, there is a striking contrast between those forever keen to do the new thing (sometimes using React’s own context and hooks, sometimes using relatively new libraries) and those who prefer to rely on more tried-and-tested tech like Redux and MobX.

In any situation like this, it’s sensible to question how much real progress is being made, and how much of the change is just lost productivity due to churn in tools and “best practices”. If so many developers think it’s normal to swap out most of your tools and coding style every couple of years or less, you have to wonder how long they expect anything they ever build to be maintained for or how often they think longer-lived software should have big rewrites just to update the tools…

In contrast, esbuild is shaping up to be an excellent tool. There seems to be a healthy focus on doing one common and important job well, it’s much better at it than the popular tools it potentially replaces, and it also seems designed to play nicely with others. It reminds me of the early days of 6to5/Babel, actually. This is what we need more of in the front-end web dev community right now.

And I personally can't wait to see what amazing things the creators of these component systems will land on next...

Next.js is pretty corporate-friendly. Very easy to split things up and have many folks and teams working on monoliths or services with it.

That’s such an unqualified statement that I’d be embarrassed to say it out loud. Angular 1 apps are still in production. COBOL is still in production. I’d bet $100 that two years from this date, all three of those are still popular, being used by enterprise, and have tutorials written for them on blogs or produced on YouTube.

I agree. I was a web developer in the 90s when stuff was primitive, ugly and difficult.

I switched to desktop .Net development in 2001 did that for almost 15 years.

Since then I have been back on the web. I am full-stack so I find myself switching between front-end and back-end frequently.

I am enjoying my time more in the world of TypeScript, VS Code, and Angular than I am writing the back-end REST APIs in .Net Core and Visual Studio.

I was dreading going back to web development when I switched back again but recently it has turned out to be nicely structured, performant, logical and enjoyable.

My career sounds much like yours, and my conclusions are the same. Typescript is a decent language. The tooling is excellent. The old footguns are mostly behind us. It’s definitely a completely new ballgame vs the old hackery I used to have to endure.

If you have the resources available to you (e.g. your employer is willing to pay) Rider is an excellent alternative to Visual Studio. It should make backend dev more enjoyable.

Every time I am unfortunate enough to do something front-end it's just as bad as I remember.

Edit: professionally, that is; when I do front-end related stuff for myself, it's fine, but they are small and I keep things simple - vanilla JS where needed, etc.

What do you remember? These days I’m no longer concerned about `this` pointing to the wrong object. Importing files is a huge step forward from when I started. The standard library has grown; a bunch of Lodash isn’t needed anymore because of it. Promises and async/await. Even just template strings! So glad I don’t have to concatenate with pluses and watching my double or single quotes.

I definitely agree with this in general, but there are exceptions where it’s still a quagmire. Angular, for example.

totally! i have been developing a thesis around this I call the "Third Age" of JavaScript - TLDR: the arc of history is toward ES Modules, and polyglot tooling, like esbuild. Creating much faster dev tools and user experiences.

http://swyx.io/js-third-age

Drag&drop building UI in Visual Whatever was plenty productive, hell they even had what the kids today call server rendering, and if it didn't look right I could always press F5 and see the result right there.

I tried this a week or so ago, and it was indeed 100x or 1000x as fast as my webpack setup. Shocking, really. I couldn't get dynamic imports / code splitting working, which seemed to not be fully implemented yet. I also wasn't sure how to make polyfills happen.

We love esbuild and we use it internally for SST https://github.com/serverless-stack/serverless-stack.

The work Evan does is seriously impressive.

as a heavy user of CDK, sst looks pretty cool.

i'm curious why you didn't go the direction of adding this functionality to CDK directly? i'd like to use some of the functionality in here like live lambda development, but i also don't want to take on converting my org's already built CDK extensions and deal with migrations.

Thanks!

We had to change the build process of Lambdas to support deploying a mock version of the function. And we need to add a new command that deployed the debug stack.

Here's how it works internally — https://docs.serverless-stack.com/live-lambda-development

Your existing CDK app should work with SST. The main difference is that SST deploys per stage (or environment). This allows you to do `sst start` that goes to one environment and `sst deploy --stage prod` that goes to another.

Love how this is used with Hugo:

https://gohugo.io/hugo-pipes/js/

Yes. When ESBuild came out, I made a feature request to get it added to Hugo, and I was surprised at how well it has worked out. Goes to show you should always open an issue!

For those relying on babel - what are the options?

One thing I haven't seen yet is support for SCSS and CSS Modules. It looks like projects on those would need to switch to emotion+styled-components or styled-system, which would be a big move.

If anyone uses relay, I started an issue here about using it with next-gen bundlers like esbuild: https://github.com/facebook/relay/issues/3319

For those who don't know, relay is a graphql system by facebook. It seems dependent on babel (to my knowledge?) Two developments on this front:

1. @sciyoshi built an esbuild proof of concept for relay: https://gist.github.com/sciyoshi/34e5865f2523848f0d60b4cdd49...

2. Meanwhile, the compiler has been being quietly rewritten in rust: https://github.com/facebook/relay/tree/master/compiler. They're also claiming that it will include type generation.

When can we have const back? At some point esbuild started to transpile all const/let/var statements to var, which can potentially cause a slight performance decrease in some hot code paths (or at least a slight memory usage increase as noted in https://stackoverflow.com/a/52749016/78436).

Can you elaborate on this? const and let should be interchangeable from a performance perspective because it's not like the engine needs your input to know whether a binding is reassigned ever (that's a fundamentally easy thing for a compiler to check) so I must conclude that you're seeing performance benefits from using block scoped variables with TDZ that disappear when you use function scoped variables with var?

How does this compare to https://www.snowpack.dev/ ?

SnowPack is more of an all-in-one kind of tool (with dev server, HMR, etc.). Also it uses esbuild internally :-)

https://www.snowpack.dev/guides/optimize-and-bundle#option-1...

Snowpack is a bundler, not a build tool. It works with a variety of file formats, and it uses esbuild to compile JS/TS assets.

Snowpack uses esbuild internally now, there's a good rundown of it and other awesome snowpack features like streaming imports in their 3.0 release announcement: https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0

I just use the very large subset of JavaScript supported natively by all major JS engines and avoid a transpiler entirely. Infinity times faster. That's subset is ES9/ES2018. https://wwwperiodictable.surge.sh/

If you want to use config files with esbuild, esbuild-config is for you:

https://github.com/bpierre/esbuild-config

(disclaimer: I am the author)

How does Esbuild achieve such insane differences in speed?

https://esbuild.github.io/faq/#why-is-esbuild-fast

It is written in go and compiled. Go is responsible for high parallelism. The fact it is compiled is an advantage over javascript-based bundlers because they are re-compiled every time you start building the source code (did I get that right?).

partially. we should not overstate the impact of Go. if you read his design principles doc, he also prioritized parallelization and minimizing JS AST passes. those are surely at least as important as language choice.

I would love to switch to esbuild, but unfortunately some basics are still not in there. I read some people switched, but I wonder how they have projects requiring 30+ seconds when not utilizing bundle splitting. Maybe I am missing something... Are you outputting esm files or what?

Would be great to get some insights how people are mitigating the lack of bundle splitting in non-esm output right now. Thanks!

For those who are actively using esbuild with TypeScript, how do you check the types?

I run tsc with noEmit passed as a flag. Esbuild is replaces my previous tsc, babel, uglify setup and is much faster.

What some people do is use types purely for editor purposes, and let the build process just throw them away. We did this at my last company using Babel

In 3 ways:

- Using the Language Server Plugin in editors

- `npx tsc --noEmit` in a pre-commit hook

- `npx tsc --noEmit` in CI

I have a "lint" pre-test step that builds with tsc and runs eslint.

I also have a `tsc --watch` running in a vscode window that highlights syntax and typing errors as I develop.

I really really wish this supported experimental decorators with reflection metadata so we could use this in our Angular and NestJS apps.

Release note says pinning version with "^0.8.0", should be "~0.8.0" right?

^ is for minor version, ~ for patch, you can pin exact version without using anything, so "0.8.0"

Ah it seems ^ and ~ do not apply to versions pre 1.0.0

An extremely fast JavaScript bundler and minifier esbuild.github.io/

This is an amazing work :)

waiting for js bundler written in Rust

you know about swc right? https://swc.rs/

omg lol

I'd recommend esbuild over SWC. It's much more mature.

Yes, but a bunch of the Typescript support is closed sourced . No idea, if that's important for you.

Type checker, yes. I don't think esbuild comes with a built-in typechecker either.

Is there anything else I am missing?

I was referring to swc

It's important to me. Could you please link me to where these nonfree bits are?

Reply on news.ycombinator.com