%- await include("../common-head.ejs.html", { title: `JS linter
benchmarks`, description: `quick-lint-js is faster than any other JavaScript
linter.` }) %>
<%- await include("../common-nav.ejs.html") %>
Which JavaScript linter is the fastest and consumes the
least energy? We benchmarked different JavaScript
linters to give you the answer.
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.
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.
Add or remove a few characters in the document, sending small
deltas in an LSP message.
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.
Change a few characters in the document, sending the entire new
document in an LSP message.
Wait for diagnostics.
Methodology
These benchmarks measure the following linters:
quick-lint-js
version <%= versions["quick-lint-js"]["version"] %> (Debian package)
Rome
version 9be13cac83320929a949201ca462015d5a446dbc (with rustc
version 1.61.1)
RSLint
version v0.3.2 (with rustc version 1.61.1)
Flow
version <%= versions["Flow"]["flow-bin"] %>
ESLint
version v<%= versions["ESLint"]["eslint"] %>
@typescript-eslint/eslint-plugin version <%=
versions["ESLint"]["@typescript-eslint/eslint-plugin"] %>
@typescript-eslint/parser version <%=
versions["ESLint"]["@typescript-eslint/parser"] %>
eslint-plugin-vue version <%=
versions["ESLint"]["eslint-plugin-vue"] %>
<% let vscodeESLintURL = versions["ESLint"]["vscode-eslint"];
let vscodeESLintCommit =
vscodeESLintURL.match(/[0-9a-f]{40}/)[0]; %> vscode-eslint
commit <%= vscodeESLintCommit.substr(0, 20) %><%=
vscodeESLintCommit.substr(20) %>
Node version <%= versions["ESLint"]["node"] %>
Deno
version <%= versions["Deno"]["deno"] %> (with V8 version <%=
versions["Deno"]["v8"] %> and TypeScript version <%=
versions["Deno"]["typescript"] %>)
TypeScript
version <%= versions["TypeScript"]["typescript"] %> (with language
server version <%=
versions["TypeScript"]["typescript-language-server"] %> and Node
version <%= versions["TypeScript"]["node"] %>)
These benchmarks were measured on the following machine:
strager's "straglum"; Purism Librem 13 Version 4 laptop
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).