8 ms·

Deno 1.27

195 points by Mikkel-T 4y ago

alberth 4y ago
Dumb question: which appears most promising? Deno, Just-JS or Bun? (Genuine question. Not trolling)
- bastawhiz 4y ago
  I think they all serve different use cases. I'm not sure I could say one is more promising than another, because they're _all_ promising, and I don't see them as being in direct competition with each other.
- qwertox 4y ago
  Your question taught me that Just-JS and Bun exist. Thanks for asking.
- hardwaregeek 4y ago
  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.
- stephen 4y ago
  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. [1]: https://github.com/just-js/just.billywhizz.io/issues/3 https://github.com/just-js/just.billywhizz.io/issues/3
  - Mutjake 4y ago
    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 :-)
- kitsonk 4y ago
  The author of Just-JS is working on Deno as well.
- agumonkey 4y ago
  the three, after they merge into one :)
  - Petersipoi 4y ago
    While I suspect you're joking.. this doesn't seem likely given that all 3 are written in different languages
- deleted 4y ago
  [deleted]
- brundolf 4y ago
  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 of key features, and subjectively it just feels too "chaotic" for my tastes. They're designing it as they go, as fast as they can, but it feels like a wild ride. I'm not sure the creator even knows exactly where it'll end up, and in general it seems to prioritize "does everything you'd like it to right now" over "lay a new, better foundation for how the JS ecosystem works, unburdened by the historical baggage of Node" Two very different mindsets; it'll be really interesting to see which one wins. Personally I'm rooting for Deno, but I think each of them is pushing the other one to be better.
  - deleted 4y ago
    [deleted]
  - sramam 4y ago
    > 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.
    - brundolf 4y ago
      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.
      - SOLAR_FIELDS 4y ago
        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.
- mattwad 4y ago
  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.
- ilrwbwrkhv 4y ago
  Bun is the most excited I have ever been in the JavaScript ecosystem.
- 8K832d7tNmiQ 4y ago
  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 https://deno.com/deploy [1]:https://fresh.deno.dev/ https://fresh.deno.dev/
- justinmchase 4y ago
  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.
d4mi3n 4y ago
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.
- MuffinFlavored 4y ago
  > 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?
  - d4mi3n 4y ago
    The ability to infer types from NPM packages. If you have existing codebases with non-trivial apps, reworking all your dependencies makes the prospect of picking up Deno a non-starter. My understanding is prior to this release the Deno LSP didn’t have visibility into types from packages originating from NPM. Compatibility issues likely still exist, but I suspect the scope of work for an MVP substitution of Node for Deno is in the realm of possibility now when it wasn’t before.
  - brundolf 4y ago
    Deno has its own language server, unfortunately. This is necessary because of a few key aspects of Deno code that are incompatible with the regular TypeScript support, and it means Deno's editor integration is often a step behind mainline TypeScript
  - justinmchase 4y ago
    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.
stjo 4y ago
It seems to be down for me and for some reason the domain is not indexed by the web archive.
halfmatthalfcat 4y ago
As a Jetbrains user, somewhat annoying to see everything in VS Code.
- lucacasonato 4y ago
  Our editor integration is completely editor agnostic. Deno implements the Language Server Protocol [1], which essentially all editors support. Because of this the new inlay hints feature, is supported on all editors that support inlay hints and use our LSP integration. The Jetbrains integration for Deno uses our LSP, but I don't know if they support inlay hints yet. You can find docs on using Deno LSP with other editors here: https://deno.land/manual/getting_started/setup_your_environment#using-an-editoride https://deno.land/manual/getting_started/setup_your_environm... [1]: https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/
  - JLCarveth 4y ago
    I've been using Deno on neovim and it's been a breeze
- JLCarveth 4y ago
  An editor is an editor, why on earth would it bother you that someone uses a different editor than you?
  - randomguy0 4y ago
    Is this Jeopardy? Your question is essentially answered by his original comment.
    - JLCarveth 4y ago
      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.
triyambakam 4y ago
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.
- shafyy 4y ago
  I'm also dipping my toes in Deno (with Fresh) for a side project. Just curious, what were the blockers you came across with Oak?
  - kitsonk 4y ago
    Yeah, I would be interested to understand what challenges you had with oak too.
- JoyrexJ9 4y ago
  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
  - deleted 4y ago
    [deleted]
  - encryptluks2 4y ago
    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
