JavaScript is the past

JavaScript won the browser so completely that we started using it for everything else.

I get why. It is everywhere. It is fast enough for most interfaces. It lets people ship. A whole generation of products exists because JavaScript made the web programmable for everyone.

But when I am hunting bugs or building offensive tooling, I keep running into the same wall: JavaScript is great at the surface. The interesting fights are no longer at the surface.

They are in parsers. Protocol seams. Race windows. Memory pressure. TLS fingerprints. HTTP/2 downgrades. Browser behavior that only shows up when the request is ugly enough. The kind of work where the tool has to sit close to the wire and stay predictable under stress.

That is where JavaScript starts feeling like the past.

I do not mean “JavaScript is dead”

That would be a lazy take.

JavaScript is not dead. It is the language of the browser, and the browser is not going anywhere. If I am building a product UI, I still want the web. If I am building a dashboard, an onboarding flow, or something a customer has to use every day, JavaScript and TypeScript are usually the sane choice.

The mistake is assuming the language that won the interface should also own the engine.

Security tooling is an engine problem.

The browser made us comfortable with wrappers

A lot of modern tooling feels like a wrapper around someone else’s hard part.

Electron around a desktop app. Node around a protocol implementation. Plugins around a proxy. A script runtime around an engine that was never designed for the attack you are trying to test.

That works until the bug class lives below the wrapper.

Request smuggling is not a button. It is a disagreement between parsers. Race conditions are not a UI workflow. They are timing, coordination, and transport behavior. Out-of-band detection is not a toast notification. It is infrastructure.

When the tool is mostly JavaScript, you can still build useful things. You can automate, glue, render, and orchestrate. But the moment you need exact control, you start negotiating with the runtime instead of the target.

I do not want my offensive tooling negotiating with its own stack.

Rust changed my taste

Rust did not make me care about speed first. It made me care about ownership.

One native binary. No warm-up. No runtime bundle pretending to be a desktop app. No giant dependency tree between the request I want to send and the bytes that leave my machine.

That matters as a hacker because the details matter. I want to know how the request was framed. I want to know what the scanner actually tested. I want to know why a payload was generated. If the tool lies to me, hides state from me, or makes the weird path impossible because the abstraction does not expose it, I lose time.

And most bugs are already a fight against bad assumptions. I do not need my tools adding more.

The future is split

The web interface can stay web. It should. The browser is still the best delivery surface we have.

But the engines underneath need to move closer to systems code:

• parsers that can intentionally produce malformed traffic
• scanners that do not need a paid cloud account to run at full strength
• local-first tools that keep research data on disk, not in somebody else’s workspace
• extension systems that sandbox untrusted logic instead of trusting every plugin with the process
• AI control layers that drive the real engine instead of clicking around a UI like a tired intern

That is the split I care about: JavaScript for surfaces, Rust for engines.

Not because Rust is fashionable. Because the engine is where the truth lives.

This is the line I am building on

Hugin comes from that line of thinking.

It is an intercepting proxy and vulnerability scanner in a single Rust binary. Local-first. No account. No telemetry. GUI and CLI together. The point is not to make a prettier wrapper around an old proxy model. The point is to own the engines: scanner, intruder, request smuggling, race testing, out-of-band detection, MCP control.

Hugin is not available yet. It comes soon. I would rather say that plainly than ship launch theater.

The real bet is simpler:

The next generation of security tools will not be won by prettier JavaScript around the same old core.

It will be won by engineers who control the core.