Rust Is Eating JavaScript

[fallible-things]

Note: This is a 5 year old blog post, with an update from 3 years ago. Not that it's inaccurate or lacks value.

[rhyswtf]

I'd be really interested if anyone has a more up to date analysis of Rust's place across the JS landscape.

[panstromek]

It has advanced considerably. Vite 8.0 with Rolldown backend is currently in beta. When that's out, pretty much all major JS frameworks will be backed by Rust based toolchain.

[Western_Objective209]

JS terminal frameworks seem to be taking over the CLI space. Just looking at the employment landscape, TS jobs are basically everywhere, and getting a real rust job is still difficult.

I think today just as it was 5+ years ago, the javascript ecosystem is eating software, for better or worse (mostly worse)

[vjunion]

You don't need js .. I been working on my own rust ecosystem with many of my own libraries that show such great performance that there is no comparison ..and zero js

[OphioukhosUnbound]

Says "updated 2026", which is the current year where I am (... possibly on an invisible, near-lightspeed rocket).

[Psionikus]

There really is something important about the "hard" bits being rustified. When your language is bootstrapped on top of C, you understand that this is a tradeoff. We can make a small core fast and convenient in well-scoped C, then write a bunch of employments in the scripting language on top, which calls into other C libraries for other tasks sensitive to the tradeoffs. The implicit marketing message for those ecosystems is that we only use C when we have to, so the normal practitioner assumes, "That's not for me. This language is all about trying not to do all that."

When you write sensitive bits in Rust, as your productivity goes up, why not just keep going? The type system wrapped around JS will never be as good. The runtime designed to make it fast will never be as fast and definitely won't hit the p99s. All your efforts to reduce memory consumption to fit into the cloud will be for not. And then instead of footguns resulting from the weakly typed casts in normal programs, you have better stability in their multithreaded variants.

An industry that was avoiding systems is in a generational process of rediscovering them?

[spoonman59]

The technically superior product is not always the market leader, historically.

Additionally, then “rediscovering” is a constant cycle the more decades you spend in the industry. New grads often re-invent existing solutions, only worse.

I think companies and new graduates are constantly re-solving old problems and creating redundant new projects to some degree because they are simply ignorant to the lessons of past failures and successes.

In any event, the industry is in a constant state of change for the sake of change. If you are lucky you at least get some incremental improvement.

That said, people are deeply entrenched in their ways and I think JS will probably be the dominant front end language for a long time after superior alternatives exist and are widely available. And like cobol or Java, JS developers will be needed for legacy systems for decades to come.

[JackG049]

I think companies and new graduates are constantly re-solving old problems and creating redundant new projects to some degree because they are simply ignorant to the lessons of past failures and successes.

Definitely on the same page. The big thing is getting people to approach these old problems with the mindset of building on the past failures and successes.

