Frontend Developer Tools
The frontend toolchain is large and changes often, but the categories are stable: something to write code in, something to install packages, something to build, something to keep code consistent, optional type checking, and a way to check browser support. This annotated directory names dependable choices in each category and, more usefully, says what each category is for, so you can assemble a toolchain rather than copy one blindly.
The aim is judgement, not a definitive list, since the specific winners shift year to year while the roles do not.
What you'll learn
Code editors and IDEs
The editor is where you spend the most time, so it is worth configuring well.
Where you write the code
- Visual Studio Code · the de facto standard for frontend work, with a deep extension ecosystem for linting, formatting, and debugging. Its built-in support for the tools below is a large part of why it dominates.
- WebStorm · a full IDE with stronger out-of-the-box refactoring and navigation, worth it for large codebases where those features earn their cost.
Package managers
Every project beyond a single file pulls in dependencies, which a package manager handles.
Installing and locking dependencies
- npm · bundled with Node and the default registry, fine for most projects and the baseline every alternative is compatible with.
- pnpm · faster and far more disk-efficient through a shared content-addressable store, a strong default for new projects.
- Yarn · an established alternative with workspaces and its own resolution model, common in larger monorepos.
Build tools and bundlers
Browsers want optimised files, and a bundler turns your source into them.
From source to shippable files
- Vite · the common modern default, with fast development startup and a sensible production build, suitable for most new apps.
- webpack · the long-standing, highly configurable bundler still found across countless existing projects, worth knowing for maintenance work.
- esbuild and Rollup · esbuild is an extremely fast bundler and transpiler, while Rollup excels at building libraries; several higher-level tools build on both.
Linters and formatters
Consistency across a codebase is automated, not enforced by hand.
Keeping code clean automatically
- ESLint · the standard for catching likely bugs and enforcing code rules, configurable per project and integrated into every major editor.
- Prettier · an opinionated formatter that ends style debates by reformatting code automatically, usually paired with ESLint which handles correctness.
TypeScript and type checking
Types catch a class of errors before the code ever runs.
Adding a safety net
- TypeScript · a typed superset of JavaScript that catches type errors at build time and powers much of the editor autocomplete you rely on, increasingly the default for serious projects.
- JSDoc with type checking · for codebases not ready to migrate, type annotations in comments give much of the benefit with no build change.
Browser compatibility references
Before using a feature, it helps to know who supports it.
Checking what is safe to use
- Can I Use · up-to-date support tables for web platform features across browsers, the quickest way to check whether something is safe to ship.
- MDN Web Docs · the reference for how features behave, with compatibility data on every page. See more in developer learning resources.
Frequently Asked Questions
What build tool should I use for a new frontend project?
Vite is the common modern default, with fast development startup and a sensible production build. webpack remains worth knowing because countless existing projects use it, which matters for maintenance work.
Do I need both ESLint and Prettier?
They do different jobs. ESLint catches likely bugs and enforces code rules, while Prettier formats code consistently. They are usually used together, with Prettier handling style and ESLint handling correctness.
Is TypeScript worth adding to a project?
TypeScript catches type errors at build time and powers much of the editor autocomplete developers rely on, which makes it increasingly the default for serious projects. JSDoc types are a lighter alternative.
How do I check if a web feature is safe to use?
Use Can I Use for up-to-date browser support tables, and MDN Web Docs for how the feature behaves, since each MDN page includes compatibility data. Together they answer most support questions.
Read next: JavaScript SEO tools, or the Resources hub.
Building a SPA?
The SPA developer roadmap shows where these tools fit in the workflow.
Read: SPA Developer Roadmap →