Alright JS gang - anonymous, neutral poll:
Which of the new serverside JS runtimes do you suspect you will be using MOST in 2025? (not counting Node.js)
Going live with our meetup @YextEng in just a few minutes! Don't miss @swyx and @iam_nawaz on this livestream:
Unfortunately @hdjirdeh isn't able to make this meetup but we hope to feature him again in the future!
Tons — Hermes has no JIT, so it is very slow at runtime. Hermes optimizes entirely for startup time
JSC is more comparable to V8. JSC outperforms V8 at regexp, setting properties and some strings-related tasks whereas V8 tends to outperform at typed array access & promises
I briefly looked at using Hermes and using QuickJS for Bun. QuickJS would've been a lot easier to embed than JSC. But the runtime performance is very limiting
Thanks, helpful.
I'm thinking Hermes might make sense for CLIs where startup time really matters.
I do think JSC is better than V8 for what you're doing.
Being able to choose would be so cool! React Native has managed it, just a simple build toggle. Imagine shipping a CLI with bun and flipping a switch to bundle it with Hermes 🤯
I voted for Bun because I hope it gains more adoption and I would love to use it in a real project. However, Deno and especially Cloudflare Workers have a greater pull for production apps since they've been out longer.
Heh... Not making a judgement on the quality of any of these tools, but people are way misjudging the length of time it takes to get a company to scale up. 2025 is not that far away
Cloudflare Workers, or rather the product development that led to them, began like 8-10 years ago at least. I remember CF was doing stuff on the Edge with Lua for companies like Riot Games back then
Cloudflare has had some pretty big missteps though. Cloudflare Pages is an incredibly disappointing product. They've not done a great job explaining their KV/Durable Objects storage. They need a way more serious logs product
I think Cloudflare Workers/Pages is one of the most slept on innovations in web dev right now. If the dev & testing environments/tooling around those products was 10x better, they could make a serious dent in web app hosting market share, imho. KV storage alone is mind blowing.
Can just use the Cache API instead for that use case. This is a documentation/education problem IMO, serious lack of resources about the cloudflare platform
I've been seeing 15 - 30ms on hot reads and ~ 250ms for a cold read but the service isn't live in production yet so remains to be seen how consistent that is across different regions. At least for our use case, it works well for an edge lookup.
Even 15-30ms is slower than it needs be to fully take advantage of "the edge". That's a significant percentage of the roundtrip time between most users and edge locations (usually <50ms).
Compared to Redis on fly.io, which is consistently <5ms IME.
Fundamentally, if we're looking to squeeze every bit of latency out of a request, it's just really hard to beat a long lived server node that can amortize the cost of establishing the initial connection over its entire lifetime.
This is why I'm more bullish on Fly than CF.
Durable objects is pretty single handedly the most exciting development that I’ve seen. I’m using them to manage game state and I’ve never had a better developer experience and totally disagree on KV as well it’s equally brilliant and a joy to use. Im going to open source my game
FWIW, I've also been pretty disappointed at R2, which despite all the marketing around being globally distributed, happens to be abysmally slow at writes.
I remember seeing ~1s latency when I tried it, slower than writing to a S3 bucket on the other side of the planet.
When Cloudflare open sources their workers runtime and builds a good documentation and community behind it, I think that’ll be a big deal for me. Bun is still new and I’m undecided, but it looks very promising.
Yeah I think everyone voting for Bun is underestimating what it takes to build an entire deployment platform around a runtime.
For Bun to win it can't just be better than Deno and Workers, it needs to also have something better than Deno Deploy and the entire Workers platform.
I cant imagine choosing bun here. So much unproven, so experimental. V8 has been proven for over a decade on the server, bun will move faster than node but I don't imagine it'll be ready for production in less than 3 years
I think deno is probably a better benchmark. That's only recently gotten production ready IMO in the "rapid" timeframe of 2 years since 1.0. bun is still a way off from a 1.0, let alone being stable enough for production usage
Observing Deno, it seems like they could have built that on top of JavaScriptCore rather than V8, and it wouldn’t have made that big a difference. Most of the work is in the layers in top?
V8 was already embedded in node (and other places) at this time. That's a huge amount of prior art to draw from. Deno choosing v8 definitely helped them ship faster
It absolutely helped them ship faster, but is JavaScriptCore “not being proven on the server” really that big a factor in Bun’s trajectory?
It could be, I’m just not convinced it’s that clear cut. It feels pretty close in Bun today.
the coldly logical answer is Cloudflare Workers
people overestimate the value of a functions only platform with nothing else
there's a reason that Lambda, which has the worst DX, is used 100x more than any of these
CF workers is the closest to not being functions only
Agree that things like KV are a big plus, but the whole tooling around Workers (esp wrangler and Cloudflare's web UI) is a pain in the butt and not my idea of DX.
Exactly. We’re long Cloudflare but judging from their (lack of) feature velocity Microsoft and Google still have a chance of getting their edge/serverless shit together before Cloudflare closes the general app dev gap.
Can you remove all the knowledge you have in the ecosystem, look at it with fresh/newbie eyes, and say the same? I'm pretty curious.
I find when we take a step back from *loads* of things we're very familiar with/find easy, we find that they aren't actually intuitive at all.
But yeah, to your point, I haven't revisited the AWS stack in years, due to the horrible DX (as experienced firsthand). Would love to see what, if anything they've improved. Even if they haven't, it just means they have loads of opportunities to catch up :)
this is really the entire premise of our work at SST
raw primitives in AWS are very complete, just needs a proper framework to use the good parts and avoid the bad parts
I'll have to check out what you guys are doing!
I definitely agree that there's a ton of great tech in the AWS ecosystem, as it obviously powers much of the world. :)
Nope. I still remember how much time I have spent to get up and running with simple function that returns hello world(with api-gateway). Even today it's hard to do it manually through console(without IaC).
with R2, D1, and... probably eventually their mythical "D2" (whatever that is... postgres?) to wrap their "R2, D2" moniker are going to give Workers such a productivity boost
Missing from poll: @billywhizz1970's Just_JS (v8 only for x86/Linux).
Faster than some Java, Rust, C++, C#, Go stacks:
Otherwise, Bun or a OSS version of CloudFlare Workers; I'm allergic non-OSS lock-ins.
Haven't tried it yet, but assuming eventually it becomes more stable/feature complete, I think bun's ability to both support existing node packages out of the box but also do its own thing will make for a smoother transition curve than deno's createRequire() shim
Of course, deno can change until 2025. node might also change (in fact it is already changing). I don't think a proprietary runtime will win. And I think JSC being used server side will contribute to the ecosystem health overall