3 ms·

> I maybe chose the wrong horse and hopped onto deno early on. After reading through this thread, I'm personally leaning toward Deno for my first non-Node proj

> I maybe chose the wrong horse and hopped onto deno early on. After reading through this thread, I'm personally leaning toward Deno for my first non-Node project. Demo seems to be more thoughtfully managed, more pragmatic (e.g. Node/NPM compatibility), more secure, with better technology choices (e.g. Rust vs. Zig) overall.

culi 2y ago
I'm still a fan of Deno and hoping it wins out but > more pragmatic (e.g. Node/NPM compatibility) Both projects are good on this front. Deno actually originally explicitly promised NOT to work on node compatibility to "move the industry forward". They realized this was a failing move and backtracked (which has been a little controversial amongst the core base) > with better technology choices (e.g. Rust vs. Zig) I think it's a little silly to take the choice of language as a "technology choice". Both are new languages, both still have a lot to prove, and both have pros and cons the other lacks
porridgeraisin 2y ago
> Node/NPM compatibility Bun is miles better in this regard. Deno initially did not even want to focus on Node/NPM compatibility, and then backtracked once they understood the importance of it. Bun OTOH runs the entire Node.js test suite on every commit, and the mentality of breaking less existing node/npm code is clear. e.g, just in this release, `bun publish` has the exact same CLI as `npm publish`, and bun also works out of the box with .npmrc. About the Node.js test suite.. many modules are at 100% compatibility, and many are at 90%. You can track it here: https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis Also, they reimplement the V8 public C++ API in JavaScriptCore (!) so that packages like npmjs.com/cpu-features work [1] Every new feature has this aspect to it, e.g the postgres client inbuilt is a drop-in replacement for the `postgres` package. As far as Node/NPM compatibility, and thought given to compatibility in general, is concerned, there is absolutely no contest. And if I'm allowed a little snarky slight... Deno couldn't even maintain compatibility with their own API for reading and writing files during the Deno 1->2 update. [1]: https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v8-part-1 https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v...

culi 2y ago

I'm still a fan of Deno and hoping it wins out but > more pragmatic (e.g. Node/NPM compatibility) Both projects are good on this front. Deno actually originally explicitly promised NOT to work on node compatibility to "move the industry forward". They realized this was a failing move and backtracked (which has been a little controversial amongst the core base) > with better technology choices (e.g. Rust vs. Zig) I think it's a little silly to take the choice of language as a "technology choice". Both are new languages, both still have a lot to prove, and both have pros and cons the other lacks

porridgeraisin 2y ago

> Node/NPM compatibility Bun is miles better in this regard. Deno initially did not even want to focus on Node/NPM compatibility, and then backtracked once they understood the importance of it. Bun OTOH runs the entire Node.js test suite on every commit, and the mentality of breaking less existing node/npm code is clear. e.g, just in this release, `bun publish` has the exact same CLI as `npm publish`, and bun also works out of the box with .npmrc. About the Node.js test suite.. many modules are at 100% compatibility, and many are at 90%. You can track it here: https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis Also, they reimplement the V8 public C++ API in JavaScriptCore (!) so that packages like npmjs.com/cpu-features work [1] Every new feature has this aspect to it, e.g the postgres client inbuilt is a drop-in replacement for the `postgres` package. As far as Node/NPM compatibility, and thought given to compatibility in general, is concerned, there is absolutely no contest. And if I'm allowed a little snarky slight... Deno couldn't even maintain compatibility with their own API for reading and writing files during the Deno 1->2 update. [1]: https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v8-part-1 https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v...