| Hi HN, We built a very early prototype: a Browser-Agent/browser-automation runtime using Kotlin/JVM and raw CDP. Before investing further, we’d like advice from anyone who has worked on browser agents, AI browsers, large-scale automation, crawling, browser farms, or who has deep knowledge of Chromium/CDP. We ourselves suspect many of our design assumptions may be flawed, so sharp criticism is very welcome. --- TL;DR We’re building an open-source runtime: • AI planning/reasoning/logic lives on the JVM • Browser actions are driven via raw CDP • High concurrency via Kotlin coroutines • A small ML agent learns page structure But we’re not sure any of this is actually meaningful. Feedback—especially negative feedback—is appreciated. --- 1. JVM + CDP: possibly the wrong abstraction layer
AI planning/reasoning/logic is on the JVM; browser actions are sent through CDP. Some doubts we cannot resolve internally: • Is the JVM too heavy for this domain? Will GC and scheduling cause tail latency? • Is CDP inherently unsuitable for high-throughput automation? • Does nobody actually need a JVM-native browser agent? • Would Go/Node/Python be more sensible choices? If the answer is “no, this is the wrong direction,” we’d really like to hear it. --- 2. High-concurrency runtime: likely to fall apart in real workloads We’re trying to push single-machine throughput on real, complex pages by relying on: • Kotlin coroutines • Minimizing DevTools round-trips • Raw CDP with multi-tab concurrency But our doubts are even larger: • Can Chromium realistically survive this scale? (render-process contention, GPU-thread limits, compositor stalls, etc.) • Are multi-tab workloads doomed to event interference, reordering, and deadlocks? • Will CDP scheduling become the true bottleneck? • Is raw CDP unavoidably more brittle than Playwright? If you’ve seen similar attempts fail, we’d especially like to know how they failed. --- 3. Non-LLM page-structure learning: probably not generalizable We built a small ML module to avoid calling an LLM every time we parse HTML. It works well on e-commerce pages, but we strongly suspect it will break elsewhere. Concerns: • Will it fail outright on news, forums, SaaS dashboards, and other domains? • Has anyone built DOM-structure-learning systems and then abandoned them? Why? • Is the long tail of the web fundamentally hostile to non-LLM approaches? Failure stories are particularly valuable. --- 4. Some questions we have zero confidence about • Does the world actually need yet another browser-automation stack? • Do “Browser Agents” have long-term practical value at all? • Do coroutine-style concurrency models provide real benefits under heavy CDP I/O? • Should we drop the “agent” layer entirely and just build a runtime? • What fatal issues exist around resource isolation, multi-tenancy, event storms, or long-tail page behaviors? • Do all high-concurrency browser runtimes eventually die for the same reasons? If the answer is “yes, stop now,” we’d prefer to know early. --- Prototype status We’ll open-source a very early version (missing docs, missing examples, and possibly flawed designs). Known issues include: • Deadlocks on certain complex sites that are hard to reproduce • CDP event reordering under high concurrency • Worse-than-expected memory behavior • Structure-learning module is inaccurate on non-e-commerce pages If you’ve built systems with heavy browser interaction, automation, data extraction, or treating the browser as a runtime, we’d love to hear about the bottlenecks you hit—so we don’t optimize toward the wrong direction. --- Finally Any single sentence of criticism may save us months. — Browser4 Team |