ExpressJS vs. Actix-Web: performance and running cost comparison (opens in new tab)

I’m skeptical of this finding out at least it’s generalizability. I know (and like) Rust a fair bit better than JS, but I would be surprised if I could build a nontrivial web app in Rust faster than Node. And that’s without using TypeScript. YMMV, but I’d be curious to hear from others with experience with both languages.

JavaScript isn’t the only way to write Node.

I know Rust alright, and I like it. I’d rather write TypeScript for most web applications and I write good and solid TypeScript a lot faster than I do Rust. (Helps that I can easily write the same language and use many of the same libraries on my frontend, too.)

A common language across front and backend systems is a huge benefit. I find it extremely productive to have a backend in Typescript on NodeJS, and a frontend in ReactJS, talking over a GraphQL layer where I'm autogenerating Typescript types from the GraphQL typedefs. Means I can share many libraries and tooling across the front and back ends, but most importantly it means devs feel much more comfortable digging into code on the other side. If a front end dev has an issue with a backend API call, he can just pull down the code and instantly inspect it and submit a PR of necessary without feeling "out of his element".

Development speed is one. If the author were more familiar with JavaScript (e.g. knowing what const does) it might have gone faster. Using TypeScript should erase the development time delta due to static types.

If you're creating a frontend web app to go along with it there are others, such as reduced context–switching and using fewer tools.

Frankly, a sample size of one is incredibly weak evidence that it's faster to develop using one technology than another. If you glance through the author's Twitter/GitHub it's also clear that he works with Rust significantly more than he does with Node, which makes this particular sample even more suspect.

Another upside: you'll never be stumped implementing something in Javascript/TS. There is no lifetime management. And the entire ecosystem is async-everything. You aren't stuck in an async-ready subecosystem like you are in Rust, Python's Twisted, Ruby's Event Machine, etc.

"... wanted to bootstrap a business by optimizing costs" -- The famous quote "premature optimization is the root of all evil" comes to mind. :-) As a fellow tech entrepreneur, thinking long and hard about my planned startup's technology stack, I was also guilty of initially leaning toward a scalable, safe, enterprise-y and fancy, but less mature, stacks, like C# on .NET Core and Julia, correspondingly. However, upon my extensive research and thinking, I'm now leaning toward using Python and Flask for API-focused backend and Vue for frontend. After all, unless you're the next Google (or, at least, Dropbox), costs of your infrastructure would be negligible compared to business costs associated with people (due to salaries) and lost time-to-market advantage (due to higher complexity and learning curve). Should a startup become wildly successful and scale-driven cost optimization would become an issue, it most likely would make much more sense from the strategy perspective to ask a team to rewrite the platform(s) - or, rather, its relevant performance-critical parts - into a highly-performant language, like Rust. Having said that, I still think that the containerized applications (not necessarily microservices!) approach might be preferable, despite corresponding increase in extra complexity, learning curve, efforts and costs, because IMO the above-mentioned extras are less significant (and, thus, more affordable for a bootstrapping startup) than those associated with attempting to use new to founders or relevant team or not mature enough language and corresponding technology stack.

Koa is better but still has 43 dependencies...

I even once got a `!!!someVariable` in a codebase I inherited. It's what convinced me that the previous devs weren't doing weird things to work around a bad backend: they just didn't know what they were doing

I really don't think the results would be significantly different.

I tried to make changes and run his benchmarks, however the DB seeding is in Rust and it fails to compile on my machine....

> Your claims about being dead are wildly exaggerated and misleading.

I’d say they’re outdated. The project after the original author was frustrated with some in the community, found a way to allow the project to continue, which is overall good, but still a very disappointing episode.

I feel like Koa JS deserves a mention.

https://koajs.com/

If it is a small project I'd recommend just using the built in http server. It is what all these projects use anyway, and if it's just a few routes it's usually easier to just use that instead of pulling in more dependencies.

Better support for promises? Koa 2 since 4 years ago.

Yes, it is active with many recent contributions. The goal was to show how much opportunity is there for making things more optimal from running perspective. Imagine how much of cpu power and electricity wasted