[HN Gopher] Esbuild - An extremely fast JavaScript bundler
___________________________________________________________________
Esbuild - An extremely fast JavaScript bundler
Author : taitems
Score : 625 points
Date : 2021-10-14 05:07 UTC (17 hours ago)
(HTM) web link (esbuild.github.io)
(TXT) w3m dump (esbuild.github.io)
| TekMol wrote:
| 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 wrote:
| > 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 wrote:
| That contradicts my experience and what I just described. In
| my experience, sites _do_ feel instant even if they load
| dozens of scripts.
| dmitriid wrote:
| 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_ wrote:
| Browsers are good at caching JavaScript files, so it
| depends if the scripts are already cached or not.
| setr wrote:
| 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.
| eknkc wrote:
| If they are not waterfalling then yeah. But when a depends
| on b and b depends on c you will be fetching those
| serially.
|
| The bundler will have those preprocessed and bundled
| together.
| hivacruz wrote:
| I thought HTTP 2 fixed the problem of multiple downloads of
| small files/dependencies?
|
| The creator of Rails talks about it here:
| https://world.hey.com/dhh/modern-web-apps-without-
| javascript...
| beeandapenguin wrote:
| Khan Academy did a great writeup on their experience
| (including thoughts about HTTP/2) with various strategies
| for serving JS, such as:
|
| - Single bundle
|
| - No bundles (all separate files)
|
| - Hybrid
|
| https://blog.khanacademy.org/forgo-js-packaging-not-so-
| fast/
| eyelidlessness wrote:
| You can use the Network tab of your preferred browser to
| see the waterfall. HTTP2 did improve a lot, but it can't
| magically resolve N-deep transitive imports without
| additional information. It was originally designed to have
| that information provided at the server level, but HTTP
| Push has been dead for a while. There are physical
| limitations at work, optimizing requests on the wire is
| still important.
| throw_m239339 wrote:
| > How many scripts does a site need to make it feel faster when
| bundled?
|
| It's because people are using these huge frameworks with a lot
| of bloated code, it's too big, now devs are forced to do tree
| shaking and what not to trim the fat... front end JS
| development has become a madhouse of unnecessary complexity,
| because of node.js as well...
|
| I hope that with the help of DENO that doesn't suffer from all
| that cargo culting, front-end development can become a
| healthier ecosystem...
|
| Yes, some apps are complex, but 99% of front-end UI aren't.
| rimliu wrote:
| I just saw an (internal) presentation where presenter
| predicted that in a few coming months we will see a lot more
| RxJS being used in ReactJS projects. Cannot wait to see it
| included on webpages which would be just fine with zero JS.
| kryptiskt wrote:
| I like Snowpack (https://www.snowpack.dev) because it doesn't
| actually do any bundling, it just makes sure that the files are
| in the right place to be loaded (it does compile Typescript
| files). Because the only thing I actually care about during
| development is that all the inter-package dependencies are
| resolved. I don't actually need a fat heap of JS that needs to
| be rebuilt every time I change something.
| Mikeb85 wrote:
| Yes, that's why ES modules and import maps are a thing. For
| example Deno uses them, and they're the new default on Rails 7.
| eyelidlessness wrote:
| What ESBuild offers over plain ESM is:
|
| - fast TypeScript/JSX compile
|
| - bundling shared code to reduce request waterfall/splitting to
| reduce redundancy
|
| - bundle optimization (tree shaking/dead code elimination;
| minification is actually faster than not using it)
|
| - a simple plugin system for use cases like other compiled
| frameworks like Vue or Svelte, or whatever else you might want
| in a build pipeline
| TekMol wrote:
| On the downside, it will put all the code into one giant
| script that has to be downloaded upfront.
|
| While a website that loads scripts per page will only load
| the scripts that are needed on the current page.
| rudian wrote:
| Unless your site is made of 4 files/modules, you simply
| must bundle. ESM will download the files in series, as each
| dependency is discovered. Then compression doesn't work as
| well as it will be per-file. Then of course you can't tree-
| shake dependencies from npm, so good luck downloading the
| whole of lodash on your client.
|
| In short you lose the advantages of _only download what you
| need_ pretty quickly.
| TekMol wrote:
| > good luck downloading the whole of lodash on your
| client
|
| I never felt the need to use loadash. But even if a site
| would do that, it does not seem like a big issue. It is
| 71k. A Twitter profile page is over 5MB. 70 times the
| size of that loadash library. An appartment page on
| AirBnB is over 9MB. An Instagram profile page is over 9MB
| too.
| eyelidlessness wrote:
| ESBuild does support code splitting, in case you weren't
| aware.
| nsonha wrote:
| > When I visit websites that are rendered serverside, they
| usually feel instant to me. Even when they load a dozen scripts
| or so
|
| Then they'll be faster doing only one request, this is
| regardless of ssr or spa
|
| Bundling also gives you slatic analysis (typescript and
| linting), and frees developers from developing in the dark,
| like keeping track in their brain what component in what script
| exposes what global.
| throw_m239339 wrote:
| > Bundling also gives you slatic analysis (typescript and
| linting),
|
| No it doesn't do that, typescript compiler does the static
| analysis and whatever linter does the linting, you don't need
| a bundler for that, a bundler just takes many source files
| and bundles them into one.
| towndrunk wrote:
| Does esbuild support scss directly yet? I see on the site it
| mentions css. This is an important limitation for me.
| pineconewarrior wrote:
| 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 wrote:
| I use the esbuild-sass-plugin[1] in my Phoenix 1.6 project,
| using the build script they give in the doc[2] and it works for
| me.
|
| [1] https://github.com/glromeo/esbuild-sass-plugin
|
| [2] https://hexdocs.pm/phoenix/asset_management.html#esbuild-
| plu...
|
| Maybe it'll help someone, one difference from the plugin doc
| was using:
|
| const { sassPlugin } = require("esbuild-sass-plugin");
|
| Instead of:
|
| import { sassPlugin } from "esbuild-sass-plugin";
|
| After all, it would not be Javascript without some import
| syntax shenanigan ;)
| petethepig wrote:
| 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 wrote:
| It is very easy to be misleading though:
| https://github.com/evanw/esbuild/issues/669
| iruoy wrote:
| 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.
| ..
| darepublic wrote:
| It stings being in webpack and there isn't much I can do about it
| in my current situation
| kureikain wrote:
| 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.
| eyelidlessness wrote:
| 3. You can inject anything you want without a plugin with
| `inject`.
|
| 4. You can just use `target: node` (or node12, node14.6, etc)
| rwieruch wrote:
| 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 wrote:
| 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 wrote:
| 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
| Sheepsteak wrote:
| 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.
| calmyournerves wrote:
| esbuild is awesome! The level of detail in the release notes [1]
| always impresses me.
|
| [1] https://github.com/evanw/esbuild/releases
| swhitf wrote:
| 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!
| ep103 wrote:
| 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 wrote:
| Don't forget bun and swc
| moralestapia wrote:
| >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 ...
| jacobsenscott wrote:
| 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 wrote:
| 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 wrote:
| 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.
| koolba wrote:
| > 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 wrote:
| 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 wrote:
| 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)
| [deleted]
| have_faith wrote:
| 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 wrote:
| I felt the same, the industry's shift away from the gulp way
| of doing things was a real loss.
| horsawlarway wrote:
| 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.
| pineconewarrior wrote:
| You're right about the community being mostly dead. There
| are a lot of bugs and performance issues in the
| underlying libraries, and Gulp's developers have not been
| able to get the upstream updates integrated.
|
| I just redid our Grunt stuff in Gulp. It was painful -
| difficult to find up-to-date information, and the result
| was not that great. I expected a much greater SCSS
| compilation performance increase compared to FS-based
| tooling. Maybe I'm doing something wrong.
|
| I'd switch to something like ESBuild and leave SCSS for
| dead, but it's not an option for me yet :(
| dom111 wrote:
| 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.
| sanderdlm wrote:
| Do you have a public example of a PHP/Symfony project that
| you've ported from Webpack to esbuild?
| dom111 wrote:
| I'm afraid not, it's all internal and not open-source. :(
| baybal2 wrote:
| 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 wrote:
| >Webpack is a bane of webdev existence.
|
| Modern Web Dev is the cause of Webpack though. Over
| complicated things.
| enjikaka wrote:
| 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 wrote:
| what are you talking about, webpack has nothing to do with
| Facebook or React.
| fabian2k wrote:
| 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 wrote:
| I think vite is using esbuild only for TS transpiling in
| development and esbuild & rollup for production.
| conaclos wrote:
| 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?
| Zarkaos wrote:
| 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
| pier25 wrote:
| 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.
| mjackson wrote:
| 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.
| Aeolun wrote:
| What I need is a similar speedup for my Typescript and eslint
| checks. Bundling isn't my main issue.
| kitten_mittens_ wrote:
| For ESLint:
|
| https://eslint.org/docs/user-guide/command-line-interface#ca...
|
| For TS, tsc has an --incremental flag. ts-fork-checker-plugin
| is non-blocking for the rest of the build too.
| nuerow wrote:
| > _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.
| Tade0 wrote:
| Such a shame that Angular doesn't benefit from using such tools:
|
| https://github.com/evanw/esbuild/issues/42#issuecomment-9339...
|
| So I'm currently stuck with a build that takes minutes, even
| though in principle it should require only seconds.
| junon wrote:
| 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.
| terpimost wrote:
| I must say that this got to be a new standard. Es build is what
| we need. Great thing. Huge thanks to creators!
| imjared wrote:
| 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 wrote:
| > 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
| truth_seeker wrote:
| I would rather use Parcel.
| nsonha wrote:
| 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 wrote:
| I don't think context (JS build tool) is missing here.
|
| If someone has open mind, they can also google what is
| Parcel.
| marton78 wrote:
| Most people who care to read the comments to a post about
| esbuild will know what Parcel is. Why do you prefer it?
| wruza wrote:
| "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.
| jFriedensreich wrote:
| 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 .
| talkingtab wrote:
| 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 wrote:
| 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) ?
| Kiro wrote:
| How is it possible to be so fast?
| lioeters wrote:
| Answered in the FAQ:
|
| Why is esbuild fast? https://esbuild.github.io/faq/#why-is-
| esbuild-fast
|
| - It's written in Go and compiles to native code
|
| - Parallelism is used heavily
|
| - Written from scratch with performance as a goal
|
| - Efficient use of memory
| louissm_it wrote:
| 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
| leeman2016 wrote:
| It also doesn't include type checking for typescript. It just
| transpiles sources to javascript
| Ginden wrote:
| > 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 wrote:
| 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?
| lioeters wrote:
| Rehype is an HTML processor with an ecosystem of plugins:
| https://github.com/rehypejs/rehype/
| M2Ys4U wrote:
| I think Parcel[0] is what you want for that use-case.[1]
|
| [0] https://parceljs.org/
|
| [1] https://parceljs.org/recipes/image/
| darekkay wrote:
| Check out PostHTML: https://github.com/posthtml/posthtml
| eyelidlessness wrote:
| 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.
| tannhaeuser wrote:
| 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.
| peanut_worm wrote:
| Is this the only popular JS build tool written in something other
| than JavaScript
| awestroke wrote:
| SWC, Bun are other examples. And I'm sure there are even more
| satvikpendem wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| could you provide a link on how to enable this experimental
| setting ? thank you.
| cute_boi wrote:
| May be in next release we get swc in nextjs?
| forsakenharmony wrote:
| It's being using to bundle some parts of nextjs itself, but
| not quite ready to replace babel for users rn afaik
| escot wrote:
| So is esbuild vs parcel a bit of an accidental proxy battle
| between go and rust?
| crubier wrote:
| 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.
| strzibny wrote:
| Both Rails 7 and Phoenix 1.6 is going off Webpack by default and
| I am so looking into the esbuild future. I never really liked
| Webpack to be honest.
|
| I already replaced Webpack in my Phoenix project (you can compare
| default steps for building a release here
| https://nts.strzibny.name/12factor-elixir-phoenix-releases/) and
| cannot wait to do the same in Rails.
| hit8run wrote:
| What do you think of the importmap approach propagated by dhh on
| rails 7?
| Mikeb85 wrote:
| 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.
| albertgoeswoof wrote:
| 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 wrote:
| No importmaps are the new default in Rails 7. The menu is
| still omakase. In case you have different requirements you
| can use options.
| louissm_it wrote:
| 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.
| jerrygoyal wrote:
| see comparison with swc: https://swc.rs/docs/benchmark-transform
| toastal wrote:
| 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.
| wdroz wrote:
| So swc is faster in almost all scenarios
| RobertKerans wrote:
| 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.
| XCSme wrote:
| 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 wrote:
| I have to note that the project is a TypeScript project.
| qwertox wrote:
| 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
| sesm wrote:
| > 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.
| qeternity wrote:
| What's the catch? Do they really have a secret sauce or are there
| limitations in esbuild to achieve these speed ups?
| nusaru wrote:
| 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/
| qeternity wrote:
| I saw that, but none of that adds up to a 100x speedup.
| dbbk wrote:
| It does
| johnnypangs wrote:
| 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.
| pedrow wrote:
| It doesn't always work in situations where 'require' can't be
| statically evaluated at run-time (webpack would work in this
| situation) - for example I filed a bug recently[0] Even though
| the bug was closed I was impressed with the thorough and timely
| response from the esbuild developers which explained the
| reasoning behind it. For me it was worth changing my project
| just so I could continue using esbuild, it really is that good!
|
| [0]: https://github.com/evanw/esbuild/issues/1619
| Kyro38 wrote:
| Well not being written in JS does help -a lot-.
|
| Esbuild is written in GO.
| qeternity wrote:
| I'm sure it helps. It doesn't help 100x
| 1_player wrote:
| It helps to get 80% of the way there, on a logarithmic
| scale. The remaining 20% is evanw saying no to adding any
| kind of option, feature and the kitchen sink to this
| project, which is one of the reason Webpack/Babel & co. are
| some of the heaviest objects in the universe.
| [deleted]
| hsn915 wrote:
| The catch is the person behind it cares about performance
| armchairhacker wrote:
| How does esbuild compare to Bun, snowpack, Vite, and any other JS
| bundles? In performance, reliability, and extra features?
| TameAntelope wrote:
| 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...
| joshxyz wrote:
| Yep, moved from webpack to esbuild + postcss. Great results.
| dugmartin wrote:
| 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.
| phillu wrote:
| 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 wrote:
| 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.
| acid__ wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| Vinnl wrote:
| You can absolutely run it during development! In fact,
| many people will use an editor that automatically does
| this and highlights any potential errors - which means
| you don't need your compiler to display them (or even
| block compiling) as well.
|
| And yes, type checking is relatively slow, and also
| strictly extra work, since it's not required to make your
| code runnable.
|
| You'll often see that people do still do a more thorough
| production build in their CI systems, but not necessarily
| by using a bundler that includes type checking; rather,
| they just run type checking and bundling as separate
| tasks. That way, you do indeed get all the verification
| you would like without having to delay deployment.
|
| (To make it somewhat more confusing, a project like Vite
| _does_ use a fast bundler (ESBuild) during development
| and a more thorough one for production (Rollup), but that
| 's independent of type checking. It's more about the
| latter doing more optimisations, and the former merely
| making the code runnable by the browser.)
| EugeneOZ wrote:
| It's not a linter, far from it.
| Sammi wrote:
| I downvoted you because that's not what was said.
| EugeneOZ wrote:
| Appreciate the explanation.
|
| But:
|
| > Consider TypeScript like a linter
| samhw wrote:
| There's a difference between _is a linter_ and _is like a
| linter [in this context]_.
| nsonha wrote:
| 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.
| dkdbejwi383 wrote:
| `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.
| RobertKerans wrote:
| 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
| kitd wrote:
| 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`
|
| to type check before the build.
| EugeneOZ wrote:
| 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.
| simlevesque wrote:
| Did you reply to the wrong comment ? The --noEmit does
| not have the issue you talk about.
| EugeneOZ wrote:
| yes, sorry
| sandGorgon wrote:
| has anyone used this in react-native ?
| dstaley wrote:
| Pretty sure the Expo folks are working on this!
| sandGorgon wrote:
| 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
| Salu3 wrote:
| salu2
| KingOfCoders wrote:
| 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.
| CodeIsTheEnd wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| [deleted]
| DrBazza wrote:
| I understand what you're saying, but I'd still argue that
| they're supremely familiar with their toolchain, and have
| a deep understanding of the problems they're trying to
| solve. My comment said they've _usually_ solved the
| problem at least once already, but I don 't discount
| people solving new problems.
| ksec wrote:
| 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 wrote:
| 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.
| moron4hire wrote:
| 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.
| hn_throwaway_99 wrote:
| I totally agree with you, but I also love the context of
| this quote with your username ;)
| leetrout wrote:
| 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.
| l30n4da5 wrote:
| Agreed. I think most developers find themselves more
| productive on their side projects than they are in the
| workplace because there is less overhead.
| depr wrote:
| 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'.
| ZephyrBlu wrote:
| The thing is that people tend to appear to think it's
| black magic rather than familiarity with a toolset and a
| deep understanding of the problem.
| xeromal wrote:
| That's not all it is. Some people are just better than
| others. No matter how hard every tries to be the best
| football or basketball player, only an extremely small
| set of people even have the chance to make it. There are
| physical traits they'll never have and mental fortitude
| to use those traits. You can't grow yourself to 7 ft tall
| and you never will be able to. What makes you think the
| brain is any different.
| ZephyrBlu wrote:
| If you take the perspective that some people are "just
| better" than others, why are we idolizing these people?
|
| Being born with high intelligence and favourable traits
| is not an achievement.
| tengbretson wrote:
| > If you take the perspective that some people are "just
| better" than others, why are we idolizing these people?
|
| Good question. Take it up with the people wearing
| jersey's with Lebron James' and Aaron Rodgers' names on
| them.
| xeromal wrote:
| lol, yeah. I don't idolize them. I'm just aware of my
| limitations.
| DrBazza wrote:
| I wish I could upvote this more, because it's proven by a
| couple of the other replies to my original comment.
| hn_throwaway_99 wrote:
| Baloney. I don't think it's "black magic", but as a
| software engineer with some deep familiarity with my tool
| chain I'm not going to pretend that I could ever be as
| productive as some of these folks. It's like when I see
| another post about a Fabrice Bellard project, and I think
| "he gets done in a year what it would take me about a
| career".
|
| I don't understand this fetishization of "everyone has
| nearly equal ability" in the face of tons of overwhelming
| evidence to the contrary.
| ZephyrBlu wrote:
| I don't believe everyone has the same ability. What I do
| believe is that performance is explainable and there's a
| practical upper limit to raw output.
|
| I made a side project that I spent 1-2years building on
| and off and had people saying "wow I could never build
| that". That's bullshit. If they were of similar
| intelligence and put in a similar amount of time and
| effort I'm sure they'd be able to replicate what I did.
|
| The luxury of being able to spend ample amounts of time
| on a project or idea is also massively overlooked.
| cj wrote:
| > 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)
| DrBazza wrote:
| > Is this a bad thing to discourage?
|
| No. It's what I encourage people in my team to do all the
| time. In fact it's something I was also encouraged to do.
|
| The full quote was:
|
| "Become an expert in at least one thing in your job or
| preferably career, and do it while you have the time"
| (e.g. when you're junior and expectations are low, or not
| a manager).
| BiteCode_dev wrote:
| Sure, like anyone can be Usain Bolt if they are familiar
| with their body and has a deep understanding of running.
| chakkepolja wrote:
| 10xer is not about churning out code.
|
| "Why is DJ Bernstein so great? I too can churn out CRUD
| apps very fast in ruby rails" - some webshit says this
| every day on HN.
| DrBazza wrote:
| That's a bit of a strawman. My full comment is that being
| familiar with your language of choice, and having a deep
| understanding of a problem means that can produce a
| solution faster than someone that doesn't. I used the
| phrase 'churn out', I could have simply said 'produce'.
|
| I've worked in the industry for almost 30 years, and I've
| worked with a lot of people in that time. Those that you
| might qualify as '10x', all have had both of the
| qualities I mention.
|
| I would not expect any of those people to switch
| languages and fields and still be a '10x' developer.
| true_religion wrote:
| But isn't what you said a bit of a straw man too? Back in
| the music comparison, no one would expect an excellent
| guitarist to take up playing piano and still be a
| virtuoso.
|
| And yet... we do recognize that some people are
| impressively better than others at playing piano, running
| yards, fighting, and all sorts of other narrowly specific
| tasks.
|
| It's just that the more creative the task, the harder it
| to measure how much better someone is.
| atonse wrote:
| I would. Languages aren't as important as you would
| think. Certain people can pick up the new idioms quickly
| and run with it.
|
| Look at someone like Yehuda Katz. Substantial
| contributions in ruby (merb, bundler), JS (jQuery core
| team, created Ember.js), and rust (created cargo).
|
| But trying to elevate him or make him uncomfortable (he's
| also a really humble dude), but just saying there are
| examples of polyglots that make substantial
| contributions.
| wetmore wrote:
| Calling people "webshits" is not really in the spirit of
| HN imo.
| todotask wrote:
| 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.
| marton78 wrote:
| 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 wrote:
| and he's building tools to optimize his teams.
| hn_throwaway_99 wrote:
| > 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.
| ZephyrBlu wrote:
| 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 wrote:
| 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.)
| pixelrevision wrote:
| The tool is likely helping Figma pretty directly by cutting
| developer build times.
| zerocount wrote:
| Maybe there's not much to do as the CTO of Figma. Throwing
| time into Esbuild doesn't mean he's neglecting his CTO
| duties.
| ZephyrBlu wrote:
| In which case my last option would be relevant:
|
| > _or his output is actually not as high as it looks_
| fvdessen wrote:
| Frankly most of us would not be able to create esbuild
| even with all the time in the world.
| betageek wrote:
| 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 wrote:
| So working a shit ton then.
| atonse wrote:
| 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 wrote:
| Same
| Aeolun wrote:
| Sounds like he solved his own problem?
| ksec wrote:
| 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 wrote:
| The numbers seem cherry picked though, I don't like this type
| of 197.96432100004x faster claims.
| eyelidlessness wrote:
| 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 wrote:
| Granted, those stats are for JSX, but it'll be interesting to
| check out for sure.
| moron4hire wrote:
| 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?
| louissm_it wrote:
| 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
| deergomoo wrote:
| 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 wrote:
| You can use esbuild to your existing rails apps via the gem
| jsbundling-rails https://github.com/rails/jsbundling-rails
|
| It works really well
| d3nj4l wrote:
| 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
| louissm_it wrote:
| 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 :)
| lovely_koala wrote:
| Looks awesome! I'm gonna use it!
| ianberdin wrote:
| 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 wrote:
| You knew how to speed up webpack 5-10 times by setting
| cache.type = 'filesystem', right?
| eezing wrote:
| Deno is using this: https://github.com/swc-project/swc
| ep103 wrote:
| Anyone able to compare this to Vite?
| Aeolun wrote:
| Vite uses esbuild I think. But the concepts are different.
| armincerf wrote:
| Vite uses Esbuild for development builds, and they have an
| answer for why they don't use it for prod builds here
| https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
| kohlerm wrote:
| That's old news or? For complex projects moving to esbuild from
| say Webpack is not necessarily easy.
| onion2k wrote:
| _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.
| oliyoung wrote:
| its also surprisingly easy, much easier than you'd expect
| sAbakumoff wrote:
| from my PoV Vite.js is much more mature project than esbuild
| maga wrote:
| 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.
| lawn wrote:
| > 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!
| ljm wrote:
| The process is cyclical.
|
| Make, Cmake and autoconf offered solutions in this space, but
| for C/C++.
|
| I do like what esbuild and swc are doing though.
| xeromal wrote:
| Has anyone given you crap for your username? I know you had the
| username long before MAGA became a popular word in the american
| lexicon, but I'm still curious!
| maga wrote:
| Yeah, the funny part is that I have never even been to US of
| A let alone having anything in common with the said movement.
| No, to be honest, I don't recall anyone mentioning it here on
| HN or GitHub. I don't use other social media, though, I guess
| it would be more of an issue there. However, I was wrongly
| suspended on Twitter once despite not posting (or even
| "liking") anything the whole decade of being there. I just
| used the account for OAuth subscription, one day it stopped
| working, I had to write a letter and wait for manual
| "unsuspension.
|
| I chose my now "nom de plume" way back in zeros for its
| seeming originality and simplicity, when compared to my
| rather common and unwieldy "real" Polish name.
| [deleted]
| theptip wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jscambrian wrote:
| I survived the JavaScript Cambrian explosion and all I
| got was a disenchantment with computer programming
| mpd wrote:
| To me, it feels like the same effect as Ruby ~15-10 years
| ago. Lots of chaos as good (subsequently winnowed down to
| preferred), patterns were discovered, and then things
| stabilized. It isn't sexy anymore, but to this day I've
| yet to discover a better tool, that lets me blast out
| features and make changes at rapid pace, than Ruby (and
| Rails on the web side).
| theptip wrote:
| 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.)
| phist_mcgee wrote:
| >when everybody starts using wasm
|
| I would say this is a far off possibility. The need to
| write WASM code rarely surfaces for the average SPA, and
| really seems like its more applicable to games or sites
| with heavy processing needs.
|
| For better or worse, it's going to be JS/TS for a long
| while yet.
| eyelidlessness wrote:
| ESBuild's author and docs[1] are quite clear about its future
| scope:
|
| > [... a list of features that are already done...]
|
| > After that point, I will consider esbuild to be relatively
| complete. I'm planning for esbuild to reach a mostly stable
| state and then stop accumulating more features. This will
| involve saying "no" to requests for adding major features to
| esbuild itself. I don't think esbuild should become an all-
| in-one solution for all frontend needs. In particular, I want
| to avoid the pain and problems of the "webpack config" model
| where the underlying tool is too flexible and usability
| suffers.
|
| That said, now quoting you...
|
| > But we tried "compose tools in the Unix way" with grunt
| too, and that led to spaghetti scripts, unique to each
| project, that were hard to reason about.
|
| In this respect, ESBuild's firm stance has a major strength,
| and a major weakness:
|
| - Strength: the Unix philosophy is easy to achieve, with
| esbuild-plugin-pipe[2]. There's just one, simple plugin API,
| everything follows that same format
|
| - Weakness: since ESBuild doesn't expose its AST, plugins are
| often slow which can undermine the benefits of the tool
|
| 1: https://esbuild.github.io/faq/#upcoming-roadmap
|
| 2: https://github.com/nativew/esbuild-plugin-pipe
| imbnwa wrote:
| > 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.
| shakezula wrote:
| The Convention Over Configuration crowd has their arguments.
| tengbretson wrote:
| > 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.
| Epskampie wrote:
| I really don't, webpack config was was a cluster&EUR@ from
| day 1. Also, webpacks goal always was to do everything and
| the kitchen sink, much different from esbuild.
| josteink wrote:
| 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.
| praveenperera wrote:
| > 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!
| sesm wrote:
| I guess build times were a real issue for Figma and it
| started as an internal project.
| _fat_santa wrote:
| 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.
| capableweb wrote:
| I'm not so sure about that as you. Not all companies are
| like Google and "steal" the credit of work done by
| employees, even if done on work time but unrelated to the
| core business. Plenty of companies let employees work on
| open source and still remain the owners of the software
| produced.
| btown wrote:
| 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 wrote:
| He seems to like writing code
| chipsambos wrote:
| Ironically, the Figma tagline is "Nothing great is made
| alone"
| Cyph0n wrote:
| What in the world? And some say 10x engineers don't exist...
| sesm wrote:
| 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 wrote:
| 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_to
| olk...
|
| [5] https://redux-toolkit.js.org/rtk-query/overview
|
| [6] https://redux.js.org/tutorials/essentials/part-7-rtk-
| query-b...
| [deleted]
| seumars wrote:
| God bless Evan Wallace
| baxuz wrote:
| 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 wrote:
| 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.
| hashkb wrote:
| 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.
| magerleagues wrote:
| This looks promising: https://github.com/pradel/create-react-
| app-esbuild
| Aeolun wrote:
| > 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 wrote:
| 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.
| antihero wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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' },
| ] }, })
| brightball wrote:
| 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.
| throw_m239339 wrote:
| 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 wrote:
| 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 wrote:
| > 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...
| phinnaeus wrote:
| I certainly didn't.
|
| > If you're going to use a JS bundler written in Go, just
| stick to MAKEFILE...
|
| What?
| innocenat wrote:
| dist.js: $(wildcard *.js) cat $? > dist.js
|
| Like this?
| Intrepidd wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-14 23:01 UTC)