4 ms·

They basically said they were taking a risk (node/npm incompatible) for a big long-term benefit. They gave up on that forever, for some short-term growth. How m

They basically said they were taking a risk (node/npm incompatible) for a big long-term benefit. They gave up on that forever, for some short-term growth. How many more times would they back-pedal on any risk they announced taking?

skybrian 1y ago
They did say something like that, but I don’t remember what the big long-term benefit was supposed to be. What specifically did they give up? Maybe it wasn’t that important after all.
- afavour 1y ago
  Their original announcement post covers it pretty well: https://deno.com/blog/v1 https://deno.com/blog/v1 IMO their logic still holds up. Dahl had a whole talk about the mistakes made with Node: https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
  - skybrian 1y ago
    I haven’t done all that much network programming in Deno, but I think it’s still fairly easy to get “promises all the way down” by sticking with Deno API’s? What’s your experience with this?
    - afavour 1y ago
      My complaint is not with Deno APIs. From what I’ve seen they’re great. My problem arrives the moment you install a dependency, because it isn’t using Deno APIs. And digging into exactly what any dependency is doing is often an odyssey through transpiled-to-ES3 JavaScript, outdated APIs and so on. The original promise of Deno was a consistent ecosystem. Absent that it doesn’t matter to me all that much how great Deno is within itself, the case for using it simply isn’t compelling enough. These days the newer, standards-compliant Node APIs are pretty good too!
      - monooso 1y ago
        Surely you can choose to only install "Deno native" dependencies? It may sometimes be difficult to find such an option, but that was always going to be the case without Node compatibility. Now, in theory at least, you have the option of sticking with Deno native dependencies, and an escape hatch when none are available. That seems like the most pragmatic solution to the ideology vs adoption dilemma.
- the_gipsy 1y ago
  They gave up on a quality Deno ecosystem. And being relevant.

skybrian 1y ago

They did say something like that, but I don’t remember what the big long-term benefit was supposed to be. What specifically did they give up? Maybe it wasn’t that important after all.

afavour 1y ago
Their original announcement post covers it pretty well: https://deno.com/blog/v1 https://deno.com/blog/v1 IMO their logic still holds up. Dahl had a whole talk about the mistakes made with Node: https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
- skybrian 1y ago
  I haven’t done all that much network programming in Deno, but I think it’s still fairly easy to get “promises all the way down” by sticking with Deno API’s? What’s your experience with this?
  - afavour 1y ago
    My complaint is not with Deno APIs. From what I’ve seen they’re great. My problem arrives the moment you install a dependency, because it isn’t using Deno APIs. And digging into exactly what any dependency is doing is often an odyssey through transpiled-to-ES3 JavaScript, outdated APIs and so on. The original promise of Deno was a consistent ecosystem. Absent that it doesn’t matter to me all that much how great Deno is within itself, the case for using it simply isn’t compelling enough. These days the newer, standards-compliant Node APIs are pretty good too!
    - monooso 1y ago
      Surely you can choose to only install "Deno native" dependencies? It may sometimes be difficult to find such an option, but that was always going to be the case without Node compatibility. Now, in theory at least, you have the option of sticking with Deno native dependencies, and an escape hatch when none are available. That seems like the most pragmatic solution to the ideology vs adoption dilemma.
the_gipsy 1y ago
They gave up on a quality Deno ecosystem. And being relevant.