Lead the landing page with the rival comparison - #173
Merged
Conversation
The landing page opened with three slice-scope panels and prose about trust tiers, and the sidebar listed four superseded snapshots beside the current result. A reader asking how Bifrost compares to the language server they already use had to work that out from the evidence map, and the older snapshots -- different analyzer versions against different corpora -- read as though they were current. Lead with the comparison instead. LandingResults renders one card per reference language server: strict-contract conformance for Bifrost and for that server over the cases they both answer, the overlap, and each side's own wins. Sorted by Bifrost's margin, so where we are behind is visible rather than buried. Every count comes from the evidence map's derived scores for the published slice; only the short answer is written by hand, and it is phrased from the computed tallies so it cannot drift from them. Without a checksum-verified bundle there are no scores, and the page says so rather than showing a number. The comparison is the reviewed legacy core, which is the broadest we publish and the weakest tier we publish. The page names that on its face: the cases are retrospectively selected and re-reviewed from source, deliberately not preregistered, and it points at the prospective slices for the stronger claim over fewer languages. Leading with breadth is an editorial choice; letting it pass as preregistered evidence would not be. Superseded snapshots move into their own collapsed sidebar group and stay reachable. Testing: builds against a published evidence map carrying the real v0.3.1 scores -- verdict resolves to 7 of 10 ahead, 2 level, 1 behind (rust-analyzer), over 94 shared comparisons, matching the generated result page -- and against the checked-in placeholder, where it renders the no-result state. astro check clean, 23 pages, links:check 22 routes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DavidBakerEffendi
added a commit
that referenced
this pull request
Aug 26, 2026
Follow-up to #173 on two reported nits. ## The bars were lying Ruby LSP's `9/9` rendered at **56% width**. The bars were scaled against the widest card's denominator (16, the TypeScript server) rather than their own, so a perfect 9 of 9 drew as 9/16 and read as a 56% score. Each bar is now a share of its own card's `shared` denominator: `9/9` is full, `2/9` is 22.2%, `8/10` is 80%. Cross-card bar lengths were never a valid comparison anyway — rivals answer different populations, from 5 shared cases for gopls to 16 for the TypeScript server — and the project's own guardrail is that those denominators are not interchangeable. Per-card scaling now prevents that false read rather than inviting it. ## Uneven card heights Two causes, both measured in the browser rather than guessed at: 1. The rival's name sat in a fixed `5.5rem` label column, so "Eclipse JDT LS", "TypeScript LS" and "rust-analyzer" wrapped to a second line. The two bar rows now share one grid, whose label column sizes to the longer of the pair and never wraps. 2. Starlight's markdown flow puts `margin: 16px 0 0` on every sibling after the first, so the **first** card was a different height from the rest inside the grid. The grid's own `gap` owns that spacing now. Also swapped the per-card breakdown from a prose sentence to three fixed slots — same height on every card, scannable down a column — and the third label reads "Rival only" instead of repeating a server name the card title and bar row already carry, which was truncating mid-phrase to "Eclipse JDT LS …". ## Verified In a browser against the real published scores, at 800px and 1400px: - all ten cards **206 × 350**, one unique height, one unique width - zero truncated labels - bars `100%` / `22.2%` for Ruby LSP's 9 of 9 against 2 of 9 - checked-in placeholder still renders the no-result state - `astro check` clean, `links:check` 22 routes 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Modelled on dataflowbench's results-first landing page, adapted to what
UsageBench actually compares: Bifrost against established language servers.
The problem
The landing page opened with three slice-scope panels and prose about trust
tiers. A reader asking "how does Bifrost compare to the language server I
already use?" had to derive that from the evidence map. Meanwhile the sidebar
listed four superseded snapshots beside the current result — different analyzer
versions against different corpora — which read as current.
What it does now
One card per reference language server: strict-contract conformance for Bifrost
and for that server over the cases they both answer, plus the overlap and each
side's own wins. Sorted by Bifrost's margin, so where we are behind is
visible rather than buried.
From the published v0.3.1 evidence:
That sentence is generated from the computed tallies, so it cannot drift from
the cards beneath it. Every count comes from the evidence map's
derivedScoresfor the published slice; only the surrounding interpretation is hand-written.
Without a checksum-verified bundle there are no scores and the page says so,
matching how the result pages already behave.
On the tier
The comparison is the reviewed legacy core — the broadest slice we publish
and also the weakest tier we publish. The page names that on its face:
retrospectively selected, re-reviewed from source, deliberately not
preregistered, with a pointer to the prospective slices for the stronger claim
over fewer languages.
Leading with breadth is an editorial choice. Letting it pass as preregistered
evidence would not be, and the guardrail in
docs/legacy-promotion-manifest.mdis about the claim being labelled, not about where it appears.
Superseded snapshots
Moved into their own collapsed sidebar group. Still reachable, no longer
sitting beside the current result.
Testing
to 7/2/1 over 94 shared comparisons, and each card's overlap and per-side wins
match the generated result page's strict-conformance table exactly.
astro checkclean, 23 pages built,links:check22 routes.🤖 Generated with Claude Code