Which JavaScript linter is the fastest and consumes the least energy? We benchmarked different JavaScript linters to give you the answer.

- LSP: incremental-change-wait express-router.js
- LSP: incremental-change-wait react-quickly-ch10.jsx
- LSP: full-change-wait express-router.js
- Methodology
- Comments

## LSP: incremental-change-wait express-router.js

An LSP server is software which plugs into your code editor. It provides diagnostics (error squigglies), go-to-definition, and auto-complete. This benchmark measures how long an LSP server takes to give diagnostics after making a change in a JavaScript file (e.g. after typing a character). In other words, it measures input latency. Lower latency means a faster-feeling editor.

### Results

0 ms 60 FPS 50 ms 100 ms 150 ms 200 ms 250 ms 300 ms 350 ms 0.1 ms 1 ms 10 ms 100 ms 350 ms
quick-lint-js
ESLint
ESLint + Vue plugin
Flow
ESLint + TypeScript plugin
ESLint + React plugin
ESLint + Airbnb rules
TypeScript
TypeScript (JSX parser)
Deno (no linting)
Deno
response time (lower is better)
log scale

linter | response time (milliseconds)
--- | ---
min | avg | max | ÷ qljs quick-lint-js
quick-lint-js | 0.24 | 0.26 | 0.30 | 1.0×
ESLint | 35.87 | 36.82 | 37.31 | 139.9×
ESLint + Vue plugin | 37.20 | 37.77 | 38.41 | 143.5×
Flow | 50.42 | 51.07 | 51.73 | 194.0×
ESLint + TypeScript plugin | 52.23 | 54.22 | 56.65 | 206.0×
ESLint + React plugin | 56.50 | 57.03 | 58.27 | 216.7×
ESLint + Airbnb rules | 105.60 | 107.04 | 109.13 | 406.7×
TypeScript | 153.52 | 186.16 | 206.03 | 707.3×
TypeScript (JSX parser) | 177.44 | 199.01 | 205.18 | 756.1×
Deno (no linting) | 264.76 | 265.94 | 267.64 | 1010.4×
Deno | 266.36 | 267.64 | 268.69 | 1016.9×

### Setup (untimed)

1. Start the LSP server.
2. Wait for initialization to finish.
3. Open one document with contents from express-router.js.
4. Wait for diagnostics.

### Work (timed)

Repeat the following steps N times:

1. Change a few characters in the document, sending small deltas in an LSP message.
2. Wait for diagnostics.

## LSP: incremental-change-wait react-quickly-ch10.jsx

This benchmark measures how long an LSP server takes to give diagnostics to an editor.

This benchmark is similar to the incremental-change-wait benchmark, except it uses a JSX (React) source file instead of a vanilla JavaScript source file.

### Results

0 ms 60 FPS 50 ms 100 ms 150 ms 200 ms 250 ms 300 ms 350 ms 0.1 ms 1 ms 10 ms 100 ms 350 ms
quick-lint-js
Flow
ESLint + React plugin
ESLint + TypeScript plugin
Deno
Deno (no linting)
TypeScript (JSX parser)
response time (lower is better)
log scale

linter | response time (milliseconds)
--- | ---
min | avg | max | ÷ qljs quick-lint-js
quick-lint-js | 0.09 | 0.10 | 0.12 | 1.0×
Flow | 26.58 | 26.88 | 27.18 | 273.2×
ESLint + React plugin | 32.88 | 33.96 | 34.40 | 345.2×
ESLint + TypeScript plugin | 33.55 | 34.58 | 37.28 | 351.6×
Deno | 228.43 | 229.40 | 230.52 | 2331.8×
Deno (no linting) | 229.06 | 229.48 | 230.29 | 2332.6×
TypeScript (JSX parser) | 277.71 | 278.83 | 279.52 | 2834.3×

### Setup (untimed)

1. Start the LSP server.
2. Wait for initialization to finish.
3. Open one document with contents from react-quickly-ch10.jsx.
4. Wait for diagnostics.