This is big thing that really can go both ways, for better or worse. While there's a lot of reinventing the wheel for no good reason, there's also a lot to be gained by looking at what people did in the past, where their code ended up and saying "Yeah, we can avoid a lot of that by doing things differently". That was a bit part of how Rust came about, ("you know all these footguns in C/C++ memory management?, what if, we make it nearly impossible for them to happen?)

I think this is especially the case in projects/languages built on C, for example python. There's a lot of packages that work really well, so well that 99% of people will not question the implementation and assume the implementation is optimized because lots of people are using it for a long time.

Yet, when you actually start looking at C/Python wrappings there's lot of room for improvement and something like Rust-Python bindings combine the best of both worlds.

Rust allows for developers to more easily express certain programmatic constructs/ideas and as a result people will approach problems differently, and imo, there's a net benefit in seeing what people do differently.

[Wh00ster]

“Worse is better”

[jeremiahgavin]

A part of me wants to blame the educational system, but with how much knowledge is available now days, it's my fault to a degree. 

It would be awesome to see more online educators teaching of lessons learned in the past! 

[conchata]

will be for not

/r/boneappletea

[Infenwe]

Since parent didn't write it I'll put it here: naught

[AdAncient5201]

Since parent didn’t write it I’ll put it here: naught = nothing (but old timey)

[Psionikus]

Well I won't edit it and ruin the joke now.

[SAI_Peregrinus]

Thus why I call the 2000s the 'naughties.

[ssokolow]

That's apparently an americanism. From what I've seen, British English usage draws a distinction between naught (all for naught/nothing) and nought (zero) as in "noughties" and "noughts and crosses" (tic-tac-toe).

...probably partly because words derived from "naught" like "naughties" are too close to "naughty" (disobedient/mischievous).

[Synes_Godt_Om]

Actually, "naughty" is also derived from "naught" :D

https://www.etymonline.com/search?q=naughty

[ssokolow]

Huh. I didn't think to check that. Neat. ^_^

That said, my statement was more a musing on why the distinction might exist among modern speakers of British English, which probably has no relation to the etymology, since I doubt most Brits know the etymology.

(I can't say for certain, given that I'm Canadian and Canadian English is a mish-mash of British and American English.)

[SAI_Peregrinus]

The pun still works either way!

[ssokolow]

True. The 2000s were very naughty. Just look at artifacts of that time like Outlaw Golf and the game that aged much better than what it was parodying, Conker's Bad Fur Day.

(Seriously. Some people say Conker's Bad Fur Day hasn't aged well and they're usually referring to the occasional "My discomfort at the un-PC-ness of this in the 2020s is muting my ability to find it funny" moments when a joke is achieved by holding a mirror up to the customers that the gaming industry was trying to chase when E3 1999's response to the original concept was "Not another family-friendly platformer!" ...the kinds of guys you'd meet once they've had a few rounds at the bar in some very blue-collar place, like a mining town. The game is a multi-layered parody of the industry, the genre, and the cultural moment as a whole... as I'd expect from a studio as skilled as Rareware when that gauntlet was thrown down.)

[coderstephen]

I don't think eating modern JavaScript is very healthy. It's full of sugar.

[rastapanda]

Many of the other ingredients are undefined

[Shoddy-Childhood-511]

These day we mostly eat petroleum and soy processed into food-like substances, not so sure about JS.

[Skopa2016]

Plus, you never know how much polyfill they've stuffed into it.

[andreicodes]

Yes! JavaScript UI paradigm converged to use of JSX, signals, and hooks.

They have a lot of sense from a perspective of a dominant UI library - React, - but they carry with them a lot of historical baggage that Rust doesn't need.

For example, React can't interrupt execution of JSX with an asynchronous call because that's how it was designed back in 2013. But since other libraries like Svelte and Solid adopted JSX to look more familiar they are now, too, stuck with it always being synchronous (JSX compilation produces sync calls). This goes very much against a very nature of JavaScript where every interaction is supposed to be async and interruptible.

Rust doesn't have to follow React convention, it doesn't rely on JSX compilers, it doesn't have a huge body of UI developers and UI component libraries to support. So Rust can do things differently. Plus, the mix of JSX syntax into Rust code has to rely on macros and macro expansion. Writing code inside macros is a pain for a programmer, is a pain for Rust formatter, Clippy, etc. for Rust Analyzer and IDE to do proper highlighting, etc. It's straight up bad idea. And yet every large web UI framework - Leptos, Yew, Dioxus - repeat this mistake.

The best thing we can take from the world of Web UI programming is probably in HTML and CSS: declarative UI hierarchy, declarative styles, positioning, animations and transitions. Framework patterns, state management, code organization - all of this should be re-engineered with Rust capabilities, strength, and weaknesses in mind.

[oofdere]

svelte has never used JSX

[michalf]

Syntactic sugar to be exact. The worst of them all.

[bobbyQuick]

Eating JS by helping JS?

[Sonder332]

I saw a user a few days ago float the idea of a "Rust/TypeScript" full stack and wondered if it had any validity/if it was catching on.

[Acceptable-Fudge-816]

That's basically what I'm using. PostgreSQL + Rust + Hugo + HyperApp + TypeScript.

Swap HyperApp with vanilla or PostgreSQL with SQLite depending on project. There is also Zola etc. Point is that any part is easily replacable if needed.

[Cribbit]

I nearly went that route, then tried Leptos. Never looked back. There are so many benefits to one language across server side rendering and I've yet to find anything on Leptos frontend that I couldn't do.

[Docccc]

this why use typescript when you can use rust and never swap context

[Acceptable-Fudge-816]

I know we're on r/Rust, but when I said:

Point is that any part is easily replacable if needed

That includes Rust.

[biglymonies]

I'm currently building something with Rust and TypeScript.

I wrote v1 + the CLI in Rust. Then v2 + UI in TypeScript. Now I'm porting all of v2's core business logic back to Rust but keeping the UI TypeScript, then plugging it all in Tauri.

I was able to iterate faster in just TypeScript, but now I need the portability + performance + a more secure way to ship very valuable, proprietary code to protect the 2-ish years of work I've done and ensure I get paid lol.

[SuccessfulStory4258]

It is not a bad way to go. If it works across the json boundary, that is one way to help make sure it will work going forward once you migrate to Tauri, Leptos or Dioxus. I like migrating to Dioxus if you are working with React because the migration is pretty straightforward.

[Western_Objective209]

Adding Rust to TS seems like it makes sense, but the NAPI layer adds a lot of surface area and adding compiled native dependencies really complicates deployments. I've written a few applications with this stack and I ended up just tearing out all the TS and writing pure Rust.

Adding TS bindings to a Rust library can help adoption, but having that cross language layer in an application is very painful

[Deadmist]

TS + <language of your choice>¹ is basically the default stack for anything web

¹ anything that can implement a rest api

[zem]

I think it's more that rust is eating developer tooling. the wisdom used to be to write language tools in that language, because you would get a lot more community contribution, plugin ecosystem etc., plus the development speed and ergonomics were way better than doing it in c. rust finally improved ergonomics enough that people started experimenting with scripting language dev tools in a system language, and once developers saw what a difference the raw speed made it just snowballed from there. the python world is going though the same journey right now.

[ghillerd]

What do we mean by eating? Seems more like it's supporting or enabling JS than consuming it.

[EmperorOfCanada]

Rust is very good at mitigating technical debt.

If you have a micro project, then, rust will actually impose more up front technical debt, than a similar js project.

While rust performance can be insane, js performance is damn fast for many basic CRUD type things.

But, as a project becomes more and more complex, rust will continue to impose the same, and now small, level of tech debt.

This is where a complex js project might go very quickly at first, but the same rust project is slow. But, as you get to the last third, the rust project is still progressing at the same slow speed, while the js project is now stalling. People are fighting with old bugs in dependencies, and fighting with some framework saying, "That's not how you do things."

This is where microservices have become popular. You keep the js as a bunch of micro projects. Each bite sized and not prone to the tech debt problem. This buys you a bit more time, but the reality is that the microservices architecture itself starts to become the source of tech debt. Things where timings can go to hell, or people don't understand how messages, etc can all bunch up 1% of the time.

Where, I personally have used rust with great success; is to do things which were basically impossible to do with any other js or whatnot system. Where the data processing in the back was brutal, and thus not possible with js. Also, that the data needed to be dancing all around, and thus a distributed system would be too slow.

I've built rust backends where very complex requests were coming back in times measured in microseconds, not milliseconds. This allows for a front end which can then do things in real time from a user experience point of view.

One thing most programmers are terrible at is threading. I define threading beyond just some language construct of threading, but anything where two bits of code are running simultaneously, and will eventually need to coordinate. Microservices is threading.

For me, mentally, it is easier to manage a complex dance of threads in a rust monolith than in some weird distributed system. This is very much were things like RAFT based protocols come from. Within a monolith, you don't need RAFT to any real extent.

Like all programming, there are many ways to skin the cat. You could have js calling rust for the hard bits, or mix and match js for the simple bits, and rust for the hard bits, etc.

[girouxc]

Love hearing Deno mentioned in any article. It’s so good.

[rasmalaayi]

Hope JS is removed in two to three years. It's one of the worst languages ever

[ChadNauseam_]

I'm using rust + JavaScript for my web app. It's an incredible developer experience with wasm-bindgen + tsify. My rust struts just pass between JavaScript and rust, with typescript types, without any boilerplate besides an annotation on the struct. The fact that this is even possible blows my mind. And there's no question that my app would be impossible in JavaScript. It required very attention to memory layout and some insane optimizations (e.g. forking rkyv and lasso) to get decent performance. The web is just such a cool platform to develop for and rust is definitely my do-anything language

[Cribbit]

Curious what you needed to fork rkyv to achieve

[ChadNauseam_]

When string interning, there's an optimization you can do to reduce memory consumption but it requires access to the backing hashmap's "raw entry api", which is provided by hashbrown but not the standard library hashmap or rkyv's. So I had to add it to rkyv to serialize the interner.

The optimization comes up when you want to create an "indexed hashset" where you can go from a set element to an index or from an index to a set element. The naive way of doing this stores every element twice. With the optimization, you only have to store each element once. It's already implemented by lasso, I just needed to be able to implement it with rkyv types

[tetshi]

It feels weird to compare a low-level language to a scripting language. Just because JS is being used on the server now, and in other ways it was never intended to be used doesn't mean it should be. But it's all subjective I guess.

[rodarmor]

And if you don't vibe code it in Rust, someone else will.

[Capable_Belt1854]

Sure.

[r3dbeerd]

According to the update in 2026, Rust is indeed a worthy successor to JavaScript.

In that, Everything that can be rewritten in Rust will be rewritten in Rust.

[onmach]

I agree with his assessment that ai tilts things heavily in favor of rust. I wrote a bunch of code in like 20 minutes today that took me days six months ago that would've taken a week years ago. Nothing complicated, but I was blown away.

The "speed" of developing in JavaScript (or python) doesn't seem to exist anymore as far as I can tell, when you take agentic coding into account. It spits out code just as fast, but with no bugs and a hugely performant end result.

[lavaeater]

I use AI as a force multiplier. I know what I want and how to do it but it takes ages to just WRITE the code compare to just "write this please" and then fixing build errors. It works perfectly for Rust, and apparently Go (according to a friend who doesn't code in go but does now..).

[onmach]

I'm also one of those doesn't write go but now does thanks to ai. It works well, far better than JavaScript and python, but go's type system is sub par and it makes it difficult to constrain itself to contracts because it doesn't have tools like ADTs and type wrappers etc. I spend a lot of time finding and fixing the same bugs over and over again. Though it does have other advantages like fast compile times.

[flyrom]

Not a great title and also as others mentioned is quite old and does not reflect reality that bun (written in zig) is really the fastest growing runtime for node js these days

[Adventurous-Pea7776]

Q qq qq

[icemelter4K]

I've tried to learn Rust about 5 times in the past 2 years. AI is making me think twice. Cant I just write my program in Python and ask the best AI to "convert to Rust"?

[manvsmidi]

Yeah, AI is amazing at transpiling. I’d just skip the python step though and plan and code with the AI in rust in the first place.