Show HN: Ant – A JavaScript Runtime and Ecosystem (antjs.org)
Hello HN!
I'm the author of Ant, a JavaScript ecosystem built around a runtime with its own JavaScript engine. Ant also includes a package manager, the ants.land package registry, a platform for deploying and hosting applications, and Ant Desktop for building native desktop apps with web technologies, similar to Electron.
The goal is for these pieces to work as one coherent platform while remaining compatible with the wider JavaScript ecosystem. It's still early, and I'd appreciate any feedback on the overall direction or what you'd like to see from an e2e alternative to the existing JavaScript stacks.
P.S. I’ve shared Ant here before as a runtime; since then, it has grown into the broader ecosystem you see today.
122 comments
[ 4.5 ms ] story [ 69.6 ms ] threadDo you think that Ant could be used to create a small index.html/css/js project into an desktop app minimally.
I currently found deno desktop which is pretty recent to be the easiest way of doing this for one of my projects (https://epub.mirror.forum) but I found there to be some issues within deno-desktop in terms of some features not working on the desktop app but I overall really like the idea of converting these files into desktop apps and I am wondering if ant could be suitable for that, so I am curious to hear what you think :-D
V8 21M, Score 47285, ES6 98%
Ant 4.3M, >>> Score 69 <<<, ES6 50%
I know some folks love the "purity" of WSL 1 but it's really hard to recommend if you care at all about Linux compatibility.
• (ant) https://github.com/anthropics/anthropic-cli
• (claude) https://github.com/anthropics/claude-code
Implementing, running, maintaining, scaling a module registry is probably not worth the time. Unless there's a clear technical requirement from the runtime. I would think there isn't since npm protocol compatibility is a stated goal/feature.
But according to zoo.js benchmarks that is far from the case:
https://zoo.js.org/
Unless there were major perf gains since 2026-02-10?
The author has said that they've redone it since, but the "from-scratch hand-built" framing specifically – for me – somewhat grates given the original heavy lifting from an existing AGPL codebase.
https://github.com/cesanta/elk/issues/75
I want to acknowledge that the original authors don't seem to have minded too much – per that thread – after older versions were dropped.
For context, the current code doesn't look like it is the same shape, the same structure, etc., etc. – it _has_ been rewritten since (the 'since Feb' rewrite mentioned adjacent is related to this, AFAICT).
To the author: I absolutely love what you're doing overall. Keep going! Just be careful, folks.
isn't the post of someone who just implemented a js engine (it reads like someone who asked an LLM to write a blog post about the git log of a different LLM which was apparently lifting code from a different js engine...)
It's a bit hard to understand what's going on here, but definitely hard to trust the project.
For example, I think young developers would not know that SOAP was a major, like really major, technology in the 2000's. If you google for SOAP now, you get "cleaning products" mostly, and if you're lucky a single mention of the protocol - but unless you dig deeper, it's hard to find out it was actually THE industry standard for web services at some point.
IMO it's exactly the same with Ant (I used Apache Ant a lot in my early days as a dev!! But I've seen how very few Java devs know it these days, it's one of those things only the older guys know, plus a few younger one who have an interest in build systems in general and their history).
https://ant.design/
Some people have also heard of ants of the formicidaen variety.
apache ant (another neat tool) is from the java ecosystem (and can be used outside of it) that has largely been replaced by maven, which is gradually being replaced gradle.
this project seems to only overlap with either in that it uses javascript (or the word java).
Is antjs coded in plain and simple C?
Odd choice for a vibecoded project.
Not really, there's some advantages if the viber is experienced in C.
1. When the LLM needs to figure out what functions exist, it reads only headers, not the actual implementation. IME the agent uses a fraction of tokens compared to vibing out a Java or C# project.
2. There's only a handful of common footguns in C (signed overflow, use-after-free, dereferencing NULL, etc) all of which are localised, compared to C++ which has all those C footguns plus non-localised footguns that can't be easily detected without knowing the entire program at once.
I'm using coding agents to accelerate implementation, not to replace understanding or review. The architecture, technical decisions, testing, and final responsibility are still mine, so I don't think "vibecoded" is an accurate description here.
And then the follow up few months later: https://themackabu.dev/blog/ant-part-two
I'm not sure what the economics of building a new runtime and ecosystem from scratch are but it seems we're already in a phase where individual developers are creating software which previously took a whole team. And its only getting started...
There is no shame in saying it's generated, bun is now completely vibe code also.
Saying it's hand built when it's not is false advertising
I would assume by now most of the code published on Github is hand-built with LLM prompts and armies of AI agents.
He forgot to scrub the vendor ID field.