esbuild – An extremely fast JavaScript bundler

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • OPS - Build and Run Open Source Unikernels
  • GitHub repo esbuild

    An extremely fast JavaScript and CSS bundler and minifier

    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.

  • GitHub repo swc

    swc is a super-fast compiler written in rust; producing widely-supported javascript from modern standards and typescript.

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • GitHub repo posthtml

    PostHTML is a tool to transform HTML/XML with JS plugins

  • GitHub repo rehype

    HTML processor powered by plugins part of the @unifiedjs collective

  • GitHub repo Snowpack

    ESM-powered frontend build tool. Instant, lightweight, unbundled development. ✌️

    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.

  • GitHub repo parcel

    The zero configuration build tool for the web. 📦🚀

    I think Parcel[0] is what you want for that use-case.[1]

    [0] https://parceljs.org/

    [1] https://parceljs.org/recipes/image/

  • GitHub repo labelflow

    The open platform for image labelling

    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 !

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.

  • GitHub repo vite

    Next generation frontend tooling. It's fast!

    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...

  • GitHub repo redux-toolkit

    The official, opinionated, batteries-included toolset for efficient Redux development

    Yeah, we actually went through this with Redux itself.

    When Redux was first released in 2015, it was deliberately designed to be minimal and extensible. Other Flux libraries at the time had various forms of async handling built in (support for dispatching actions via promises, etc). Dan and Andrew wanted to avoid locking users in to any single form of async handling [0], so the middleware API was designed to let users pick their preferred async approach and syntax.

    Similarly, the store setup process was entirely left up to users to add whatever middleware, enhancers, and other configuration users felt was appropriate. The docs were also always unopinionated about preferred file structures, how to organize logic, etc.

    Over time, it became very clear that users _wanted_ more specific guidance about how to structure their apps, and wanted Redux itself to build in default setup and configuration.

    As a result, we wrote a "Style Guide" docs page [1] that lists our recommended best practices, and created our official Redux Toolkit package [2] as the standard way to write Redux logic. RTK was designed to solve the most common problems and use cases we saw in the ecosystem [3], including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.

    RTK has been extremely successful - we routinely get users telling us how much they enjoy using RTK [4], even if they disliked "vanilla Redux" previously.

    We also recently released a new "RTK Query" API [5] [6] in RTK 1.6, which is a built-in data fetching and caching API inspired by libraries like Apollo and React Query. Again, similar theme - we looked at what users were doing and what pain points they were running into, and built an official API to help address those use cases.

    [0] https://blog.isquaredsoftware.com/2017/09/presentation-might...

    [1] https://redux.js.org/style-guide/style-guide

    [2] https://redux-toolkit.js.org

    [3] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

    [4] https://www.reddit.com/r/reactjs/comments/px6kxy/redux_toolk...

    [5] https://redux-toolkit.js.org/rtk-query/overview

    [6] https://redux.js.org/tutorials/essentials/part-7-rtk-query-b...

  • GitHub repo create-react-app-esbuild

    Use esbuild in your create-react-app for faster compilation, development and tests

  • GitHub repo esbuild-plugin-pipe

    Pipe esbuild plugins output.

    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

  • GitHub repo esbuild-sass-plugin

    esbuild plugin for sass

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts