Live data from Hacker News

Deno 1.27

deno.com

61–70 of 71 posts

Re: Deno 1.27

#61
post #51

Earlier quoted context omitted.

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

The pedigree of Deno does speak for at least something as well. Who better to address the flaws of a lasting project someone created than the creator themselves? Just from incentive alignment it’s a powerful motivator.

Re: Deno 1.27

#62

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…

I'm using deno (with oak) for a side project and it's great. I experimented with bun as well, but came back to deno because I got frustrated with bun's segfaulting (this was pretty early after their announcement).

Re: Deno 1.27

#63

I'm curious how strongly Deno matters to the developers in this space. Honestly, I just don't care. I really, really don't care. When Node.js succeeded PHP in industrial practice, it was enough then to get me to move since everyone had already jumped onboard quickly. Now, it's gotta take a LOT for me to want to move. I'm already too productive with Linux, Nginx, MySQL, and Node.js w/ Express, and React on the front-e…

No post body was provided.

Re: Deno 1.27

#64
post #33
post #28

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

As a quick note, while containers offer a degree of isolation, depending on your use case you might not want to put too many eggs into that basket (Linux privilege escalation bugs do happen). E.g. Firecracker VM is a relatively easy improvement to make of course, and on cloud env the container isolation might be Amazon’s/Microsoft’s problem. Just figured it would be good to mention not to see containers as a silver bullet, while they are better than not using containers on a shared host (and a useful tool in general :-)

Re: Deno 1.27

#65
post #28

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

I'd say deno, because they've already established a proper ecosystem since day one, has a working usage such as Deno Deploy[0] and Fresh[1], and already addresses some issues about distribution issue on Node, while bun still acts like a replacement for Node.

[0]:https://deno.com/deploy

[1]:https://fresh.deno.dev/

Re: Deno 1.27

#66

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

> Yeah NH gives a warped lens on how ready these runtimes & frameworks are for real work

I think it's more that HN is warping reality on how ready they are for real work. We are shaping what is going to happen next in tech, and how quickly, by being eager and ready to give things a try and, in a mix of above average skill and curiosity, being able to make it work at a fairly sophisticated level, despite its current shortcomings.

Re: Deno 1.27

#67

I'm curious how strongly Deno matters to the developers in this space. Honestly, I just don't care. I really, really don't care. When Node.js succeeded PHP in industrial practice, it was enough then to get me to move since everyone had already jumped onboard quickly. Now, it's gotta take a LOT for me to want to move. I'm already too productive with Linux, Nginx, MySQL, and Node.js w/ Express, and React on the front-e…

I get what you're saying. For me too everything is about developer experience, stability and business value. Rewriting to Deno will be a massive time sink with the lack of npm support and the small community compared to Node.js. Still, I applaud the effort to take JavaScript/TypeScript on V8 to the next level.

Re: Deno 1.27

#68
post #28

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

I have nothing bad to say about the other two but Deno is pretty great, I'm hoping it topples node.js at least, it seems poised to do so. Really lookin forward to playing with deno deploy too.

Re: Deno 1.27

#69
post #2

Better IDE support is huge. I know a lot of devs who liked the idea of Deno but weren't in a position to dump a lot of their development tooling to pick it up, so this effectively removes a big barrier to adoption for a lot of folks. Excited to see how well Deno's security features pan out under broader, real-world usage.

> I know a lot of devs who liked the idea of Deno but weren't in a position to dump a lot of their development tooling to pick it up if VS Code already supports TypeScript, what is missing?

It did still partially work but there was some friction with resolving types from ESM modules. For example in typescript+node if you're importing another module with esm you'd still have to import javascript like so:

``` import { Example } from "./example.js" // the actual file is example.ts ```

While in Deno you actually import the typescript file ``` import { Example } from "./example.ts" ```

That difference alone was enough to trip up the built-in typescript language tool and add friction.

Another thing is that Deno has a built in formatter / linter, you don't use a 3rd party tool like eslint, so having the ide just know how to do the linting and formatting is nice, the default typescript language plugin can't do that.

Also, Deno formats other file types including json, yaml and markdown.

Re: Deno 1.27

#70

I'm curious how strongly Deno matters to the developers in this space. Honestly, I just don't care. I really, really don't care. When Node.js succeeded PHP in industrial practice, it was enough then to get me to move since everyone had already jumped onboard quickly. Now, it's gotta take a LOT for me to want to move. I'm already too productive with Linux, Nginx, MySQL, and Node.js w/ Express, and React on the front-e…

You're definitely right. If so far you've only cared about PHP, until finally Node became dominant, then...

Yeah. You should just wait until 2035, then check again if Deno is relevant. If so, might be time to take another look.

Post reply on HN