3

!Deno

Being now able to write import 'npm:<name>' and it just working is quite hilarious, not having to use nodejs but still using the projects built on it .. wwwwww

Comments
  • 4
    NPM is like 60% of the problems with Node.
  • 3
    The runtime itself also isn't optimal, but delegation culture makes it so much worse.
  • 2
    Same thing with using rust bindings to a c lib vs the c lib natively via make or whatever

    Thats the power of good tooling, baby!
  • 0
    Does that mean demo comes with a node runtime? Gross.
  • 0
    @AlgoRythm

    1. It's called Deno, not Demo

    2. Obviously it doesn't
  • 0
    @ElectroArchiver yeah, that's a typo, but how could it run node modules without node?

    Answer: it does, and it doesn't.

    Deno has a standard library package of node "polyfills" to help npm modules work.

    Deno doesn't support all npm packages. Anything with native plugins is completely unsupported. It looks like there's some problems with importing other modules too.

    In short, only very basic npm modules will likely work without issue.
  • 0
    @AlgoRythm No, the vast majority works, which is what matters.
  • 0
    @ElectroArchiver curious what the difference is between implementing 80% of node and just calling yourself a node runtime is

    Deno was so self-righteous about NOT being node in the beginning. Now they're desperate because they aren't catching on and they're like "hey guys, you can use your npm modules with us!"

    Absolutely pathetic move.
  • -1
    @AlgoRythm You sounds like you cope a lot ..

    Understanding the difference between supporting code written for node ( mostly commonJS ) and reimplementing a runtime isn't that hard ..
  • 0
    @ElectroArchiver writing code supporting a system = implementing a runtime, literally. They've implemented most of the node stdlib, which is completely fucked because the original mission of deno was to get rid of the awful design patterns in node. They were annoyingly clear about this.

    Now you can just import your shitcode into deno - and even worse, you have no guarantee it will work.

    This is so fucked lol
  • 0
    @AlgoRythm

    > writing code supporting a system = implementing a runtime, literally.

    That doesn't make it a nodejs runtime just because you implement npm support.

    Oh no, they have improved onboarding, what are people gonna do.. how awful, now trasitioning is so much easier and people might switch to Deno .. oh no, now npm code can be run with the same security features as Deno code ..

    I'm so sad I'm now able to use big existing libraries like Babel without any issues ..
  • 0
    @ElectroArchiver deno fanboys are so insufferable lol
  • 0
    @AlgoRythm deno haters are so insufferable lol
  • 0
    @ElectroArchiver I'm not a deno hater I loved it's initial design. I never found a production use case for it, but I really really appreciated the typescript and testing out of the box thing. Now that they're getting nearer to competing with node, they just turn into node. Absolute fucking shame.
  • 0
    @AlgoRythm Deno is totally like NodeJS but with

    - Good documentation

    - Simple module hosting ( Don't even need an NPM account )

    - Security features

    - Doesn't need a package.json

    - Doesn't have a node_packages folder

    - Better standard library

    - Typescript support out of the box

    - More performant than node

    - ESModules as default
  • 0
    @ElectroArchiver these dumb desktop-javascript runtimes are literally just defined by their standard library and environment. Otherwise it's just V8.

    Pulling in npm and partially implementing the node stdlib leaves deno with fewer advantages, not more.

    And the fact that not 100% of node modules work makes it even worse than what npm has to offer because now it's dependency hell AND testing hell because your dependencies could break at any point.
  • 0
    @AlgoRythm

    As the 'not Deno hater' that started with

    'Does that mean demo comes with a node runtime? Gross.'

    go ahead and continue your pointless ranting while I will continue to enjoy my easy life using Deno.
  • 0
    @ElectroArchiver pretty clearly hating on the node runtime there, sorry your reading comprehension has mislead you :(
  • 0
    @AlgoRythm ( ་ ⍸ ་ ) Sure.
  • 1
    @AlgoRythm So does WSL make Windows a Linux implementation? Does Wine make Linux a Windows implementation? Does the mere existence of either imply that both OSes replicate each other's problems?
  • 0
    @lorentz ah that's my bad, I didn't realize that WSL and Wine were integral parts of Windows and Linux. I thought they were extra packages installed by the user to do a specific job. But I guess you're right, installing WSL and having Node.JS built into the standard fucking Deno library are 1:1 comparable.

    If WSL came with Windows by default then you probably could say that Windows is an implementation of Linux now. Bizarre but true.
  • 1
    @AlgoRythm Wine comes standard with many many distros, none of which are equivalent to Windows because of it. Windows and Node aren't just an interface, they're also a codebase, a set of standard practices, a roadmap, a pile of tech debt. Deno can improve everything and then provide a compatibility layer to make the transition easier.
  • 0
    @lorentz sorry ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯ implementing something makes you an implementation of it. Deno is now an implementation of Node.JS
  • 1
    @AlgoRythm If you're gonna be pedantic, at least be pedantic correctly. Deno is an implementation of Node's APIs. The absence of those APIs was never a feature in Deno, just that there's something better and you can do anything without ever using them.
  • 1
    Implementing (most of) an API defined as the feature set of some exact software does not make a competitor identical to that original software.
Add Comment