quick-lint-js

Find bugs in JavaScript programs.

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

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
Flow
ESLint
ESLint + Vue plugin
ESLint + TypeScript plugin
ESLint + React plugin
ESLint + Airbnb rules
TypeScript
Deno (no linting)
Deno
response time (lower is better)
linter response time (milliseconds)
min avg max ÷ qljsquick-lint-js
quick-lint-js 0.30 0.70 1.16 1.0×
Flow 3.09 3.66 4.44 5.3×
ESLint 33.81 34.89 35.79 50.1×
ESLint + Vue plugin 35.66 36.81 37.64 52.9×
ESLint + TypeScript plugin 49.46 50.84 51.61 73.0×
ESLint + React plugin 55.40 56.66 57.68 81.4×
ESLint + Airbnb rules 124.50 125.94 127.06 181.0×
TypeScript 138.47 157.90 170.84 226.9×
Deno (no linting) 287.07 295.23 304.19 424.2×
Deno 312.76 324.78 338.54 466.6×

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: 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
Deno (no linting)
Deno
response time (lower is better)
linter response time (milliseconds)
min avg max ÷ qljsquick-lint-js
quick-lint-js 0.31 1.09 1.29 1.0×
RSLint 20.01 20.05 20.15 18.3×
ESLint 34.15 34.43 34.95 31.5×
ESLint + Vue plugin 35.21 36.64 37.75 33.5×
Flow 50.01 50.26 50.86 46.0×
ESLint + TypeScript plugin 48.92 50.31 51.00 46.0×
ESLint + React plugin 55.29 56.66 57.98 51.8×
ESLint + Airbnb rules 125.34 125.80 126.95 115.0×
TypeScript 151.01 167.66 187.52 153.3×
Deno (no linting) 290.09 296.65 304.01 271.3×
Deno 298.38 317.18 333.98 290.0×

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:

These benchmarks were measured on the following machine:

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