41–50 of 56 posts
For me, the key thing that is missing is dgram (UDP) support. Makes bun unusable for a lot of IoT scenarios.
Why would you want to use JavaScript in IoT scenarios?
Earlier quoted context omitted.
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…
The packaging situation is indeed messed up but that’s because TC39 decided to invent a maximally incompatible new module format. But you can not install CJS packages in Node just as well as you can not install them in Deno.
I don’t find configuring build systems enjoyable, but the benefit is that your dev environment is not tightly coupled. If your runtime is also your build system then there’s one tool doing two jobs. Some people might like this. I personally think that this kind of coupling causes more inconvenience over the long-term even if there’s less inconvenience up front.
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…
I'm all ears! Will revise it later today
Not sure about you, but I really do hate Babel, Prettify, tsc, uglify and all that. I think it's awesome that they are integrated in Deno and Bun, and starting to get integrated into Node.
We all know that Node has a massive ecosystem, job opportunities and all that, do I really need to list that as features? I don't think any company would read this and think "Woah, let's ditch node!"
Should I list "better compatibility with existing Node modules" as a feature for Bun?
Earlier quoted context omitted.
I think that in general, tooling is underrated. In many ways, tooling is more important than the language itself (although some language features are intertwined with the tooling story). And I don’t mean more features, but rather consistency, reproducibility, simplicity, etc. Great tools have knock on effects. Good dependency managers improve the ecosystem. Fast language servers can enable interactive dev style. And…
+1. Before I could understand benefits of Rist, I was sold on cargo.
Bun is getting a lot of hype due to all the press, but almost everyone is just echoing Bun's docs and marketing material and lack direct experience using it. I haven't done a deep dive into Bun yet, but I have tried porting a legacy project to it. Hit a lot of issues after a few hours of hacking around. It wouldn't correctly install node modules because of opt-in dependency lifecycles (and maybe other issues?) and th…
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…
> worse than I thought it would be, bordering on useless. I'm all ears! Will revise it later today Not sure about you, but I really do hate Babel, Prettify, tsc, uglify and all that. I think it's awesome that they are integrated in Deno and Bun, and starting to get integrated into Node. We all know that Node has a massive ecosystem, job opportunities and all that, do I really need to list that as features? I don't th…
Earlier quoted context omitted.
> worse than I thought it would be, bordering on useless. I'm all ears! Will revise it later today Not sure about you, but I really do hate Babel, Prettify, tsc, uglify and all that. I think it's awesome that they are integrated in Deno and Bun, and starting to get integrated into Node. We all know that Node has a massive ecosystem, job opportunities and all that, do I really need to list that as features? I don't th…
I think the problem with what you have now is that the feature comparison values "built in" above any other qualities. Obviously would require a much bigger article but I think the only way this is useful is if there is a comparison of tools in each runtime and "built in" is simply a pro in that comparison.
Earlier quoted context omitted.
I think the problem with what you have now is that the feature comparison values "built in" above any other qualities. Obviously would require a much bigger article but I think the only way this is useful is if there is a comparison of tools in each runtime and "built in" is simply a pro in that comparison.
How about something like " (Built in)", " (Native Ecosystem)", " (Third party), " " as a fix which avoids loads of text?
Bun is getting a lot of hype due to all the press, but almost everyone is just echoing Bun's docs and marketing material and lack direct experience using it. I haven't done a deep dive into Bun yet, but I have tried porting a legacy project to it. Hit a lot of issues after a few hours of hacking around. It wouldn't correctly install node modules because of opt-in dependency lifecycles (and maybe other issues?) and th…
I would consider it only for backend nodejs at the moment.
Earlier quoted context omitted.
I think that in general, tooling is underrated. In many ways, tooling is more important than the language itself (although some language features are intertwined with the tooling story). And I don’t mean more features, but rather consistency, reproducibility, simplicity, etc. Great tools have knock on effects. Good dependency managers improve the ecosystem. Fast language servers can enable interactive dev style. And…
Agreed. Go is prime example of a rather (intentionally) unsexy language that sports great tooling.
Rust/Cargo is the one I was most impressed by. But I haven't done any significant work in Rust.