FAQ and Philosophy

FAQ and Philosophy

Why

Why not Playwright / Puppeteer?

Every agent that touches the web today drags along the same stack: headless Chromium. Playwright/Puppeteer download ~300–400 MB of browser per machine, eat ~100–200 MB of RAM per open page, and are driven by CDP — a protocol built for DevTools, not for agents. Meanwhile, what an agent actually needs is small: go to a page, execute its JS, read the text, take a screenshot, click, type. navette does exactly that over the engine the OS already ships.

The analogy: headless Chromium is the Postgres of scraping; navette is the embedded SQLite. SQLite won because nobody wants to run a server to hold a little state; navette wins because nobody wants to download a browser to read one page.

Who is this really for?

The agent web has two halves, and they don't need the same browser:

• Server fleets (scraping at scale, cloud browser APIs): Linux boxes running Chromium headless. Real, big, already served. Not our fight today.
• Local agents (MCP clients, desktop assistants, CLI agents, IDEs): the agent runs on the user's machine, which already ships a full engine. This half is exploding in 2026 — and here, downloading 400 MB of Chromium to read one page is a blocking defect. This is navette's beachhead: the agents that live where you live.

Windows deserves its own line: the system WebView there is WebView2 — Chromium, preinstalled on every Windows 10/11. So on Windows, navette delivers Chromium-grade rendering from a <1 MB binary with zero download. The Chromium without the Chromium.

Why not Apple's Safari MCP server (2026)?

Same thesis, different scope: navette is agent-first (8 primitives, ghost windows, resident daemon), open source, and cross-platform by design (WebView2 on Windows is Chromium — preinstalled). Apple's is macOS-and-Safari-shaped.

Why not just fetch + readability?

For static pages, do that — it beats everyone. navette exists for what fetch can't do: JS-built pages, logins, sessions, forms, screenshots, acting like a human.

Why not an ML extraction model?

Two trades, not a ranking — trained extraction models survive hostile HTML (agency templates, mangled CMS output) where a DOM walk picks the wrong node, at roughly ~600 ms of compute per page. navette's native DOM walk costs ~10 ms per page and wins wherever the markup is sane, which is most documentation, news and dev-tool pages — most of what agents actually read. The layers compose: when one target's markup is hostile enough that native extraction picks garbage, hand that page's raw HTML to an ML pass.

Is navette a crawler?

No — deliberately. navette does navigate/read/screenshot/act on a URL you hand it; robots → sitemap → link discovery is a layer above, not a core primitive. Point a crawler at navette when its targets need a real engine.

Screenshot fidelity?

Capture is native per engine (v1.3+) — what the compositor drew, not a re-render — and viewport-sized; set the viewport before navigating for repeatable captures. Full-page capture is not implemented yet; tracked honestly rather than approximated (see Roadmap and Known Gaps).

No CDP?

Not a drop-in for Playwright, on purpose. The bet: agents speak MCP and plain HTTP now — and if they don't, a thin CDP shim can come later.

Landscape

	Playwright + Chromium	Lightpanda	Browserbase (cloud)	navette
Engine download	~300–400 MB	small binary	none (remote)	none — engine is the OS
Engine completeness	full	partial (alpha)	full	full (system WebKit)
RAM per page	~100–200 MB	~123 MB peak	n/a (their bill)	WebView-native
Protocol	CDP	CDP	REST	MCP native + loopback HTTP
Runs where	anywhere	anywhere	their cloud	anywhere with a system WebView

Honest trade-offs

• No CDP — see above.
• WebKit ≠ Blink. A minority of sites are tuned for Chrome and may render slightly differently. For reading, this rarely matters — and on Windows, WebView2 is Chromium.
• Every platform needs its own plumbing. WKWebView, WebView2 and WebKitGTK are three different controls with three sets of quirks; the ghost-window/headless work is per OS. The concept ports everywhere; the glue doesn't.

Name lore

Navette is French for shuttle — the small vessel that carries your agent from page to page. Always fueled (the engine ships with your OS), light enough to ignore, and it skips the human web's garbage — cookie banners, popups, autoplay — so your agent never has to see it. Name collision-checked at pitch time: free on npm, free GitHub handle, both .dev and .com unregistered.

Mascot: a grumpy shuttle. It does the nav. It's literally its job.

Not a scraper — an actor

navette doesn't fetch pages for later parsing; it acts: opens sessions, fills forms, clicks through flows, verifies with screenshots, keeps state across steps. Scraping is the demo; acting is the product.