5 ms·

People underestimate the node compatibility that Deno offers. I think the compat env variable will do a lot of adoption. Maybe a denon command or something coul

by voat 1y ago

People underestimate the node compatibility that Deno offers. I think the compat env variable will do a lot of adoption. Maybe a denon command or something could enable it automatically? Idk.

CuriouslyC 1y ago
Honestly, I was bullish on Deno back in the day, but I don't see why I'd use it over Bun now.
- jitl 1y ago
  Less segfault, improved security / capability model
  - spiffytech 1y ago
    As a Bun user I don't really get segfaults anymore.
    - fleetfox 1y ago
      https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20label%3Acrash https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
    - surajrmal 1y ago
      I've written C for years. The only time it is safe from crashes is when the code doesn't churn and has consistent timing between threads. bun has constant feature churn and new hardware it runs on all the time providing novel timings. It is very unlikely going to be crash free any time soon.
    - drewbitt 1y ago
      Just got one today! But yes it is better.
  - tmikaeld 1y ago
    The security model is very underestimated imo, it will be very evident when more bun projects reach production and not experimental.
  - beef_rendang 1y ago
    If the drive is towards greater performance by leveraging native code, at what point do we just bypass the JavaScript runtime abstraction and build directly with a language like Rust? The ecosystem seems to have hit a critical mass for web development. You now have incredibly mature and production-ready frameworks like Actix and Axum, along with innovative ones like Warp and Tide, providing everything you'd expect from routing and middleware to templating and native JSON handling. There are crates for everything, like for databases, there's powerful options like sqlx for fully async compile-time checked queries or Diesel for a feature-rich ORM, so it feels like all the pieces are there.
    - jitl 1y ago
      If you want to use rust, and it fits your use case, then use rust. Same as with any language choice if it’s the right thing for you then go ahead. I have a few million lines of existing TypeScript so will keep using JS runtimes for the foreseeable future.
- pjmlp 1y ago
  I have yet no reason to fight IT and architects for having anything besides node on CI/CD pipelines and base images for containers.
efilife 1y ago
The deno compatibility with node has been a lie for me. I tried to port a simple project (100-200 LOC) to deno and it took me an hour which should have been 5-10 minutes. It didn't support some of node's methods and if it did, it was completely undocumented. Had to install basic functionality from some obscure URLS. Onxe it came to porting my test suite I just gave up. The problem was CJS -> ESM transition that was way more painful than I anticipated it to be. And definitely not as simple as deno's docs make it to be. Couldn't just port the whole library

by voat 1y ago

People underestimate the node compatibility that Deno offers. I think the compat env variable will do a lot of adoption. Maybe a denon command or something could enable it automatically? Idk.

CuriouslyC 1y ago

Honestly, I was bullish on Deno back in the day, but I don't see why I'd use it over Bun now.

jitl 1y ago
Less segfault, improved security / capability model
- spiffytech 1y ago
  As a Bun user I don't really get segfaults anymore.
  - fleetfox 1y ago
    https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20label%3Acrash https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
  - surajrmal 1y ago
    I've written C for years. The only time it is safe from crashes is when the code doesn't churn and has consistent timing between threads. bun has constant feature churn and new hardware it runs on all the time providing novel timings. It is very unlikely going to be crash free any time soon.
  - drewbitt 1y ago
    Just got one today! But yes it is better.
- tmikaeld 1y ago
  The security model is very underestimated imo, it will be very evident when more bun projects reach production and not experimental.
- beef_rendang 1y ago
  If the drive is towards greater performance by leveraging native code, at what point do we just bypass the JavaScript runtime abstraction and build directly with a language like Rust? The ecosystem seems to have hit a critical mass for web development. You now have incredibly mature and production-ready frameworks like Actix and Axum, along with innovative ones like Warp and Tide, providing everything you'd expect from routing and middleware to templating and native JSON handling. There are crates for everything, like for databases, there's powerful options like sqlx for fully async compile-time checked queries or Diesel for a feature-rich ORM, so it feels like all the pieces are there.
  - jitl 1y ago
    If you want to use rust, and it fits your use case, then use rust. Same as with any language choice if it’s the right thing for you then go ahead. I have a few million lines of existing TypeScript so will keep using JS runtimes for the foreseeable future.
pjmlp 1y ago
I have yet no reason to fight IT and architects for having anything besides node on CI/CD pipelines and base images for containers.

efilife 1y ago

The deno compatibility with node has been a lie for me. I tried to port a simple project (100-200 LOC) to deno and it took me an hour which should have been 5-10 minutes. It didn't support some of node's methods and if it did, it was completely undocumented. Had to install basic functionality from some obscure URLS. Onxe it came to porting my test suite I just gave up. The problem was CJS -> ESM transition that was way more painful than I anticipated it to be. And definitely not as simple as deno's docs make it to be. Couldn't just port the whole library