Show HN: Titan – JavaScript-first framework that compiles into a Rust server

Posted by soham_byte 5 days ago

Counter33Comment19OpenOriginal

Hi HN,

I built Titan, a backend framework where you write routes and logic in JavaScript, and the CLI compiles everything into a single Rust + Axum binary using the Boa JS engine. No Node.js is required in production.

The idea is to keep JS developer experience while getting Rust performance and a self-contained deployable server.

Current features:

JS route DSL

Action system mapped to Rust

esbuild bundling

Generated Rust server with Axum

Hot-reload dev server

Single-binary output

Repo: https://github.com/ezet-galaxy/-ezetgalaxy-titan

Would love feedback on the architecture, DX, and whether this hybrid JS→Rust approach is useful.

Thanks for reading!

Comments

Comment by wavemode 3 hours ago

> 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.

Comment by denys_potapov 20 minutes ago

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

Comment by tigranbs 5 hours ago

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!

Comment by pseudony 2 hours ago

I’ve heard it said and I won’t argue your personal experience.

However, I don’t see it that way at all. I find claude much more capable of writing large chunks of python or react/js frontend code than writing F#, a very statically type-checked language. It’s fine, but a lot more hand-holding is needed, a lot more tar pits visited.

If anything, it seems a popularity contest of which language features the most in training data. If AI assistance is the goal, everyone should write Python and Javascript.

Comment by k9294 1 hour ago

I’ve worked with relatively large projects in TypeScript, Python, C#, and Swift, and I’ve come to believe the more opinionated the language and framework, the better. C# .NET, despite being a monster, was a breath of fresh air after TS. Each iteration just worked. Each new feature simply gets implemented.

My experience also points to compiled languages that give immediate feedback on build. It’s nearly impossible to stop any AI agent from using 'as any' or 'as unknown as X'casts in TypeScript - LLMs will “fix” problems by sweeping them under the rug. The larger the codebase, the more review and supervision is required. TS codebase rots much faster then rust/C#/swift etc.

Comment by christophilus 20 minutes ago

You can fix a lot of that with a strict tsconfig, Biome and a handful of claude.md rules, I’ve found. That said, it’s been ages since I wrote a line of C#, but it remains the most productive language I’ve used. My TypeScript productivity has only recently begun to approach it.

Comment by Yokohiii 4 hours ago

Not everyone is doing the AIch

Comment by rizky05 4 hours ago

[dead]

Comment by Terretta 1 day ago

> 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'?

Comment by ediatedia 34 minutes ago

Yeah, this is either an oversight or unnecessarily immature. Either way, not good.

Comment by 22 minutes ago

Comment by jitl 5 hours ago

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.

Comment by Jean-Papoulos 2 hours ago

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 ?

Comment by pavelai 3 hours ago

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

Comment by jeswin 2 hours ago

> 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.

Comment by Jaxan 1 hour ago

There is not. It uses Boa, a JavaScript engine in Rust. So I’m not sure what the benefit really is compared to Node (a JavaScript engine in c++).

Comment by css_apologist 5 hours ago

    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

Comment by alltheuuu 1 hour ago

Wow. Just sucks that Rust proponents apparently tried to assassinate through sw*tting a Rust critic, Rene Rebe.

Murderous, wretched and evil Rust proponents will censor, downplay and distract from this post. These murderous Rust proponents already know that they deserve worse than hell.

Comment by phplovesong 51 minutes ago

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

Comment by waterTanuki 5 hours ago

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.

Comment by isuckatcoding 5 hours ago

Tit? Really? Just two more letters.

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