Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.27

deno.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Deno 1.27

#51

Post by sramam »

brundolf wrote: post #45
alberth wrote: post #28

Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)

From the little I've read about just-js, I'm not sure it's even trying to be a competitor with the others for their main use-cases I think Deno has the strongest overall vision, and it's a vision I really want to see become the new default Bun is compelling with its blistering pace and its ruthless dedication to performance, compatibility, and Just Works user experience. However, it's still very new and missing a lot…

> unburdened by the historical baggage of Node

Is this even possible anymore?

Deno made a valiant attempt, but with every release, the best received update seems to be the node/npm compatibility.

Re: Deno 1.27

#52

Post by brundolf »

sramam wrote: post #51
brundolf wrote: post #45

Earlier quoted context omitted.

From the little I've read about just-js, I'm not sure it's even trying to be a competitor with the others for their main use-cases I think Deno has the strongest overall vision, and it's a vision I really want to see become the new default Bun is compelling with its blistering pace and its ruthless dedication to performance, compatibility, and Just Works user experience. However, it's still very new and missing a lot…

> unburdened by the historical baggage of Node Is this even possible anymore? Deno made a valiant attempt, but with every release, the best received update seems to be the node/npm compatibility.

I see NPM compatibility as a temporary stopgap. They tried to make a hard break all at once, and then Bun made it clear that no, actually people still really want access to that existing ecosystem for now.

But new code written for Deno starts out on that better foundation without CommonJS, several different module-resolution algorithms, manual transpilation, competing linting and testing standards, etc etc. They just need to bridge the gap in the meantime, until Deno's own ecosystem gets more filled out. That's the dream anyway.

Re: Deno 1.27

#53

Post by mattwad »

alberth wrote: post #28

Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)

My guess is none of them will ever replace Node.js, but they will all help shift the momentum of Node.js to be faster, better support for Typescript, etc. Similar to how folks created io.js at one point and that eventually got merged back into Node.js.

Deno seems like to offer a better dev experience, and because it's created by Dahl it's the only one I take seriously as an alternative.

Re: Deno 1.27

#54

Post by Petersipoi »

agumonkey wrote: post #38
alberth wrote: post #28

Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)

the three, after they merge into one :)

While I suspect you're joking.. this doesn't seem likely given that all 3 are written in different languages

Re: Deno 1.27

#55

Post by lucideer »

sramam wrote: post #51
brundolf wrote: post #45

Earlier quoted context omitted.

From the little I've read about just-js, I'm not sure it's even trying to be a competitor with the others for their main use-cases I think Deno has the strongest overall vision, and it's a vision I really want to see become the new default Bun is compelling with its blistering pace and its ruthless dedication to performance, compatibility, and Just Works user experience. However, it's still very new and missing a lot…

> unburdened by the historical baggage of Node Is this even possible anymore? Deno made a valiant attempt, but with every release, the best received update seems to be the node/npm compatibility.

What's interesting though is that the compatibility effort seems to be on all sides. Deno has acted somewhat like a forcing function - I think a lot of Node folk want to move away from CommonJS in general (even staying within the NPM ecosystem) & having multiple targets for modules you write has given that effort some good pushes.

A simple example of this in my mind is the node: prefix added to CommonJS functions in NodeJS. This has some perf/caching advantages, which may have been the main driver, but also introducing a protocol prefix to module strings happens to improve extensibility/flexibility/compat across the ecosystem - there are transpilers that change e.g. import to require() or vice-versa, so extra context in module strings is helpful there. Deno's npm: prefix has a similar effect (it would be cool if this made it into Node someday - having control over module locator strategy at import granularity seems interesting; it would certainly make a lot of bundler hacks currently in use for things like CSS/etc. simpler)

Re: Deno 1.27

#56

Post by rcoder »

nerdponx wrote: post #27

Maybe 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?

For languages that can emit clean ESM JavaScript source and don't depend on special tooling or runtime support you can totally drop the generated JS files into a Deno project and import them.

...but you're even _more_ on your own w.r.t. bugs, compatibility issues, and the basic assumption that everything will be running inside Node, and therefore trivially able to access e.g. `npx` or various scripting+automation tools.

Your best bet today is to run Node in your development environment, then use the generated code in a Deno service/CLI wrapper/etc. It's clunky, but you can get there.

Re: Deno 1.27

#57

Post by encryptluks2 »

JoyrexJ9 wrote: post #39
triyambakam wrote: post #7

I'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

I don't know that they are made to.

Npm packages already do too much, with package.json being used to run scripts that have permission to do nefarious tasks to relying on C libraries.

If I were to use Deno it would be with the understanding that I'd need to find dependencies that are generic and standard... Not expect everything from npm to work by default.

If I used either I'd specifically look for dependencies that are standard enough to not matter or

Re: Deno 1.27

#58

Post by KyleJune »

e63f67dd-065b wrote: post #24

> 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…

At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are.

https://github.com/denoland/deno_std/pull/2400

The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted.

I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime would be if the standard module was depending on runtime APIs that have a breaking change.

Re: Deno 1.27

#60

Post by schemescape »

encryptluks2 wrote: post #57
JoyrexJ9 wrote: post #39

Earlier quoted context omitted.

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

I don't know that they are made to. Npm packages already do too much, with package.json being used to run scripts that have permission to do nefarious tasks to relying on C libraries. If I were to use Deno it would be with the understanding that I'd need to find dependencies that are generic and standard... Not expect everything from npm to work by default. If I used either I'd specifically look for dependencies that…

Hopefully it has changed, but when I was using Deno, there wasn’t a standard for TypeScript libraries that worked in both environments (due to Deno requiring file extensions on imports and tsc requiring no file extension on imports). There was a workaround using import maps, but it’s not tenable for large libraries.
Post reply on HN