### Work (timed)

Repeat the following steps N times:

1. Add or remove a few characters in the document, sending small deltas in an LSP message.
2. Wait for diagnostics.

## LSP: full-change-wait express-router.js

This benchmark measures how long an LSP server takes to give diagnostics to an editor.

This benchmark differs from the incremental-change-wait benchmark in that the editor gives the new version of the file entirely rather than just the incremental changes. This is for compatibility with linters such as RSLint which do not support incremental changes.

### Results

0 ms 60 FPS 50 ms 100 ms 150 ms 200 ms 250 ms 300 ms 350 ms 0.1 ms 1 ms 10 ms 100 ms 350 ms
quick-lint-js
RSLint
ESLint
ESLint + Vue plugin
Flow
ESLint + TypeScript plugin
ESLint + React plugin
ESLint + Airbnb rules
TypeScript
TypeScript (JSX parser)
Deno (no linting)
Deno
response time (lower is better)
log scale

linter | response time (milliseconds)
--- | ---
min | avg | max | ÷ qljs quick-lint-js
quick-lint-js | 0.27 | 0.30 | 0.33 | 1.0×
RSLint | 20.02 | 20.08 | 20.17 | 67.6×
ESLint | 34.01 | 34.64 | 35.11 | 116.6×
ESLint + Vue plugin | 35.62 | 37.22 | 37.89 | 125.3×
Flow | 49.44 | 50.30 | 51.01 | 169.3×
ESLint + TypeScript plugin | 49.95 | 50.85 | 52.69 | 171.2×
ESLint + React plugin | 56.06 | 56.94 | 57.76 | 191.7×
ESLint + Airbnb rules | 105.41 | 106.61 | 107.92 | 358.9×
TypeScript | 130.20 | 167.71 | 213.75 | 564.6×
TypeScript (JSX parser) | 130.36 | 180.89 | 213.53 | 609.0×
Deno (no linting) | 264.85 | 266.21 | 267.83 | 896.2×
Deno | 266.09 | 267.57 | 269.54 | 900.8×

### Setup (untimed)

1. Start the LSP server.
2. Wait for initialization to finish.
3. Open one document with contents from express-router.js.
4. Wait for diagnostics.

### Work (timed)

Repeat the following steps N times:

1. Change a few characters in the document, sending the entire new document in an LSP message.
2. Wait for diagnostics.

## Methodology

These benchmarks measure the following linters:

- quick-lint-js version 2.0.0 (Debian package)
- RSLint version v0.3.0 (with rustc version 1.56.1)
- Flow version 0.171.0
- ESLint version v8.8.0
  - @typescript-eslint/eslint-plugin version 5.11.0
  - @typescript-eslint/parser version 5.11.0
  - eslint-plugin-vue version 8.4.1
  - vscode-eslint commit d3c7703cd11dc6752c96edf0f140d50156d72dd7
  - Node version v17.4.0
- Deno version 1.18.2 (with V8 version 9.8.177.6 and TypeScript version 4.5.2)
- TypeScript version 4.5.5 (with language server version 0.9.6 and Node version v17.4.0)

These benchmarks were measured on the following machine:

- strager's "straglum"; Purism Librem 13 Version 4 laptop
- CPU: Intel Core i7-7500U CPU @ 2.70 GHz (2 cores, 4 threads)
- OS: Linux Mint 20 Ulyana; Linux 5.4.0-42-generic #46-Ubuntu SMP x86_64 GNU/Linux
- Performance governor: performance; 400 MHz - 3.50 GHz

## Comments

### Deno

Deno's LSP server (and thus its Visual Studio Code extension) delays processing by 200 milliseconds. This means that Deno appears to be much slower than it actually is, but this artificial latency does affect the editing experience.

### TypeScript

TypeScript's LSP server (but not its Visual Studio Code extension) delays processing by 200 milliseconds + 50 milliseconds. This means that TypeScript appears to be much slower than it actually is, but this artificial latency does affect the editing experience (in all editors except Visual Studio Code).