7 ms·

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

• lawn 5y ago
  > 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!
• baxuz 5y ago
  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.
  • Aeolun 5y ago
    > 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 5y ago
      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.
  • brainbag 5y ago
    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 5y ago
    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 5y ago
    This looks promising: https://github.com/pradel/create-react-app-esbuild https://github.com/pradel/create-react-app-esbuild
• antihero 5y ago
  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.
  • maga 5y ago
    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 5y ago
      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' }, ] }, })
  • Rapzid 5y ago
    There is a short paragraph adressing this on the "Why Vite" page: https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild 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.
• praveenperera 5y ago
  > 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!
  • kyawzazaw 5y ago
    Massively impressive!
  • sesm 5y ago
    I guess build times were a real issue for Figma and it started as an internal project.
    • _fat_santa 5y ago
      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 5y ago
        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.
  • chipsambos 5y ago
    Ironically, the Figma tagline is "Nothing great is made alone"
  • btown 5y ago
    Figma's tech is mindblowing. Their entire engine is custom-built in C++ : https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/ 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!
• seumars 5y ago
  God bless Evan Wallace
• brightball 5y ago
  This is exactly why the Elixir Phoenix team switched from Webpack to esbuild as the new default. They were spending more time responding to Webpack issues than Phoenix issues and it was an endless time sink.
• sesm 5y ago
  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 5y ago
    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-need-redux-ecosystem/ https://blog.isquaredsoftware.com/2017/09/presentation-might... [1] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide [2] https://redux-toolkit.js.org https://redux-toolkit.js.org [3] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/ https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [4] https://www.reddit.com/r/reactjs/comments/px6kxy/redux_toolkit_is_awesome/ https://www.reddit.com/r/reactjs/comments/px6kxy/redux_toolk... [5] https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview [6] https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics https://redux.js.org/tutorials/essentials/part-7-rtk-query-b...
• 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.
  • shakezula 5y ago
    The Convention Over Configuration crowd has their arguments.
  • 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.
    • josteink 5y ago
      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.
  • eyelidlessness 5y ago
    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 https://esbuild.github.io/faq/#upcoming-roadmap 2: https://github.com/nativew/esbuild-plugin-pipe https://github.com/nativew/esbuild-plugin-pipe
• xeromal 5y ago
  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 5y ago
    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 5y ago
    [deleted]
• ljm 5y ago
  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.