> Would love feedback on the … DX

Is it that the two extra characters 'an' in 'titan' are so difficult to type for the CLI, or is it just for the giggles when you 'dev'?

TBH, the idea seems way outdated for the current state of software engineering. The Rust compiler provides a massive benefit for AI Coding because it literally catches all the failure cases, so all AI have to do is implement the logical parts, which is usually a no-brainer for something like a Claude Code or Codex.

For example, the https://github.com/SaynaAI/sayna has been mostly Claude Code + me reviewing the stuff + some small manual touches if needed, but for the most part, I have found that Claude Code writes way more stable Rust code than JS.

It would be easier and safer to give the JS code to a translator and have it translate it into Rust, and then continue AI Dev with Rust, than to invest time in an automated compiler from JS to Rust. IMHO!

One of your merits listed is "Pure JavaScript developer experience". I don't think most devs, even JS devs would consider this a merit lol. Cool project either way.

Tit? Really? Just two more letters.

Second, how does concurrency (like promises) translate to rust ?

I guess as long as you have basically no business logic, perhaps it makes sense to orchestrate route handling in Rust?

But Boa is very very slow compared to JIT compiled JavaScript. As soon as your business logic starts trying to stand up and walk I think you’ll start hitting request latency sadness.

    const body = JSON.stringify({
        model: "gpt-4.1-mini",
        messages: [{ role: "user", content: "hii" }]
    });

    const r = t.fetch("https://api.openai.com/v1/chat/completions", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
            "Authorization": `Bearer ${API_KEY}`
        },
        body
    });

    const json = JSON.parse(r.body);

.. no async? i wonder how they are doing this & how they plan on more js interop

While the idea is somewhat new for today's JS. And I see some benefits for this to make single-purpose servers compiled into tiny binaries. I believe it would take some time to make this popular. You should to find the niche where it's required right now. And also I would spend more time working on marketing: explainer, documentation, landing page. For example now the readme looks too ai-written

What's about code and DX: it's not a good practice to export anything using globals, this is what JS world refused to do long ago. It turns your code into a hardly debuggable mess quickly

> you write routes and logic in JavaScript, and the CLI compiles everything into a single Rust + Axum binary using the Boa JS engine

It's not clear to me how this would have better performance than plain Node.js, which is a C++ binary using the V8 JS engine.

It looks like you're handling routing in Rust, but this seems unlikely to move the needle measurably. In fact, it could be hurting you - you're basically betting that the rust program (route request + invoke JS interpreter + marshal data) is faster than the much simpler JavaScript program (route request). That doesn't seem likely.

Any benchmarking ? Because this fundamentally sounds like replacing node (V8) with another javascript engine. Which I'm not sure is going to be much of a gain, at which point why use an entire different toolchain than the rest of the world ?

> Rust-level performance > JS → Rust compilation pipeline

There's a JS to Rust transpiler? How? If this is true, this is the most impressive part. The web server/framework almost irrelevant.

The AI generated documentation is very confusing.

The rust fanboys will eat this alive! Props for having the courage to do this tho.

As the author of a JS-to-OCaml compiler [1], I must admit that Poe’s Law applies here [2]:

“Without a clear indicator of the author’s intent, any parodic or sarcastic expression of extreme views can be mistaken by some readers for a sincere expression of those views.”

[1] https://dev.to/denyspotapov/porting-is-odd-npm-to-ocaml-usin...

[2] https://en.wikipedia.org/wiki/Poe's_law

Wait, the CLI command for the package is.. 'tit'?

How doesn’t Bun provide ”Rust-level” performance?

This basically makes a rust server to do the routing, then uses the Boa JS engine to evaluate the JS to handle the route

With this approach, you might be able to do some multithreading to improve the throughput

However, each request is almost guaranteed to be slower because V8 will be faster than Boa

You could also achieve this by spinning up multiple NodeJS instances and putting an nginx server in front to do load balancing - which is pretty standard practice

Bun can generate single file executables even from TypeScript:

  bun build ./cli.ts --compile --outfile mycli

So the value proposition here is debatable.

https://bun.com/docs/bundler/executables

Also stating that Bun has no hot reload is just wrong:

https://bun.com/docs/guides/http/hot

A lot of the claims in the comparison table are highly debatable to put it gently.

"Pure JavaScript developer experience" with yes for Titan and node but no for Bun? If anything Titan's JS support is lagging behind for using Boa.

"Rust-level performance" with yes for Titan and no for all others. But it uses a slow JS engine called Boa. Slower than node and much slower than Bun.

One does not simply "get Rust performance".

Rust can go that fast because of guarantees its compiler enforces about what the code is doing, that JS emphatically doesn't.

By all means build your tooling and runtime in Rust if it helps, but "you can write high-performance code in JS with no Rust-like constraints" is fundamentally a nonsense pitch.

Thanks for the thoughtful feedback — this is helpful. To clarify, Titan isn’t meant to be a drop-in replacement for Node or a V8 competitor. The primary goal is a JavaScript-first developer experience that compiles into a single native Rust binary, removing Node.js from production while keeping a familiar authoring model. You’re absolutely right that Boa is slower than V8. At the moment, Boa is used during development and as the embedded JS runtime, but the core value proposition is not raw JS engine speed. The focus is on deployment simplicity, portability, and tighter control over the runtime surface. In production, the output is a single Rust binary (no Node.js dependency), and a production-ready Dockerfile is already available. Performance parity is important, and benchmarks are on the roadmap, but the initial emphasis is on reducing operational complexity rather than outperforming Node in every scenario. I’ve been updating the documentation to make this positioning clearer — including recent production and Docker updates. For anyone interested, the latest docs are here: https://titan-docs-ez.vercel.app/docs Appreciate the pushback — it’s useful for refining both the project and the messaging.