rickstanley 4y ago
The video on the page doesn't have controls and I have Firefox block autoplay; fortunately, I can just right click and select play from context menu. Just giving notice.
flockonus 4y ago
Excited for the improvements, some big wins there! But surprised to see so many removals in the Changes section to what seems to be a minor version of a 1.x release. Nothing that hurts me personally, altho not Semantic Versioning and cautions shaky ground to build on?
- crowlKats 4y ago
  There are no removals in the CLI, and std is considered unstable, and due to that has different versioning that is still in 0.x
  - flockonus 4y ago
    Thanks for clarifying, could be perhaps more evident in the changelog. I know Node had this idea of unstable APIs, but in practice it's hard to enforce of course, if you're building a software & gotta rely on them.
intellectronica 4y ago
Link to cached blog post: https://readwise.io/reader/shared/01ggdaqh2rr2my3qc5rzw09kpw https://readwise.io/reader/shared/01ggdaqh2rr2my3qc5rzw09kpw
jmarneweck 4y ago
https://archive.vn/wxmIG https://archive.vn/wxmIG
Pr0ject217 4y ago
Nice! Time to upgrade.
Cupprum 4y ago
I really like the irony of this. The creator of node is fighting node now. Good jobs guys! You are doing nice job with deno.
jeffhwang 4y ago
Appreciate the improvements to npm compatibility. Does anyone have a sense of how close Deno is their estimate that 80-90% of npm packages would be working? I think they said this was what they were hoping for back in August.
e63f67dd-065b 4y ago
> 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 reason somewhere?
- deleted 4y ago
  [deleted]
- kitsonk 4y ago
  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.
- simlevesque 4y ago
  Node.js before v1 (maybe even until v4) was like this. It took like 5 years.
- KyleJune 4y ago
  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 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.
nerdponx 4y ago
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?
- deleted 4y ago
  [deleted]
- Yahivin 4y ago
  No real support, just a placeholder on their roadmap: https://github.com/denoland/deno/issues/1739 https://github.com/denoland/deno/issues/1739
- Tomuus 4y ago
  Things mostly just work. Remember Node.js is mostly APIs on top of JS the language. If those tools compile to JS in the browser, they can compile to Deno. Deno is a more stabdards-based runtime than Node, it's closer to how the browser works.
- rcoder 4y ago
  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.
rubenfiszel 4y ago
We bet big on deno with Windmill (OSS platform to turn scripts into internal UI and workflows) [1][2] and are extremely pleased. The language design choices and the performances/caching strategies are a perfect match for building a distributed workflow runtime at scale. However, the compatibility with npm was the most requested feature. Before the compatibility mode with npm was released, we were about to build a completely separate mode of execution based on node. This solves it very elegantly. Also super excited about the lsp improvements. I believe we are the only project to have a webeditor that features lsp integration with deno in the web (to test, go on [3], New Script -> Next, it works really well). It's very pleasant to work with and make the webeditor experience match closely a local dev setup. We are super excited about the improvements and I am about to try tonight if we can have the inline hints work with monaco. As we are fully open-source, one can see how we are able to pull it off [4][5]. [1]: https://windmill.dev https://windmill.dev [2]: https://github.com/windmill-labs/windmill https://github.com/windmill-labs/windmill [3]: https://app.windmill.dev https://app.windmill.dev [4]: https://github.com/windmill-labs/windmill/blob/main/frontend/src/lib/components/Editor.svelte https://github.com/windmill-labs/windmill/blob/main/frontend... [5]: https://github.com/windmill-labs/windmill/blob/main/lsp/pyls_launcher.py https://github.com/windmill-labs/windmill/blob/main/lsp/pyls...
andrewmcwatters 4y ago
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-end. I have little to no reason to try anything out. On a similar note, while people are switching from Webpack to Turbopack, I'm kicking back writing actual product features with a near buildless process. Because I simply don't care. I use the "Run JSX Preprocessor" straight out of the docs as I work and commit the output. Screwing around with switching back and forth and changing build configurations every few years reminds me of when back in the day people would supercustomize their desktop environments instead of just accepting them as they are. Is anyone really working up a sweat over security theatre like passing in args to flip permissions flags? Could you imagine how ridiculous that would sound in literally any other programming environment? That you can't trust your own software and its dependencies--that YOU built?
- alehlopeh 4y ago
- Sysctl232 4y ago
  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.
