I've seen this concept a few times recently and am interested.

However, what's the benefit over just using the "Claude Code for Web" feature built into the Claude Code mobile app?

It clones your repo into a VM which has a bunch of dev tools installed, you can install additional packages, set env vars, and then prompt it remotely. The sessions can be continued from the web and desktop apps, and it can even be "teleported" into the terminal app when back at a laptop/desktop.

Would be great to understand what the differences / advantages of OP approach are.

I feel like there’s something special about connecting to a server to build and deploying on the same server. Claude Code on the web lets you connect to a repo, test the code, and deploy it, but then you have to host the app and data somewhere else to take it live. IMO the ideal is doing everything in one place and it seems like a lot of dev tools are going in that direction too (v0, val town, deno deploy).

I’ve only used web codex version but everything about it was slower than what’s described here, broken flows, more rate limited and impossible to “human in the loop” before a PR.

The Claude code tui is so nice. The web and iOS apps neuter it weirdly.

Yep, have seen this myself as previously a manager and now with a young family.

I can make incredible progress on side-projects that I never would have started with only 2-4 hours carved out over the course of a week.

There is a hopefully a Jevon's paradox here that we will have a bloom of side-projects, "what-if" / "if only I had the time" type projects come to fruition.

This is exactly the case. Businesses in the past wouldn't automate some process because they couldn't afford to develop it. Now they can! Which frees up resources to tackle something else on the backlog. It's pretty exciting.

I recently found out about https://micro.blog/ which I think is in a similar vein (https://micro.blog/about/indieweb), but as a hosted service.

It’s the easiest out of the box way to embrace POSSE.

I’m not convinced that “single binary” really matters in practice. What actually matters is how easy it is to install, run, and update an application, and that depends entirely on the target user.

For end-user apps, this is basically solved: use jpackage to ship an installable app with a bundled, trimmed JRE. Better yet, distribute via the OS app store so updates are handled for you (on Linux, Flatpak is probably the right answer today).

For CLI tools, you’re already assuming a more technical audience. At that point you have two real options:

- ship everything bundled (Go/Rust static binaries, pyinstaller, jpackage)

- ship just the app and rely on a smart launcher/runtime manager (npx, bunx, uvx, jbang), and assume your technical audience can install that first

The real question isn’t "is it a single binary?", it’s "how do users install, run, and update it?". In practice, that’s already been solved by developer package managers like brew and scoop. All the Go and Rust CLIs on my machine are installed via brew, not manually downloaded from GitHub releases.

You also want CLIs on PATH or inside a dev environment (mise, direnv, etc.), so whether that executable is a true single binary or a symlink to a bundle is mostly irrelevant.

So the trade-off becomes, do you support `brew install foo-java-tool` with a bundled JRE, or do you ask users to `brew install jbang` and then `jbang install foo-tool`? Either way, the end result is the same, you run `foo-tool`.

Note, Claude Code for instance supports both options (curl | bash, brew cask, and npm -i), isn't a single binary, and that still hasn't stopped it from being the most popular CLI tool released this/last year.

There’s definitely room for improvement in Java’s packaging story, I just think the focus shouldn’t be on "single binary" as the primary goal.

Hi @rohanray - original submitter.

Apologies for submitting before the project was perhaps ready for a wider audience. I'm a boring Spring developer these days but enjoy reading about wider JVM developments and thought this was cool and worth sharing.

I think it's a shame that the HN audience's AI debates tend to derail more interesting technical conversations.

From my perspective, there are many valid reasons to use AI to bring a project to fruition, including speed, project scope, time constraints, etc. If AI helps bring to life projects that would otherwise remain daydreams, especially open-source ones, that's a win imo.

It's also far-fetched to assume someone clearly an engineer, building a project of such scope, working with low-level Java, integrating io_uring, and generating tests to ensure contracts, is a "vibe-coder" in the pejorative sense. It's unfortunate that some HN users resort to name-calling and gatekeeping, and I think some newer community rules and guidelines for AI-enhanced submissions would be helpful.

Anyway, keep coding and releasing!

Thanks @mands for you reply! I am glad you did post it and really thanks for it. However, I echo your thoughts too - I was expecting a constructive engagement re FFM & io-uring, etc. but unfortunately the entire thread digressed into AI & vibe coding etc.

I am definitely continuing to work on this.

We've just moved to GraphQL after using REST and bog-standard RPC, and it's been a breath of fresh air. I was considering building my own HTTP RPC system, similar to json-rpc or open-rpc, but I would have ended up with a poorly-specified GraphQL clone.

I think GraphQL's biggest issue is a naming and positioning problem. I, along with colleagues, thought for a long time that it was tied to graphs, DB query languages, and heavy backend implementations.

It's actually a typed RPC system designed for Client UIs, including SPAs and mobile. We're using it with a monolith in a code-first manner, where the schema and client code are auto-generated from backend types.

I think the project could benefit from a `graphql-lite` / `graphql-full` split, where `-lite` includes a well-documented, leaner core featureset (RPC, simple resolvers), and full mode includes federation.

Really cool, excited to see how the rest of the library pans out.

@dang perhaps auto-flagged as was top of front-page for a few minutes then disappeared, shame as a fun read.

Thanks! Appreciate it

Nice read up of the new FFM API.

Recently saw a new FFM-based zero-copy transport and RPC framework using io_uring at https://www.mvp.express/

An interesting time to be in the Java/JVM ecosystem, meanwhile, back to my Spring Boot app...tho least we're on Java 25

It's more an fun educational overview of the new FFM API.

I can't think of many actual use-cases where you'd want to use the LLVM JIT over those built-in to HotSpot.

Interfacing with existing LLVM-based systems, writing a very tight inner loop using LLVM where you absolutely need LLVM-like performance, or creating a compiler that targets LLVM using Java would be the main "real-world" use-cases.

Great read, both in terms of content, but also the approach to diagnosing the issue and debugging in general.