Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno vs. Bun vs. Node.js: A feature comparison

dev.hexagon.56k.guru

Post reply on HN
Print view View original

31–40 of 56 posts

Re: Deno vs. Bun vs. Node.js: A feature comparison

#31

Post by yieldcrv »

Xantier wrote: post #30
yieldcrv wrote: post #29

Earlier quoted context omitted.

My positive experience with NextJS by VC backed Vercel ($2.5bn valuation) makes me not skeptical of a package by mere nature of it being maintained and marketed by a for profit company with heavy VC investment. Its all about how it integrates and how it avoids vendor lock in.

I feel differently about next.js after their latest shenanigans. Their end goal clearly seems to be vendor lock-in to the Vercel/next.js platform, whichever way it ends up happening. The current attempt looks to be to tweak and assert control over the React library, to make it Vercelified.

you mean like with the app folder?

so far because I can still deploy out the box in other places its flying under my radar

and its just convenient that vercel is easy to be a place of simple free deployment, for now

when they pull a Heroku I’m gone.

Re: Deno vs. Bun vs. Node.js: A feature comparison

#32

Post by zarzavat »

jauntywundrkind wrote: post #18
ozten wrote: post #12

Earlier quoted context omitted.

Good point. Bun promises compatibility with existing mainstream web development technologies (CommonJS, ES Modules, NodeJs APIs, Typescript, etc). Deno promised "Node", but done a second time the right way (Typescript, new APIs, new package manager, etc). Which is not an entirely new language / platform, but different enough that you have to buy into the Deno vision.

Deno in my view was promising web. They actively fought against being Node at all for a long time, & differentiated themselves in being much much less, no package.json at all. Only recently has Deno gotten deep Node intercompatibility, after years of trying to leave that shit behind & finally giving in to the needs to be part of the vast npm externality. The general principle has & still is evident. It's not totally…

I just don’t understand why I would want to use Deno. I totally get the idea of wanting a modern Node, and I can appreciate Deno as a form of art. But does it help me do my job better than with Node? The browser API compat doesn’t move me at all, I can have that in Node as well… same with Typescript, it works just fine in Node, in fact I like having it separate because I can configure my build exactly how I want.

Re: Deno vs. Bun vs. Node.js: A feature comparison

#33

Post by yieldcrv »

Any real benchmarks with version 1.0?

Has anybody replaced everything with Bun in their 100 dependency project with a loose scaffolding of a deprecated node version due to some crucial dependency

This is the kind of thing I want to see even before using bun in a greenfield project

Re: Deno vs. Bun vs. Node.js: A feature comparison

#34

Post by jauntywundrkind »

zarzavat wrote: post #32
jauntywundrkind wrote: post #18

Earlier quoted context omitted.

Deno in my view was promising web. They actively fought against being Node at all for a long time, & differentiated themselves in being much much less, no package.json at all. Only recently has Deno gotten deep Node intercompatibility, after years of trying to leave that shit behind & finally giving in to the needs to be part of the vast npm externality. The general principle has & still is evident. It's not totally…

I just don’t understand why I would want to use Deno. I totally get the idea of wanting a modern Node, and I can appreciate Deno as a form of art. But does it help me do my job better than with Node? The browser API compat doesn’t move me at all, I can have that in Node as well… same with Typescript, it works just fine in Node, in fact I like having it separate because I can configure my build exactly how I want.

I've spent way too long fighting node.js having bitterly sad compromises in esm support. I've spent way too long hunting through tsconfig options looking for some option that maybe might help.

These problems keep recurring. Every time I start a small library, yes, I know I'll make it through, eventually. But I feel lessened by the battle. Compromises are made.

I personally feel little enjoyment for configuring build chains. A good fraction for the packages I download have people that made cute interesting personal decisions about how to package stuff - since there is no guidance & no standard - that clashes & conflicts with everything else. Or is distributed as es2015 cjs. Other people's ability to choose, their ability to like configuring their build actively impedes the general flow.

Most people dont get the web platform compat. But unjs, cloudflare workers, and dozens of others are just amazing lovely platforms that work so well, and which are often fairly cross portable with little lift. It's fine that you are happy in your niche, but having actual well adopted interoperable protocols has let some really interesting pick & choose futures start to emerge, and it's where the early adopters are. It's where the good stuff is formenting. You don't have to be there now, you can stay in your zone, but is is growing, and it's because of wintercg interoperability efforts all centered around growing web platform ideas outward.

Re: Deno vs. Bun vs. Node.js: A feature comparison

#37

Post by evnix »

yieldcrv wrote: post #33

Any real benchmarks with version 1.0? Has anybody replaced everything with Bun in their 100 dependency project with a loose scaffolding of a deprecated node version due to some crucial dependency This is the kind of thing I want to see even before using bun in a greenfield project

Did this recently, on a largish project based on express and typeorm. The only issue we had was with a native image manipulation library in combination with alpine linux image which was an easy fix. Rest worked flawlessly. Performance wasn't an issue for us, Dev experience was really bad on Node and the amount of hacks required to get esm/commonjs working in tandem was insane. Bun got rid of a lot of those hacks and we are slowly cleaning up the codebase.

Re: Deno vs. Bun vs. Node.js: A feature comparison

#39

Post by dzogchen »

ozten wrote: post #2

Bun's #1 killer feature is that web application tooling has become a nightmare that everyone dreads dealing with. Bun promises one tool designed for DX to solve bundling, testing, runtime, and more. Even if Bun didn't have a better performance story, I would evaluate switching to it to reduce project complexity.

I would argue that random segfaults are not particularly good DX.

Re: Deno vs. Bun vs. Node.js: A feature comparison

#40

Post by booi »

SkyMarshal wrote: post #6
report-to-trees wrote: post #3

I wasn't expecting a deep and thorough comparison just from the headline... but the feature list and comparison text here is worse than I thought it would be, bordering on useless. "Built in" means nothing because the value prop of node compared to the other two is the ecosystem and maturity. Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes? "Secure by default" in par…

> Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes? In general I would expect a linting tool or any other component that is a first class feature of the app would be less likely to be released with bugs and breaking changes than a third party one.

In this day and age the “linting” tool does a lot more than just respond yes or no. It usually has a rules engine, templates, config file support and enforces a lot more things than just syntactical correctness.

With that in mind it’s probably impossible to build a linter that’s going to be able to serve these needs that’s also built-in and on the same release cadence as the runtime itself.

Post reply on HN