- veidr 4y ago
  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.

Deno 1.27

195 points by Mikkel-T 4y ago

alberth 4y ago

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

bastawhiz 4y ago
I think they all serve different use cases. I'm not sure I could say one is more promising than another, because they're _all_ promising, and I don't see them as being in direct competition with each other.
qwertox 4y ago
Your question taught me that Just-JS and Bun exist. Thanks for asking.
hardwaregeek 4y ago
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.
stephen 4y ago
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. [1]: https://github.com/just-js/just.billywhizz.io/issues/3 https://github.com/just-js/just.billywhizz.io/issues/3
- Mutjake 4y ago
  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 :-)
kitsonk 4y ago
The author of Just-JS is working on Deno as well.
agumonkey 4y ago
the three, after they merge into one :)
- Petersipoi 4y ago
  While I suspect you're joking.. this doesn't seem likely given that all 3 are written in different languages
deleted 4y ago
[deleted]
brundolf 4y ago
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 of key features, and subjectively it just feels too "chaotic" for my tastes. They're designing it as they go, as fast as they can, but it feels like a wild ride. I'm not sure the creator even knows exactly where it'll end up, and in general it seems to prioritize "does everything you'd like it to right now" over "lay a new, better foundation for how the JS ecosystem works, unburdened by the historical baggage of Node" Two very different mindsets; it'll be really interesting to see which one wins. Personally I'm rooting for Deno, but I think each of them is pushing the other one to be better.
- deleted 4y ago
  [deleted]
- sramam 4y ago
  > 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.
  - brundolf 4y ago
    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.
    - SOLAR_FIELDS 4y ago
      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.
mattwad 4y ago
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.
ilrwbwrkhv 4y ago
Bun is the most excited I have ever been in the JavaScript ecosystem.
8K832d7tNmiQ 4y ago
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 https://deno.com/deploy [1]:https://fresh.deno.dev/ https://fresh.deno.dev/
justinmchase 4y ago
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.

d4mi3n 4y ago

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.

MuffinFlavored 4y ago
> 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?
- d4mi3n 4y ago
  The ability to infer types from NPM packages. If you have existing codebases with non-trivial apps, reworking all your dependencies makes the prospect of picking up Deno a non-starter. My understanding is prior to this release the Deno LSP didn’t have visibility into types from packages originating from NPM. Compatibility issues likely still exist, but I suspect the scope of work for an MVP substitution of Node for Deno is in the realm of possibility now when it wasn’t before.
- brundolf 4y ago
  Deno has its own language server, unfortunately. This is necessary because of a few key aspects of Deno code that are incompatible with the regular TypeScript support, and it means Deno's editor integration is often a step behind mainline TypeScript
- justinmchase 4y ago
  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.

stjo 4y ago

It seems to be down for me and for some reason the domain is not indexed by the web archive.

halfmatthalfcat 4y ago

As a Jetbrains user, somewhat annoying to see everything in VS Code.

lucacasonato 4y ago
Our editor integration is completely editor agnostic. Deno implements the Language Server Protocol [1], which essentially all editors support. Because of this the new inlay hints feature, is supported on all editors that support inlay hints and use our LSP integration. The Jetbrains integration for Deno uses our LSP, but I don't know if they support inlay hints yet. You can find docs on using Deno LSP with other editors here: https://deno.land/manual/getting_started/setup_your_environment#using-an-editoride https://deno.land/manual/getting_started/setup_your_environm... [1]: https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/
- JLCarveth 4y ago
  I've been using Deno on neovim and it's been a breeze
JLCarveth 4y ago
An editor is an editor, why on earth would it bother you that someone uses a different editor than you?
- randomguy0 4y ago
  Is this Jeopardy? Your question is essentially answered by his original comment.
  - JLCarveth 4y ago
    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.

triyambakam 4y ago

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.

shafyy 4y ago
I'm also dipping my toes in Deno (with Fresh) for a side project. Just curious, what were the blockers you came across with Oak?
- kitsonk 4y ago
  Yeah, I would be interested to understand what challenges you had with oak too.
JoyrexJ9 4y ago
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
- deleted 4y ago
  [deleted]
- encryptluks2 4y ago
  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

rickstanley 4y ago

