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
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.26 0.28 0.31 1.0×
ESLint 33.88 35.69 37.32 126.4×
ESLint + Vue plugin 36.84 37.69 38.20 133.5×
Flow 50.14 50.55 51.30 179.1×
ESLint + TypeScript plugin 49.44 50.56 52.02 179.1×
ESLint + React plugin 56.31 56.89 57.75 201.5×
ESLint + Airbnb rules 125.45 126.25 127.38 447.2×
TypeScript 172.80 185.62 205.68 657.6×
Deno (no linting) 264.95 265.96 267.19 942.2×
Deno 265.37 267.44 268.39 947.4×

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
ESLint + TypeScript plugin
Flow
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.32 0.35 1.0×
RSLint 19.99 20.07 20.20 62.4×
ESLint 33.89 35.35 37.57 110.0×
ESLint + Vue plugin 36.12 37.36 38.12 116.3×
ESLint + TypeScript plugin 49.08 49.94 51.23 155.4×
Flow 49.80 49.98 50.27 155.6×
ESLint + React plugin 55.73 56.31 57.17 175.3×
ESLint + Airbnb rules 124.19 125.81 127.59 391.5×
TypeScript 130.16 160.23 188.14 498.6×
Deno (no linting) 260.68 261.65 262.72 814.3×
Deno 263.55 265.05 266.19 824.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 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).