It's worth flagging that the homepage and the docs are both nearly unreadable on mobile. If you're going to have cheeky rhetoric like "no crumbs" please take the time to actually test the pages your LLM made for you in a bunch of different ways.
Reads fine for me. I’m getting a bit worn out with the number of ‘if you’re going to use an LLM then take the time to …’ posts. I’ve looked at plenty of HN submissions that don’t render at all on mobile and yes I found it frustrating but didn’t just attribute it to an LLM.
"...browser automation framework..." was about all i understood
and even then it had me guessing if it was talking about an alternative e2e testing framework like cypress, selenium, playwright.....and somehow I was right lmao (i think?)
but literally all the other jargon there had me stumped. I'm still afraid to google
a getParameter(0x9245) probe
Likewise, the text does come across to me as LLM heavy (with a spice of pizzazz), but even as a dev who uses playwright I doubt I would change after seeing this.
To OP: not convincing enough.
Maybe this is targeted towards super users who are deep in the weeds of various browser automation framework internals.
A better marketing approach towards someone like me who just uses this to test my apps e2e and be done with it, would be to have simple cliches like:
"10x faster than playwright",
"Same API",
"Did we mention....SUPER FAST!?"
I might call bs on that, but I'd be more likely to try it out.
- Trying to go to `https://grok.com` and the page doesn't render
I wished it actually worked because I use my own hand-rolled thin-wrapper over CDP and I would love for a more robust solution to avoid being detected, but man this does not inspire confidence.
> The entire DAG, fingerprint manifest schema, harvesting process, is documented. We even commit our live benchmarks to the public record (mochi on a Linux datacenter IP scored a suspect_score: 8 and bot: not_detected against FingerprintJS Pro v4).
Doesn't this defeats the purpose? Essentially giving away the mechanism to the ones implementing fingerprint so they can learn how to detect you and starting a cat/mouse chase in the open
There's a reason why some kinds of technology stay opaque, not always publishing these things help in the way you think they do
it's not that much of a black box when you can literally see the API's they call(albeit some with more effort than others), but i prefer not to engage in theatre..
fair point, I was mostly referring to how certain things are only useful because they do not have wide adoption and pushing for adoption breaks their value (meaning widespread adoption leads to the other side catching up to it)
Forget all the fancy fingerprinting - sites that really care about blocking bots will detect that, in the first place, you are running a browser in debug mode. Does this tool prevent that?
"mochi.js is a Bun-native, raw-CDP browser automation framework. Pass a seed and a profile; get a relationally-coherent fingerprint that survives a getParameter(0x9245) probe. JIT-friendly inject payload, Chromium-native fetch (real Chrome JA4 by definition), behavioral synth on top of Bezier+Fitts. Leaves no crumbs. "
I think this is saying it's:
1) A JS chromium browser automation API targeting Bun (uses Bun.* or "bun:*" apis)
2) Engineered to interact with webpages in a way that evades bot detection
It's worth flagging that the homepage and the docs are both nearly unreadable on mobile. If you're going to have cheeky rhetoric like "no crumbs" please take the time to actually test the pages your LLM made for you in a bunch of different ways.
Reads fine for me. I’m getting a bit worn out with the number of ‘if you’re going to use an LLM then take the time to …’ posts. I’ve looked at plenty of HN submissions that don’t render at all on mobile and yes I found it frustrating but didn’t just attribute it to an LLM.
Check the cards that are wrapped, along with the footer
They're nearly unreadable on desktop, too. The prose is incomprehensibly jargon-heavy, I literally have no idea what it's talking about.
I feel the same. I have no idea what “CDP” and “WAF” means in this context.
I feel awkward about all this probably-LLM-generated prose that does not respect me enough as a reader to explain acronyms and give context.
hate to tag along on this take but i agree
"...browser automation framework..." was about all i understood
and even then it had me guessing if it was talking about an alternative e2e testing framework like cypress, selenium, playwright.....and somehow I was right lmao (i think?)
but literally all the other jargon there had me stumped. I'm still afraid to google
Likewise, the text does come across to me as LLM heavy (with a spice of pizzazz), but even as a dev who uses playwright I doubt I would change after seeing this.To OP: not convincing enough.
Maybe this is targeted towards super users who are deep in the weeds of various browser automation framework internals.
A better marketing approach towards someone like me who just uses this to test my apps e2e and be done with it, would be to have simple cliches like:
I might call bs on that, but I'd be more likely to try it out.bruh
llm recommends using a desktop to view the site as typically that's also the form factor required to use the tool!
Not true. One could be running a container on Android or iOS, accessing a machine remotely, or any number of other things. Best not to assume.
I tried running the hello-mochi.ts and just modified the URL and removed the session closing:
- Trying to navigate to `https://deviceandbrowserinfo.com/are_you_a_bot` crashes it for some reason
- Trying to go to `https://grok.com` and the page doesn't render
I wished it actually worked because I use my own hand-rolled thin-wrapper over CDP and I would love for a more robust solution to avoid being detected, but man this does not inspire confidence.
> The entire DAG, fingerprint manifest schema, harvesting process, is documented. We even commit our live benchmarks to the public record (mochi on a Linux datacenter IP scored a suspect_score: 8 and bot: not_detected against FingerprintJS Pro v4).
Doesn't this defeats the purpose? Essentially giving away the mechanism to the ones implementing fingerprint so they can learn how to detect you and starting a cat/mouse chase in the open
There's a reason why some kinds of technology stay opaque, not always publishing these things help in the way you think they do
it's not that much of a black box when you can literally see the API's they call(albeit some with more effort than others), but i prefer not to engage in theatre..
fair point, I was mostly referring to how certain things are only useful because they do not have wide adoption and pushing for adoption breaks their value (meaning widespread adoption leads to the other side catching up to it)
Off topic, but the name reminds me of mochikit and early JS library in the JQuery kind of area.
Mochikit got bundled with Turbogears an early Rails like Python framework. Rails inspired a lot of frameworks back then. Must be over 20yrs ago.
Forget all the fancy fingerprinting - sites that really care about blocking bots will detect that, in the first place, you are running a browser in debug mode. Does this tool prevent that?
Not this but I do have something along those lines if you're interested!
what would that be? Heard good things about Camoufox
"mochi.js is a Bun-native, raw-CDP browser automation framework. Pass a seed and a profile; get a relationally-coherent fingerprint that survives a getParameter(0x9245) probe. JIT-friendly inject payload, Chromium-native fetch (real Chrome JA4 by definition), behavioral synth on top of Bezier+Fitts. Leaves no crumbs. "
WTF are you talking about? This is incoherent?
I think this is saying it's: 1) A JS chromium browser automation API targeting Bun (uses Bun.* or "bun:*" apis) 2) Engineered to interact with webpages in a way that evades bot detection
Everything about this smells of AI slop. The website, the website copy, the github repo, the README.md, even this announcement.
It's all slightly incoherent, and doesn't give me any trust in this project at all.