Methodology: how EditorStack produces every number on this site

Three kinds of statement, labelled differently

Most comparison sites blur measurement, fact and marketing claim into one voice. We separate them, because the difference is exactly what makes a source worth citing.

Measurements are numbers we produced. Bundle sizes, lines of code and time-to-first-editor come from scripts in the public repository, run on a stated date with the versions recorded next to the result. You can re-run them and disagree with us.

Primary-source facts are read from an authoritative machine-readable source. Licences, first publish dates and current versions come from the npm registry directly rather than from a vendor's website, because a registry entry is what the ecosystem actually resolves.

Vendor claims are things only the vendor can tell us — chiefly prices and capability lists. We record them, attribute them to the vendor's published page with the date we checked, and say "vendor-published" rather than presenting them as verified. A price is a claim about the future, not a measurement.

How bundle sizes are measured

Each package is installed on its own, imported through its documented public entry point, bundled with esbuild in production mode with tree-shaking, and gzipped at level 9. React and react-dom are external for React-only libraries because an app that picks one already ships React; framework- agnostic engines get no exclusion. CSS is excluded and reported separately.

Two rules keep this honest. First, the measured number is written into the dataset by the script, not by hand. Second, the build cross-checks every published size against the measurement file and fails if they disagree, so a number cannot drift away from its evidence. The full write-up is the bundle size benchmark.

How we score, and why most products are not scored

Five axes, each 0–10: developer experience, extensibility, documentation, ecosystem and time to production. Each score must be accompanied by at least 120 characters of written reasoning specific to that axis. This is enforced by the schema — a score without an argument fails the build, so the site cannot contain an unexplained number.

We score only products we have installed and run. As of the last update that is 8 of 34 products — exactly the set that appears in our time-to-first-editor benchmark, and no others. The commercial SDKs in the dataset — Builder.io, Plasmic, Unlayer, Beefree SDK, Stripo, Topol, TeleportHQ, the GrapesJS Studio SDK — carry structured facts and an argued assessment of what they suit, but no score, because we have not put them through the same hands-on test. Silex carried scores in our first release and no longer does: its own review said we had not run it, which made the scores unsupportable by our own rule.

CKEditor 5, TinyMCE, BlockNote and Quill show where the line sits. Their bundle sizes are measured and their benchmark applications are in the repository, but their time-to-editor runs were taken on a different machine from the published run, and timings from two machines are not comparable. Until they are measured alongside the others, they carry no score.

This costs us: a table with more numbers looks more authoritative. It is still the right call. A score derived from reading documentation measures the documentation, not the product.

We publish no AggregateRating structured data anywhere on the site, because we collect no user ratings and marking our own opinion as an aggregate rating would misrepresent it to search engines.

What "unverified" means

A capability cell reading "Unverified" means exactly that: we could not confirm the behaviour from a source we trust, so we left it empty. It does not mean the product lacks the feature. The alternative — filling gaps with plausible values — is how comparison sites become unreliable, and it is undetectable to readers, which makes it worse.

The same rule governs metrics. Where our automated sync has not yet collected a download count or a star count, the page says "pending sync". It never shows zero.

Testing procedure for hands-on reviews

1. Install the library at the version npm install resolves to, and record that version.
2. Build the smallest application that mounts the editor, registers one custom block and loads initial content. These applications live in benchmarks/time-to-editor/ and are published in full.
3. Screenshot the result from our own build at 1280×800. No vendor marketing images appear on this site.
4. Read the documentation for the three things products actually need and demos never show: asset storage, persistence, and how stored content migrates when a component changes.
5. Write the Limitations section before the Strengths section.

Conflict of interest

EditorStack is funded and operated by the team behind GJS.Market, which sells commercial products in the GrapesJS ecosystem. Three entries in the dataset are affected: GrapesJS, GrapesJS Studio SDK and PageKit. Each of those pages prints a conflict-of-interest notice above its content, and the build fails if that flag is removed.

What we do about it in practice: GrapesJS's Limitations section is the longest on the site, its measured bundle size is among the largest in the dataset and we say so on the home page, and the build-versus-buy calculator returns "build it yourself" whenever the arithmetic says so, including against our own funder's product. The full statement is on the disclosure page.

Corrections

If a fact here is wrong, it is worth more to us to fix it than to defend it. Open an issue on the repository with the source, and the correction goes into the changelog with the date. Vendors are welcome to submit corrections about their own products; they get the same treatment as anyone else, which is that we check the claim against a source before publishing it.