11 ms·

Esbuild – An extremely fast JavaScript bundler

• escot 5y ago
  So is esbuild vs parcel a bit of an accidental proxy battle between go and rust?
• moron4hire 5y ago
  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?
• Salu3 5y ago
  salu2
• XCSme 5y ago
  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).
  • XCSme 5y ago
    I have to note that the project is a TypeScript project.
• k__ 5y ago
  I've used it for a TypeScript project and it just worked. A bit like Parcel, but faster.
• armchairhacker 5y ago
  How does esbuild compare to Bun, snowpack, Vite, and any other JS bundles? In performance, reliability, and extra features?
  • TameAntelope 5y ago
    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-in-optimizations-powered-by-esbuild https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0#built...
• ianberdin 5y ago
  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.
  • ianberdin 5y ago
    You knew how to speed up webpack 5-10 times by setting cache.type = 'filesystem', right?
• louissm_it 5y ago
  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 https://inertiajs.com
  • d3nj4l 5y ago
    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 https://github.com/ElMassimo/vite_ruby
    • louissm_it 5y ago
      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 5y ago
    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 5y ago
    You can use esbuild to your existing rails apps via the gem jsbundling-rails https://github.com/rails/jsbundling-rails https://github.com/rails/jsbundling-rails It works really well
• kohlerm 5y ago
  That's old news or? For complex projects moving to esbuild from say Webpack is not necessarily easy.
  • oliyoung 5y ago
    its also surprisingly easy, much easier than you'd expect
  • onion2k 5y ago
    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.
• TekMol 5y ago
  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.
  • dmitriid 5y ago
    > 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.
    • TekMol 5y ago
      That contradicts my experience and what I just described. In my experience, sites do feel instant even if they load dozens of scripts.
      • dmitriid 5y ago
        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.
      • _old_dude_ 5y ago
        Browsers are good at caching JavaScript files, so it depends if the scripts are already cached or not.
      • setr 5y ago
        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.
• kureikain 5y ago
  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.
  • pineconewarrior 5y ago
    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 5y ago
      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 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 5y ago
        Thank you so much for sharing! I'll give this a shot really quick
  • eyelidlessness 5y ago
    3. You can inject anything you want without a plugin with `inject`. 4. You can just use `target: node` (or node12, node14.6, etc)
  • 5y ago
• Aeolun 5y ago
  What I need is a similar speedup for my Typescript and eslint checks. Bundling isn’t my main issue.
  • nuerow 5y ago
    > 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.
    • rkuykendall-com 5y ago
      Yeah, Jest is the slowest thing in my build pipeline.
  • kitten_mittens_ 5y ago
    For ESLint: https://eslint.org/docs/user-guide/command-line-interface#caching 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.
• truth_seeker 5y ago
  I would rather use Parcel.
  • nsonha 5y ago
    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)
    • truth_seeker 5y ago
      I don't think context (JS build tool) is missing here. If someone has open mind, they can also google what is Parcel.
      • marton78 5y ago
        Most people who care to read the comments to a post about esbuild will know what Parcel is. Why do you prefer it?
      • wruza 5y ago
        “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.
• phillu 5y ago
  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 5y ago
    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.
    • lstamour 5y ago
      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.
    • Vinnl 5y ago
      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.
      • 5y ago
• sandGorgon 5y ago
  has anyone used this in react-native ?
  • dstaley 5y ago
    Pretty sure the Expo folks are working on this!
    • sandGorgon 5y ago
      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
• Kiro 5y ago
  How is it possible to be so fast?
  • louissm_it 5y ago
    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
  • lioeters 5y ago
    Answered in the FAQ: Why is esbuild fast? https://esbuild.github.io/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
  • leeman2016 5y ago
    It also doesn't include type checking for typescript. It just transpiles sources to javascript
    • Ginden 5y ago
      > 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.
