4 ms·

Not a seasoned users, mostly played with Deno. To me Deno seems more oriented to be an alternative Node runtime with security as first principle and built-in su

Not a seasoned users, mostly played with Deno. To me Deno seems more oriented to be an alternative Node runtime with security as first principle and built-in support for Typescript, JSX with some tooling like linter. It's also based on V8. My best guess it's what Ryan Dahl wanted Node to be as an afterthought. Bun, technically speaking is based on Webkit, but can't really say why, seems a better all-in-on tool(also remember rome?) and not only a runtime. Also with compatibility with current frameworks out of box, Deno wasn't npm compatible some time ago and I wonder if it ever meant to be and not a pivotal change on the run

ShadowBanThis01 3y ago
It's known that Deno tacked on NPM support. For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all. The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.
- kozzz 3y ago
  You’re unlikely to encounter any issues with Node in a small project. It’s possible though that you’ll need some module that is not working with Deno.
  - ShadowBanThis01 3y ago
    Thanks. If I can do CRUD and client authorization I should be OK… I say now, anyway!
azu 3y ago
> technically speaking is based on Webkit, but can't really say why Why Bun uses WebKit/JSC was described here: > One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that. via https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-are-now-supported https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-ar...

ShadowBanThis01 3y ago

It's known that Deno tacked on NPM support. For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all. The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.

kozzz 3y ago
You’re unlikely to encounter any issues with Node in a small project. It’s possible though that you’ll need some module that is not working with Deno.
- ShadowBanThis01 3y ago
  Thanks. If I can do CRUD and client authorization I should be OK… I say now, anyway!

azu 3y ago

> technically speaking is based on Webkit, but can't really say why Why Bun uses WebKit/JSC was described here: > One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that. via https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-are-now-supported https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-ar...