The video on the page doesn't have controls and I have Firefox block autoplay; fortunately, I can just right click and select play from context menu. Just giving notice.

flockonus 4y ago

Excited for the improvements, some big wins there! But surprised to see so many removals in the Changes section to what seems to be a minor version of a 1.x release. Nothing that hurts me personally, altho not Semantic Versioning and cautions shaky ground to build on?

crowlKats 4y ago
There are no removals in the CLI, and std is considered unstable, and due to that has different versioning that is still in 0.x
- flockonus 4y ago
  Thanks for clarifying, could be perhaps more evident in the changelog. I know Node had this idea of unstable APIs, but in practice it's hard to enforce of course, if you're building a software & gotta rely on them.

intellectronica 4y ago

Link to cached blog post: https://readwise.io/reader/shared/01ggdaqh2rr2my3qc5rzw09kpw https://readwise.io/reader/shared/01ggdaqh2rr2my3qc5rzw09kpw

jmarneweck 4y ago

https://archive.vn/wxmIG https://archive.vn/wxmIG

Pr0ject217 4y ago

Nice! Time to upgrade.

Cupprum 4y ago

I really like the irony of this. The creator of node is fighting node now. Good jobs guys! You are doing nice job with deno.

jeffhwang 4y ago

Appreciate the improvements to npm compatibility. Does anyone have a sense of how close Deno is their estimate that 80-90% of npm packages would be working? I think they said this was what they were hoping for back in August.

e63f67dd-065b 4y ago

> 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 reason somewhere?

deleted 4y ago
[deleted]
kitsonk 4y ago
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.
simlevesque 4y ago
Node.js before v1 (maybe even until v4) was like this. It took like 5 years.
KyleJune 4y ago
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 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.

nerdponx 4y ago

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?

deleted 4y ago
[deleted]
Yahivin 4y ago
No real support, just a placeholder on their roadmap: https://github.com/denoland/deno/issues/1739 https://github.com/denoland/deno/issues/1739
Tomuus 4y ago
Things mostly just work. Remember Node.js is mostly APIs on top of JS the language. If those tools compile to JS in the browser, they can compile to Deno. Deno is a more stabdards-based runtime than Node, it's closer to how the browser works.
rcoder 4y ago
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.

rubenfiszel 4y ago

We bet big on deno with Windmill (OSS platform to turn scripts into internal UI and workflows) [1][2] and are extremely pleased. The language design choices and the performances/caching strategies are a perfect match for building a distributed workflow runtime at scale. However, the compatibility with npm was the most requested feature. Before the compatibility mode with npm was released, we were about to build a completely separate mode of execution based on node. This solves it very elegantly. Also super excited about the lsp improvements. I believe we are the only project to have a webeditor that features lsp integration with deno in the web (to test, go on [3], New Script -> Next, it works really well). It's very pleasant to work with and make the webeditor experience match closely a local dev setup. We are super excited about the improvements and I am about to try tonight if we can have the inline hints work with monaco. As we are fully open-source, one can see how we are able to pull it off [4][5]. [1]: https://windmill.dev https://windmill.dev [2]: https://github.com/windmill-labs/windmill https://github.com/windmill-labs/windmill [3]: https://app.windmill.dev https://app.windmill.dev [4]: https://github.com/windmill-labs/windmill/blob/main/frontend/src/lib/components/Editor.svelte https://github.com/windmill-labs/windmill/blob/main/frontend... [5]: https://github.com/windmill-labs/windmill/blob/main/lsp/pyls_launcher.py https://github.com/windmill-labs/windmill/blob/main/lsp/pyls...

andrewmcwatters 4y ago

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-end. I have little to no reason to try anything out. On a similar note, while people are switching from Webpack to Turbopack, I'm kicking back writing actual product features with a near buildless process. Because I simply don't care. I use the "Run JSX Preprocessor" straight out of the docs as I work and commit the output. Screwing around with switching back and forth and changing build configurations every few years reminds me of when back in the day people would supercustomize their desktop environments instead of just accepting them as they are. Is anyone really working up a sweat over security theatre like passing in args to flip permissions flags? Could you imagine how ridiculous that would sound in literally any other programming environment? That you can't trust your own software and its dependencies--that YOU built?

alehlopeh 4y ago
Sysctl232 4y ago
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.
veidr 4y ago
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.