01
Biloba — "browser testing is slow and flaky," answered with a comparison repo that discloses a model wrote it
Biloba (MIT, Go, 27 stars, 10 forks, created March 2023, 328 commits, two human contributors, v0.16.2 shipped on September 12) is Onsi Fakhouri's browser-testing library, from the author of Ginkgo and Gomega, built on chromedp and the Chrome DevTools Protocol. Three principles, stated in CLAUDE.md and traceable through the design: performance via parallelization (one shared Chrome process, each Ginkgo parallel process driving its own isolated root tab, reused between specs rather than recreated); stability via pragmatism (a click is element.click() after synchronous, atomic visibility and enabled checks run inside the browser, not scroll-into-view plus a real pointer); and conciseness via Gomega matchers, so a spec reads Eventually(b.ByText("Sally").Within("#user-list")).Should(tab.HaveClass("online")). Specs can be written in Go with Ginkgo or in TypeScript with Vitest, off the same engine. The headline table, median of 15 runs on an M1 Max whole-suite wall clock: biloba-fast at 2.57s parallel and 9.55s serial, biloba-realistic at 3.26s and 18.60s, Playwright at 8.23s and 38.37s. Fast is roughly 3.2x parallel and 4.0x serial ahead; realistic, which routes every interaction through real CDP input the way Playwright always does, is still about 2.5x and 2.1x ahead. The fast-versus-realistic split is the same suite with one env var flipped, so only the interaction engine differs between the two runs.
The evidence repository is the reason this leads. onsi/biloba-comparison ships METHODOLOGY.md for the fairness controls and threats to validity and SCENARIOS.md for the exact workload, states that the aim is "to measure framework + runtime overhead for an identical browser-test workload — not to manufacture a win," and warns in bold that the numbers are from one machine on one day, "indicative, not universal. Run it yourself." It also opens with a disclosure most benchmark repositories would bury: "This whole comparison — harness, scenarios, charts, and write-up — was generated by Claude (Opus 4.8), working from a brief." Then the README declines to rest on it anyway: "Of course, synthetic benchmarks don't necessarily capture real-world performance," followed by two field data points. A 1,689-spec Ginkgo suite for an interaction-heavy JavaScript app completes in under 60 seconds, at a flake rate under one percent maintained by periodic local flake hunts. A mature 165-scenario Playwright suite converted to a Biloba Vitest suite went from about 3m10s to about 1m13s, "a 2.6x observed speedup" — lower than the synthetic number, and published next to it.
Reach for it if your CI's slowest job is browser tests and you already write Go with Ginkgo, or TypeScript with Vitest; it replaces Playwright Test for that suite, and it replaces nothing you pay for. Delete the nightly-only tag on your end-to-end suite, since a 32-scenario run at 2.57s belongs on every push. Tradeoffs: the comparison repository has not been pushed since June 15 and benchmarks Biloba 0.3.0, thirteen minor versions behind the September 12 release, so the headline table is three months stale against the thing it is advertising; Biloba is pre-1.0 and says so, "the public API contract may shift"; it is Ginkgo-native in Go, which means adopting Biloba means adopting Ginkgo and Gomega if you have not already; the speed comes partly from fidelity you give up, because fast mode skips scroll-into-view, occlusion checks and real pointer movement, and the honest comparison to Playwright is the realistic track; and the project is effectively two people, 259 commits and 64, across three and a half years.