# The Best JavaScript Dev Tools in 2022

A breakdown of the most important JS dev tools in 2022, including their most relevant tradeoffs, and some opinionated advice sprinkled on top.

Canonical URL: https://www.transitivebullsh.it/javascript-dev-tools-in-2022

Author: Travis Fischer

Published: 2022-03-31

Updated: 2026-09-15T17:15:00.000Z

Tags: Web Dev, Node.js, Software Development, TypeScript, JavaScript

![The Best JavaScript Dev Tools in 2022](<https://assets.cultural-alignment.com/personal-site/media/8b86e9228b7dc03f4d7aa28ddaabeb62b0d2d5cdc4347869c1359fd1f109e513.jpg>)

In the world of software engineering, it’s important to have a firm understanding of the tools at your disposal.

But the landscape of JS tooling is always changing at such a rapid pace.

And 2022 is no different.

So I decided to break down the most important dev tools that you should be aware of in 2022.

We’ll start with the lowest-level tools and work our way up to higher-level tools from there. Let’s get started 💪



<a id="b080a09cb46d45aaaa4e64b3edb7652f"></a>

## Compilers

Compilers are responsible for transforming your input code into some target output format. For our purposes, we’re focusing on compilers which support transpiling modern JavaScript and TypeScript into specific versions of ECMAscript that are compatible with browsers and recent versions of Node.js.

| [babel](<https://babeljs.io/>) | JS compiler (TS w/ plugin) | JS | MIT | very mature | slow | 40700 |
| --- | --- | --- | --- | --- | --- | --- |
| [esbuild](<https://esbuild.github.io/>) | Fast JS / TS compiler | Go | MIT | mature | fast | 31200 |
| [swc](<https://swc.rs/>) | Fast JS / TS compiler | Rust | Apache 2.0 | mature | fast | 21300 |
| [tsc](<https://www.typescriptlang.org/docs/handbook/compiler-options.html>) | Official TS compiler | TS | Apache 2.0 | very mature | slow | 79300 |

The most important thing to understand about this space is that it’s in the middle of undergoing a massive shift from compilers like [tsc](<https://www.typescriptlang.org/docs/handbook/compiler-options.html>) and [babel](<https://babeljs.io/>), which are written in higher-level interpreted languages, to compilers like [swc](<https://swc.rs/>) and [esbuild](<https://esbuild.github.io/>), which are written in much faster, compiled languages.

This shift results in **10-100x faster compilation times** as shown in this esbuild demo.

![Source: esbuild](<https://assets.cultural-alignment.com/personal-site/media/29d889f10e3ad07a7989c71fbae98eb2efa4bf89aa149eb3292cd1a3746bdc84.png>)

Source: [esbuild](<https://esbuild.github.io/>)

If you’re updating your devtools stack or starting a new project in 2022, then you’ll want to consider using one of these next-gen compilers under the hood. They may not be as mature as the official typescript compiler or babel, but the benefits of having 100x faster builds cannot be understated.

Note that neither swc nor esbuild perform type checking. They simply transpile code into the desired output format as quickly and efficiently as possible. For the time being, if you’re working with TypeScript, you’ll almost always need to have the official TypeScript compiler as part of your toolchain to guarantee that you’re getting the most out of TypeScript’s static type checking. It’s also worth mentioning that the author of swc, [kdy1dev](<https://twitter.com/kdy1dev>) is working on [porting tsc to Go](<https://kdy1.dev/posts/2022/1/tsc-go>) in order to remove the need for tsc in many cases, as it tends to be the bottleneck in most toolchains.



<a id="5edc88a63e734e22b830205d520f8d32"></a>

### SWC vs esbuild

` swc ` and ` esbuild ` are both excellent, blazing fast, open source JS / TS compilers. They have [comparable performance](<https://datastation.multiprocess.io/blog/2021-11-13-benchmarking-esbuild-swc-typescript-babel.html>) and are both used regularly in production by some of the world’s largest companies.

It’s likely that your choice between the two will be dictated more by the higher-level tools built on top of these compilers as opposed to choosing between them directly.

Notable projects using ` swc `:

- [Vercel and Next.js](<https://nextjs.org/docs/advanced-features/compiler>)
- [Deno’s linter, formatter, and docs](<https://twitter.com/devongovett/status/1369033422002389000>)
- [Parcel](<https://parceljs.org/>)
- [nx](<https://github.com/nrwl/nx>)

Notable projects using ` esbuild `:

- [Vite](<https://vitejs.dev/>)
- [Nuxt.js](<https://nuxtjs.org/>)
- [Remix](<https://github.com/remix-run/remix>)
- [SvelteKit](<https://kit.svelte.dev/>)
- [tsup](<https://tsup.egoist.sh/>)



> In software engineering, convenient statements such as “technology A is better than technology B” rarely hold much value. Rather, you should try to always keep context in mind. In this case, there are many scenarios where you’d be better off using ` tsc ` or ` babel `.
> 
> Becoming a better software engineer often boils down to thoroughly understanding the tradeoffs involved with these types of decisions, and balancing those tradeoffs against the particular constraints of your project, team, and business’ needs.



<a id="2ef8936d85b04a3980e88bd14c6be441"></a>

## Bundlers

![Source: Webpack](<https://assets.cultural-alignment.com/personal-site/media/3fa3025e17645471f1938ea31f7aa90d16dafc2c4d1f8aa0899dc733b37791ae.png>)

Source: [Webpack](<https://webpack.js.org/>)

Bundlers are responsible for taking all of your input source files and bundling them together into an easy-to-consume output format. The two most common use cases for bundlers are bundling libraries and bundling resources for web applications.

| [Parcel](<https://parceljs.org/>) | swc | Zero-config build tool for the web | MIT | web apps, libraries | 41000 |
| --- | --- | --- | --- | --- | --- |
| [Rollup](<https://rollupjs.org/>) | babel, tsc, swc, esbuild | Bundler aimed at libraries | MIT | libraries | 21400 |
| [Webpack](<https://webpack.js.org/>) | babel, tsc, swc, esbuild | Industry standard bundler | MIT | web apps, libraries | 60100 |

Bundlers like ` webpack ` and ` rollup ` are the swiss-army knives of modern JS toolchains. They are both extremely extensible, with well-maintained plugins covering major use cases. It’s relatively straightforward, for example, to use any of the popular compilers listed above to transpile TS code with either webpack or rollup.

[Parcel](<https://parceljs.org/>), on the other hand, provides a mostly zero-config approach to bundling. It focuses on simplicity as opposed to extensibility and uses ` swc ` as a compiler under the hood.

Note that ` swc ` and ` esbuild ` both provide basic bundling capabilities as well, though compared with these alternatives, they’re not full-featured enough to be included on this list.

For a much more detailed comparison of these bundlers, check out [tooling.report](<https://bundlers.tooling.report/>).



<a id="c69ac462d6104ef7934357580e756da6"></a>

## Package Managers

[Package managers](<https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Package_management>) are responsible for managing dependencies in the form of [NPM](<https://npmjs.com/>) packages.

| [npm](<https://github.com/npm/cli>) | The default package manager for JS | Artistic License 2.0 | 5700 |
| --- | --- | --- | --- |
| [pnpm](<https://pnpm.io/>) | Fast, disk space efficient package manager | MIT | 16100 |
| [yarn berry](<https://yarnpkg.com/>) | Fast, reliable, secure dependency management | BSD-2 | 4900 |
| [yarn classic](<https://classic.yarnpkg.com/en/>) | Yarn v1; entered maintenance mode in 2020 | BSD-2 | 40600 |

There’s a [lot of history](<https://blog.logrocket.com/javascript-package-managers-compared/>) here, but the TL;DR is:

- All of these package managers have similar features and perf nowadays, so don’t be too worried about which one you’re using.
- [pnpm](<https://pnpm.io/>) seems to be gaining a lot of traction very quickly. 💪
- The way yarn berry was rolled out and the subsequent deprecation of yarn v1 turned a lot of people off from using yarn, though yarn berry has come a long way in the past few years.
- [yarn plug’n’play](<https://yarnpkg.com/features/pnp>) is an interesting approach, but in practice, it has only seen adoption in cases with very large monorepos.

  - I can’t tell you the number of times I’ve wanted to inspect or add console.log statements to my ` node_modules `, and not being able to do so is a real disadvantage.

<a id="7d46060d94a545c680a5030506bf8267"></a>

### Adoption by popular projects

![A breakdown of the package managers chosen by popular projects. This image is from Sebastian Weber’s excellent package manager deep dive. Note that at the time of this writing, none of these projects are using Yarn PnP.](<https://assets.cultural-alignment.com/personal-site/media/2872c17e79c2e6d895174a94afb2e76e28088358d154cb4b596a5edb07ef0a77.jpg>)

A breakdown of the package managers chosen by popular projects. This image is from [Sebastian Weber](<https://twitter.com/doppelmutzi>)’s excellent [package manager deep dive](<https://blog.logrocket.com/javascript-package-managers-compared/>). Note that at the time of this writing, none of these projects are using Yarn PnP.



<a id="823feddaa1bb4edea19042852b0a5b54"></a>

## Library Development

These tools are meant to help library authors bundle and publish modern NPM packages.

| [microbundle](<https://github.com/developit/microbundle>) | rollup | babel | Zero-config bundler for tiny modules | MIT | 6800 |
| --- | --- | --- | --- | --- | --- |
| [nx](<https://github.com/nrwl/nx>) | rollup, webpack | swc | Smart, Fast and Extensible Build System |  | 11800 |
| [preconstruct](<https://github.com/preconstruct/preconstruct>) | rollup | babel | Dev and build your code painlessly in monorepos | MIT | 720 |
| [tsdx](<https://tsdx.io/>) | rollup | babel | Zero-config CLI for TS package development | MIT | 9500 |
| [tsup](<https://tsup.egoist.sh/>) | rollup | esbuild | Fast TypeScript library bundler powered by [esbuild](<https://esbuild.github.io/>) | MIT | 1800 |
| [unbuild](<https://github.com/unjs/unbuild>) | rollup | esbuild | Unified javascript build system | MIT | 440 |
| [Vite](<https://vitejs.dev/guide/build.html#library-mode>) | rollup | esbuild | Next generation frontend tooling ([library mode](<https://vitejs.dev/guide/build.html#library-mode>)) | MIT | 40000 |

If you’re developing a new library in 2022, you’ll likely want to use one of these higher-level tools to simplify your workflow.

- If you have a TS package and want to take advantage of extremely fast build times courtesy of [esbuild](<https://esbuild.github.io/>), then [tsup](<https://tsup.egoist.sh/>) is a great option.
- If you have a TS package and need some additional features, then [tsdx](<https://tsdx.io/>) is a great option.
- If you have a TS or JS package, then [microbundle](<https://github.com/developit/microbundle>) is also a great option.
- [Vite](<https://vitejs.dev/>) is mainly a tool for building frontend web apps, but it also includes support for [outputting libraries](<https://vitejs.dev/guide/build.html#library-mode>) and is a very solid all-around option.
- For monorepos, [nx](<https://github.com/nrwl/nx>) looks really promising.

My personal preference will be to use [tsup](<https://tsup.egoist.sh/>) for TS packages, mainly because once you’ve experienced 100x faster builds, it’s really difficult to consider switching back to anything else.

<a id="e99d539ab9e24f3da474321cf7177d86"></a>

### More Info

Most of these tools don’t currently provide great support for TS monorepos which take advantage of [composite project references](<https://www.typescriptlang.org/docs/handbook/project-references.html>). For the time being, my recommendation for this case is to use ` tsc ` for type checking and generating ` .d.ts ` typings (with ` emitDeclarationOnly: true `) and ` tsup ` for compiling code in each of the sub-packages. For an example of this approach, check out the [react-notion-x](<https://github.com/NotionX/react-notion-x>) monorepo (one of my OSS projects).

Publishing modern NPM packages is a nuanced topic that goes well beyond the scope of this article. For more info on ESM, commonjs, dual-package publishing, exports, and more see:

- [What does it take to support Node.js ESM?](<https://www.the-guild.dev/blog/support-nodejs-esm>)
- Sindresorhus’ notes on [publishing](<https://github.com/sindresorhus/meta/discussions/15>) and [consuming](<https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c>) ESM packages



<a id="f2dc15819a65412a978bcfdb5c2ae13e"></a>

## Web App Development

These higher-level tools and frameworks are intended to help developers build modern web applications without worrying about all the details.

| [Create React App](<https://create-react-app.dev/>) | webpack | babel | Modern web apps with one command | react | MIT | 94000 |
| --- | --- | --- | --- | --- | --- | --- |
| [Next.js](<https://nextjs.org/>) | webpack | swc | The React framework for production | react | MIT | 84000 |
| [Nuxt.js](<https://nuxtjs.org/>) | rollup | esbuild | The intuitive Vue framework | vue | MIT | 39000 |
| [Parcel](<https://parceljs.org/>) | custom | swc | Zero-config build tool for the web | react, vue | MIT | 41000 |
| [Remix](<https://github.com/remix-run/remix>) | custom | esbuild | Full stack react web framework | react | MIT | 15100 |
| [Snowpack](<https://www.snowpack.dev/>) | custom | esbuild | ESM-powered frontend build tool | react, vue, svelte | MIT | 20000 |
| [SvelteKit](<https://kit.svelte.dev/>) | rollup | esbuild | The fastest way to build Svelte apps | svelte | MIT | 7700 |
| [Vite](<https://vitejs.dev/>) | rollup | esbuild | Next generation frontend tooling | react, vue, svelte | MIT | 40000 |

If you’re developing a new web app in 2022 using [React](<https://reactjs.org/>), then I would highly recommend using [Next.js](<https://nextjs.org/>). It has the best support, the most active community, and close integration with [Vercel](<https://vercel.com/>), the world’s leading deployment platform for modern web apps.

[Remix](<https://remix.run/blog/remix-vs-next>) provides a really compelling alternative to Next.js. It’s from the makers of [react-router](<https://github.com/remix-run/react-router>), and though it’s relatively new, they’re definitely a framework to keep an eye on.

If you’re developing a new web app using [Vue](<https://vuejs.org/>), then [Nuxt.js](<https://nuxtjs.org/>) and [Vite](<https://vitejs.dev/>) are both great options.

And last, but certainly not least, if you want something more light-weight, then give [Parcel](<https://parceljs.org/>) a try. 🤗

> There seems to be a roughly equal number of projects building on top of ` swc ` and ` esbuild `. The same observation goes for ` webpack ` and ` rollup `.



<a id="9ac4b2a8445b4024a8f8be240ca2e1d3"></a>

## Conclusion

Modern web development has evolved significantly over the past 10 years. Developers today are lucky to have such a wide range of amazing, well-maintained tools to choose from.

This is, however, by no means a comprehensive list of dev tools. If there’s something missing that you’d like to see added, let me know on [twitter](<https://twitter.com/transitive_bs>).

Hopefully this breakdown has helped you parse the most important aspects of the current JS / TS dev tools landscape, and hopefully it’ll help you to make more informed decisions going forwards.



<a id="1589d40c3dc4451294d5cab5cc91c8f9"></a>

### Resources

[The State of JS 2021: Libraries](<https://2021.stateofjs.com/en-US/libraries/>)

The 2021 edition of the annual survey about the latest trends in the JavaScript ecosystem.

[JavaScript package managers compared: npm, Yarn, or pnpm? - LogRocket Blog](<https://blog.logrocket.com/javascript-package-managers-compared/>)

With the spate of popular JavaScript package managers reaching relative feature parity, it's time to compare: npm, Yarn, or pnpm?