• sorenjan 5y ago
  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?
  • darekkay 5y ago
    Check out PostHTML: https://github.com/posthtml/posthtml https://github.com/posthtml/posthtml
  • eyelidlessness 5y ago
    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.
  • lioeters 5y ago
    Rehype is an HTML processor with an ecosystem of plugins: https://github.com/rehypejs/rehype/ https://github.com/rehypejs/rehype/
  • tannhaeuser 5y ago
    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.
  • M2Ys4U 5y ago
    I think Parcel[0] is what you want for that use-case.[1] [0] https://parceljs.org/ https://parceljs.org/ [1] https://parceljs.org/recipes/image/ https://parceljs.org/recipes/image/
• hit8run 5y ago
  What do you think of the importmap approach propagated by dhh on rails 7?
  • Mikeb85 5y ago
    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.
  • louissm_it 5y ago
    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.
  • albertgoeswoof 5y ago
    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
    • hit8run 5y ago
      No importmaps are the new default in Rails 7. The menu is still omakase. In case you have different requirements you can use options.
• fabian2k 5y ago
  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.
  • cypressious 5y ago
    I think vite is using esbuild only for TS transpiling in development and esbuild & rollup for production.
• eezing 5y ago
  Deno is using this: https://github.com/swc-project/swc https://github.com/swc-project/swc
• petethepig 5y ago
  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 5y ago
    It is very easy to be misleading though: https://github.com/evanw/esbuild/issues/669 https://github.com/evanw/esbuild/issues/669
    • iruoy 5y ago
      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/186446eae8cc8c7439ebf41cfe7d8e3b7c3e841c https://github.com/evanw/esbuild/commit/186446eae8cc8c7439eb...
• joshxyz 5y ago
  Yep, moved from webpack to esbuild + postcss. Great results.
• satvikpendem 5y ago
  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 5y ago
    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.
    • forsakenharmony 5y ago
      It's being using to bundle some parts of nextjs itself, but not quite ready to replace babel for users rn afaik
    • cute_boi 5y ago
      May be in next release we get swc in nextjs?
    • crubier 5y ago
      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 https://labelflow.ai ). Hot reload times instantly went from 10s to 1s. Twitter discussion here https://twitter.com/vlecrubier/status/1448371633673187329?s=21 https://twitter.com/vlecrubier/status/1448371633673187329?s=... Overall I’m pretty bullish on Rust tooling and integration within the JS/ Wasm ecosystem !
      • alfonsodev 5y ago
        could you provide a link on how to enable this experimental setting ? thank you.
        • 5y ago
• throw_m239339 5y ago
  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?
  • phinnaeus 5y ago
    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.
    • throw_m239339 5y ago
      > 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...
      • innocenat 5y ago
        dist.js: $(wildcard *.js) cat $? > dist.js Like this?
      • phinnaeus 5y ago
        I certainly didn't. > If you're going to use a JS bundler written in Go, just stick to MAKEFILE... What?
  • Intrepidd 5y ago
    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.
• calmyournerves 5y ago
  esbuild is awesome! The level of detail in the release notes [1] always impresses me. [1] https://github.com/evanw/esbuild/releases https://github.com/evanw/esbuild/releases
• dom111 5y ago
  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 5y ago
    Webpack is a bane of webdev existence. Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself
    • enjikaka 5y ago
      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 5y ago
        what are you talking about, webpack has nothing to do with Facebook or React.
    • ksec 5y ago
      >Webpack is a bane of webdev existence. Modern Web Dev is the cause of Webpack though. Over complicated things.
  • sanderdlm 5y ago
    Do you have a public example of a PHP/Symfony project that you've ported from Webpack to esbuild?
• Zarkaos 5y ago
  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
• jerrygoyal 5y ago
  see comparison with swc: https://swc.rs/docs/benchmark-transform https://swc.rs/docs/benchmark-transform
  • wdroz 5y ago
    So swc is faster in almost all scenarios
    • RobertKerans 5y ago
      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.
  • toastal 5y ago
    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.
• qeternity 5y ago
  What’s the catch? Do they really have a secret sauce or are there limitations in esbuild to achieve these speed ups?
  • nusaru 5y ago
    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/ https://esbuild.github.io/faq/
    • qeternity 5y ago
      I saw that, but none of that adds up to a 100x speedup.
      • dbbk 5y ago
        It does
  • johnnypangs 5y ago
    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.
  • hsn915 5y ago
    The catch is the person behind it cares about performance
  • JeanMeche 5y ago
    Well not being written in JS does help -a lot-. Esbuild is written in GO.
    • qeternity 5y ago
• dugmartin 5y ago
  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.
• Tade0 5y ago
  Such a shame that Angular doesn't benefit from using such tools: https://github.com/evanw/esbuild/issues/42#issuecomment-933959929 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.
• sAbakumoff 5y ago
  from my PoV Vite.js is much more mature project than esbuild
• maga 5y ago
  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.
  • theptip 5y ago
    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.
    • Epskampie 5y ago
      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.
• swhitf 5y ago
  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!
  • hi41 5y ago
    I have not done web development. Please forgive my ignorance. How is this different from Angular and React?
  • koolba 5y ago
    > 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?
    • nicoburns 5y ago
      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)
    • horsawlarway 5y ago
      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)
• conaclos 5y ago
  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?
• strzibny 5y ago
  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/ https://nts.strzibny.name/12factor-elixir-phoenix-releases/) and cannot wait to do the same in Rails.
• toastercat 5y ago
  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.
• KingOfCoders 5y ago
  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.
• lovely_koala 5y ago
  Looks awesome! I'm gonna use it!
• ep103 5y ago
  Anyone able to compare this to Vite?
  • Aeolun 5y ago
    Vite uses esbuild I think. But the concepts are different.
  • armincerf 5y ago
    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-esbuild https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
• deleted 5y ago
  [deleted]
• talkingtab 5y ago
  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. :-)
  • XCSme 5y ago
    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) ?
• darepublic 5y ago
  It stings being in webpack and there isn't much I can do about it in my current situation
• terpimost 5y ago
  I must say that this got to be a new standard. Es build is what we need. Great thing. Huge thanks to creators!
• towndrunk 5y ago
  Does esbuild support scss directly yet? I see on the site it mentions css. This is an important limitation for me.
  • pineconewarrior 5y ago
    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
  • conradfr 5y ago
    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 https://github.com/glromeo/esbuild-sass-plugin [2] https://hexdocs.pm/phoenix/asset_management.html#esbuild-plugins 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 ;)
• crubier 5y ago
  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.
• pier25 5y ago
  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.
• imjared 5y ago
  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 5y ago
    > 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
• jFriedensreich 5y ago
  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 .
• sesm 5y ago
  > 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.
• mjackson 5y ago
  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.
• CodeIsTheEnd 5y ago
  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.
  • marton78 5y ago
    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.
    • winrid 5y ago
      and he's building tools to optimize his teams.
    • hn_throwaway_99 5y ago
      > 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.
  • eloff 5y ago
    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 5y ago
      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.
• junon 5y ago
  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.
• qwertox 5y ago
  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 https://esbuild.github.io/faq/#why-is-esbuild-fast
  • jamra 5y ago
    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.
• ksec 5y ago
  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 https://twitter.com/jarredsumner/status/1390084458724741121
  • beckler 5y ago
    Granted, those stats are for JSX, but it’ll be interesting to check out for sure.
  • chakkepolja 5y ago
    The numbers seem cherry picked though, I don't like this type of 197.96432100004x faster claims.
    • eyelidlessness 5y ago
      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.
• peanut_worm 5y ago
  Is this the only popular JS build tool written in something other than JavaScript
  • awestroke 5y ago
    SWC, Bun are other examples. And I'm sure there are even more