Comparison
Rams vs ESLint
ESLint checks whether your code is correct. Rams checks whether your interface is good. Different jobs — and they work best together.
ESLint is a static analysis tool for JavaScript and TypeScript: it catches syntax errors, enforces code style, flags unused variables, and warns about likely bugs. It is essential, fast, and runs on every file in your project.
Rams is a design reviewer. It reads the same source files, but it is looking for something ESLint was never built to find: design-quality problems in the rendered UI. Visual hierarchy that breaks, hardcoded colors that bypass your design system, inconsistent spacing, missing interaction states, and the specific patterns that AI code generators leave behind.
Rams vs ESLint, side by side
| Dimension | Rams | ESLint |
|---|---|---|
| What it checks | Design quality of the rendered UI | JavaScript/TypeScript correctness and style |
| Catches accessibility issues | Yes — WCAG 2.2, contrast, focus, touch targets, semantics | Only with eslint-plugin-jsx-a11y, and only static JSX rules |
| Visual hierarchy & layout | Yes | No |
| Design-system / token violations | Yes — flags hardcoded hex, arbitrary spacing | No |
| AI-generated "slop" patterns | Yes — a dedicated category | No |
| Inline one-click fixes | Yes — GitHub suggestions on the PR | Autofix in editor / CLI (--fix) |
| Where it runs | On every pull request, no config | Editor, pre-commit, CI — needs config |
| Output style | Reads like a senior designer’s review | Rule IDs and line warnings |
Use Rams when you want to…
- Catching design and accessibility problems before they ship
- Enforcing a design system across a team without manual review
- Reviewing AI-generated UI code for quality, not just correctness
- Getting a design-aware second opinion on every PR
Use ESLint when you want to…
- Enforcing code style and formatting
- Catching syntax errors and likely bugs
- Fast, local feedback in the editor as you type
- Project-wide linting on every file
The bottom line
This is not an either/or. Keep ESLint for code correctness — it is the right tool for that. Add Rams for design quality, which ESLint cannot evaluate. Together they cover both halves of a good pull request: is the code right, and is the interface good.
Common questions
Does Rams replace ESLint?
No. ESLint checks code correctness and style; Rams checks design quality of the UI. They solve different problems and are meant to run side by side — ESLint in your editor and CI, Rams on every pull request.
Can’t eslint-plugin-jsx-a11y do accessibility?
It catches a subset of static JSX accessibility issues (e.g. missing alt attributes). Rams covers a much broader accessibility surface — contrast, focus management, touch targets, keyboard interaction, and semantics — plus visual design, hierarchy, spacing, and design-system violations that no linter evaluates.
Does Rams need configuration like ESLint?
No. Install the GitHub App, select repos, and every pull request is reviewed automatically. There are no config files, rule files, or CI setup to maintain.
See what Rams finds on your repo.
Free on public repos. Every pull request reviewed for design quality, with inline fixes.
Review my public repoFree