Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)
Your question taught me that Just-JS and Bun exist. Thanks for asking.
Deno 1.27
31–40 of 71 posts
Re: Deno 1.27
#32Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)
imo just-js and bun are too early to tell. They're in that stage where they're cool and people talk about them, but they haven't gotten to that stage where there's adoption and therefore real criticism. Basically bun/just-js are being judged on their potential, while Deno is starting to be judged on its reality.
Re: Deno 1.27
#33Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)
My on-the-sidelines take is:
Bun seems most promising to me, because it's chasing amazing performance _and_ widespread adoption.
Like Just-JS has amazing performance [1], but the author is "just" (a very amazing/talented) benchmark hacker and not necessarily trying/wanting to put in the effort to have "a node replacement" and/or extend his Techempower-specific optimizations into APIs/libraries that would affect the performance day-to-day business apps (which I don't blame him for).
Deno is kinda :shrug: b/c its original "great security" pitch doesn't really matter to anyone who runs in containers.
Re: Deno 1.27
#34Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)
The author of Just-JS is working on Deno as well.
Re: Deno 1.27
#35Maybe this is a weird question, but how does Deno compare to Node when it comes to the various "languages that compile to JS"? For example Purescript, Fable, Elm, etc. does everything mostly just work, or should one stick to Node for those?
[deleted]
Re: Deno 1.27
#36Earlier quoted context omitted.
Pardon? I am asking OP why he's annoyed that the post mentions VSCode. It's not normal to be annoyed at the mere mention of a text editor. You should work on 1. your reading comprehension, and 2. making relevant comments to the discussion at hand.
They're not annoyed that the post mentions VSCode. They're annoyed that, from their experience, only VSCode is being supported.
VSCode is the only integration that the Deno core team maintains and develops. A rough poll indicates that about 80% of Deno users use vscode.
JetBrains/WebStorm now utilises the Deno language server directly (the same one that the VSCode integration uses) but they control how features are expressed in their client and when they deliver them, something the core team can't directly control.
So for various reasons, VSCode ends up being the focus.
Re: Deno 1.27
#37Maybe this is a weird question, but how does Deno compare to Node when it comes to the various "languages that compile to JS"? For example Purescript, Fable, Elm, etc. does everything mostly just work, or should one stick to Node for those?
No real support, just a placeholder on their roadmap: https://github.com/denoland/deno/issues/1739
Re: Deno 1.27
#38Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)
the three, after they merge into one :)
Re: Deno 1.27
#39I'm an eager and early adopter of Deno. I however look forward to ecosystem improvements, and the interop with npm is helpful. I was working on a side project recently that was a simple CRUD app and I just ended up going with Express on Node after fighting with Oak on Deno for a few days. It was still in the way enough to slow down the rapid fire development process that happens when you're still figuring out an idea…
Yeah NH gives a warped lens on how ready these runtimes & frameworks are for real work.
Threads about Deno and Bun pop up almost weekly, yet in my experience they remain a long, LONG way from the stable (and admittedly stale) experience we have with Node and NPM
Re: Deno 1.27
#40> RBTree has been removed from the collections module in favor of RedBlackTree. > direction has been removed from the collections module in favor of Direction. > CSVStream has been removed from the encoding module in favor of CsvStream Hmm I smell an interesting story here. If it's renaming for the sake of renaming then that's kinda dumb and breaks backwards compat for no reason, but presumably there's a better reaso…
std library is still considered "unstable" and the sub modules contained in there tend to have their own lifecycle as well. There has been effort to try to mature std to get to a stable version, which means cleaning up lots of things that would detract from long term maintainability.