7 ms·

Wonder what itch this is scratching (security? RiiR/TS?). The IMHO biggest flaw of node (no std lib) still seems present.

by mhd 7y ago

lioeters 7y ago
I don't know, I feel like Node.js has a fairly full-featured and useful standard library? https://nodejs.org/api/ https://nodejs.org/api/ --- From the OP: Comparison to Node.js - Deno does not use npm - It uses modules referenced as URLs or file paths - Deno does not use package.json in its module resolution algorithm. - All async actions in Deno return a promise. Thus Deno provides different APIs than Node. - Deno requires explicit permissions for file, network, and environment access. - Deno always dies on uncaught errors. - Uses "ES Modules" and does not support require(). Third party modules are imported via URLs: import * as log from "https://deno.land/std/log/mod.ts"; https://deno.land/std/log/mod.ts";
- mrkurt 7y ago
  We (fly.io) use Deno pretty intensely. We really like: * No npm spaghetti, just requiring a URL is a win * It'll build a lightweight static binary. Usually way smaller than the equivalent node Docker image * The stdlib and every community lib were written at a time when async/await was the norm. So they're all very nice to use compared to wildly inconsistent node libs
  - samblr 7y ago
    Can you give size difference between both?
  - lioeters 7y ago
    Very interesting to hear. I didn't realize Deno was "production ready", I'd been curious about it for a long time. Your comment inspired me to study Deno deeper and consider it for practical use. In addition to the pros you've listed, seamless integration of TypeScript sounds fantastic. Would love to hear more about how Deno is used in your company!
- throwawayblahhh 7y ago
  > I don't know, I feel like Node.js has a fairly full-featured and useful standard library? IMO not really. We have many Java and JS projects where I work, I can't find a single Java project that has bigger dependencies than even our smallest JS project, or even an empty "create react app". One of our Java projects is 200k+ lines and still has smaller dependencies than create react app or a empty project created with angular cli. In JS, it's normal to pull in 500+ libraries and this is only because the standard library is so lacking. Our Java projects, even massive ones, pull in less than 100. In Java you also have Guava and Apache Commons. Those cover about 95% of data structure needs for a project not covered by the JVM. JS has nothing comparable. People lament about how "big" the JVM is, but you trade complexity of the VM for complexity of your own app. In practice Java projects are smaller and use less space and memory because your dependencies aren't using 10 different libraries to pad whitespace. This also makes it much easier to mentally transition between Java projects. If they were built in the last decade, they're probably using the standard library, Guava/Commons, hibernate, and some HTTP interface. I can move between Java projects at work no problem, but if it's Node or front-end 90% of the time I'm going to spend a few days learning a new framework to get anything done. Small standard libraries are very harmful to the ecosystem. I hope to God they do it right with Deno, batteries included like Python and Java
  - chrisco255 7y ago
    The average size of these JS packages is much smaller than the Java packages. "Create React App" is not a Node.js app proper, even though it uses Node and NPM to build and run, the end result is a statically served package that gets deployed as HTML, CSS, and JS. CRA would be a front end app, and front end apps have completely different needs than Node.js backend apps. My experience with Java projects is >1GB in RAM usage minimum (although it's been a couple years since I've written Java, so I don't know what improvements the JVM has made) whereas a Node app can run just fine on <100MB. Again, conflating Node.js backend and JS front end apps is not a fair comparison to Java as a backend platform. Stick to apples and apples. Node.js has quite a few standard libraries, although it's very common to use a framework like Express (and Express has been the top framework on Node.js since the earliest days of Node). The most difficult thing about going back to an older Node code base is that promises weren't officially supported, so there's often a 3rd party library for that or callbacks were used instead. The main benefit of Node.js to me, remains the use of a single language across the front end and back end. You can often use the same libraries so you suffer very little context-switching penalty when bouncing back and forth.
nmcfarl 7y ago
The linked document claims that this is the std lib: https://github.com/denoland/deno/tree/master/std https://github.com/denoland/deno/tree/master/std
- eerrt 7y ago
  They also note most of it is a loose port of Go's standard lib, which is quite good imo.
  - Rapzid 7y ago
    Go's stdlib mistakenly sorted files by default on directory walks(with no option to not sort them). This of course means a directory must be fully iterated on before you can process or bail out of processing. I wonder if Deno ported this directly or reworked it. There are some other issues with file stats as well; requiring multiple syscalls to retrieve information that can be had in just one. It's a mystery to me why they made such a high level decision in such low level code without an escape hatch.. Been a lot of talk but probably won't be fixed any time soon due to backwards compatibility.
    - TheDong 7y ago
      > with no option to not sort them Just implement your own directory walk based on `readdir` or whatever fs operations you need directly. Or use a library that has already done this: https://github.com/karrick/godirwalk#configurable-sorting-of-directory-children https://github.com/karrick/godirwalk#configurable-sorting-of... The high level interface made one choice. The escape hatch is to use a lower level interface.
      - Rapzid 7y ago
        readdir is problematic in ways godirwalk works around. Of course one could always just make direct syscalls or use a library that does, but this was a comment about stdlib. These would likely be implemented differently in hindsight per discussions on the Go project; and there have been discussions about improving them somehow in Go 2(readdir2?).
hmcdona1 7y ago
Watch the talk linked above. He goes into a lot of the reasons. Security is definitely a big one. Other things seem to be addressing problems that originated from poorly informed decisions early in development that the node.js community has had to deal with ever since (require() based module resolution, npm, etc...).
- mhd 7y ago
  I wasn’t just thinking about the features themselves, but the big picture. It does seem a bit exploratory to me (weren’t the non-V8 parts written in Go once?)
- z3t4 7y ago
  Node.JS's require, the lexical scoped module system, encourages you to lift out code as modules, rather then "include files". The difference between an "include file" and a "module" is that modules can have dependencies, but can be reused elsewhere. While "include files" depends on the environment where they are included. Now if you have a module that can be reused elsewhere, why not share it to the world!? So instead of copying random pieces of code from here and there, with Node.JS you got an official library repository aka NPM.
  - kevinkassimo 7y ago
    You don't really need NPM hosting with Deno. What you need is an index: sources can be hosted elsewhere independently, and instead people can build sites for popular module lookups. A package manager is different from package hosting. In the case of Deno you can still build and use third party package managers (and they might be able to utilize Deno's import-maps support to achieve some "magic")
    - aikah 7y ago
      How and does deno deals with extensions built in C/C++ for instance?
      - 7y ago
cdaringe 7y ago
So many! First class TS for starters, vs TS being a bolt on which is always onboards build steps and config. Drastically improved module and security systems. And lastly, it fills a the need for a portable, JIT, statically typed scripting language that doesn't really exist ATM in the mainstream with "good" dev ergonomics. I love that the me doc calls it out as a replacement for bash and python scripts. Bash is useful for running other programs but is terrible for scripting. For those of us that drink the types kooolaid, it's lighter and "more correct" than python. I thought maybe Julia was going to fill this need, but it hasn't really taken root.

Wonder what itch this is scratching (security? RiiR/TS?). The IMHO biggest flaw of node (no std lib) still seems present.

by mhd 7y ago

Wonder what itch this is scratching (security? RiiR/TS?). The IMHO biggest flaw of node (no std lib) still seems present.

lioeters 7y ago

I don't know, I feel like Node.js has a fairly full-featured and useful standard library? https://nodejs.org/api/ https://nodejs.org/api/ --- From the OP: Comparison to Node.js - Deno does not use npm - It uses modules referenced as URLs or file paths - Deno does not use package.json in its module resolution algorithm. - All async actions in Deno return a promise. Thus Deno provides different APIs than Node. - Deno requires explicit permissions for file, network, and environment access. - Deno always dies on uncaught errors. - Uses "ES Modules" and does not support require(). Third party modules are imported via URLs: import * as log from "https://deno.land/std/log/mod.ts"; https://deno.land/std/log/mod.ts";

mrkurt 7y ago
We (fly.io) use Deno pretty intensely. We really like: * No npm spaghetti, just requiring a URL is a win * It'll build a lightweight static binary. Usually way smaller than the equivalent node Docker image * The stdlib and every community lib were written at a time when async/await was the norm. So they're all very nice to use compared to wildly inconsistent node libs
- samblr 7y ago
  Can you give size difference between both?
- lioeters 7y ago
  Very interesting to hear. I didn't realize Deno was "production ready", I'd been curious about it for a long time. Your comment inspired me to study Deno deeper and consider it for practical use. In addition to the pros you've listed, seamless integration of TypeScript sounds fantastic. Would love to hear more about how Deno is used in your company!
throwawayblahhh 7y ago
> I don't know, I feel like Node.js has a fairly full-featured and useful standard library? IMO not really. We have many Java and JS projects where I work, I can't find a single Java project that has bigger dependencies than even our smallest JS project, or even an empty "create react app". One of our Java projects is 200k+ lines and still has smaller dependencies than create react app or a empty project created with angular cli. In JS, it's normal to pull in 500+ libraries and this is only because the standard library is so lacking. Our Java projects, even massive ones, pull in less than 100. In Java you also have Guava and Apache Commons. Those cover about 95% of data structure needs for a project not covered by the JVM. JS has nothing comparable. People lament about how "big" the JVM is, but you trade complexity of the VM for complexity of your own app. In practice Java projects are smaller and use less space and memory because your dependencies aren't using 10 different libraries to pad whitespace. This also makes it much easier to mentally transition between Java projects. If they were built in the last decade, they're probably using the standard library, Guava/Commons, hibernate, and some HTTP interface. I can move between Java projects at work no problem, but if it's Node or front-end 90% of the time I'm going to spend a few days learning a new framework to get anything done. Small standard libraries are very harmful to the ecosystem. I hope to God they do it right with Deno, batteries included like Python and Java
- chrisco255 7y ago
  The average size of these JS packages is much smaller than the Java packages. "Create React App" is not a Node.js app proper, even though it uses Node and NPM to build and run, the end result is a statically served package that gets deployed as HTML, CSS, and JS. CRA would be a front end app, and front end apps have completely different needs than Node.js backend apps. My experience with Java projects is >1GB in RAM usage minimum (although it's been a couple years since I've written Java, so I don't know what improvements the JVM has made) whereas a Node app can run just fine on <100MB. Again, conflating Node.js backend and JS front end apps is not a fair comparison to Java as a backend platform. Stick to apples and apples. Node.js has quite a few standard libraries, although it's very common to use a framework like Express (and Express has been the top framework on Node.js since the earliest days of Node). The most difficult thing about going back to an older Node code base is that promises weren't officially supported, so there's often a 3rd party library for that or callbacks were used instead. The main benefit of Node.js to me, remains the use of a single language across the front end and back end. You can often use the same libraries so you suffer very little context-switching penalty when bouncing back and forth.

nmcfarl 7y ago

The linked document claims that this is the std lib: https://github.com/denoland/deno/tree/master/std https://github.com/denoland/deno/tree/master/std

eerrt 7y ago
They also note most of it is a loose port of Go's standard lib, which is quite good imo.
- Rapzid 7y ago
  Go's stdlib mistakenly sorted files by default on directory walks(with no option to not sort them). This of course means a directory must be fully iterated on before you can process or bail out of processing. I wonder if Deno ported this directly or reworked it. There are some other issues with file stats as well; requiring multiple syscalls to retrieve information that can be had in just one. It's a mystery to me why they made such a high level decision in such low level code without an escape hatch.. Been a lot of talk but probably won't be fixed any time soon due to backwards compatibility.
  - TheDong 7y ago
    > with no option to not sort them Just implement your own directory walk based on `readdir` or whatever fs operations you need directly. Or use a library that has already done this: https://github.com/karrick/godirwalk#configurable-sorting-of-directory-children https://github.com/karrick/godirwalk#configurable-sorting-of... The high level interface made one choice. The escape hatch is to use a lower level interface.
    - Rapzid 7y ago
      readdir is problematic in ways godirwalk works around. Of course one could always just make direct syscalls or use a library that does, but this was a comment about stdlib. These would likely be implemented differently in hindsight per discussions on the Go project; and there have been discussions about improving them somehow in Go 2(readdir2?).

hmcdona1 7y ago

Watch the talk linked above. He goes into a lot of the reasons. Security is definitely a big one. Other things seem to be addressing problems that originated from poorly informed decisions early in development that the node.js community has had to deal with ever since (require() based module resolution, npm, etc...).

mhd 7y ago
I wasn’t just thinking about the features themselves, but the big picture. It does seem a bit exploratory to me (weren’t the non-V8 parts written in Go once?)
z3t4 7y ago
Node.JS's require, the lexical scoped module system, encourages you to lift out code as modules, rather then "include files". The difference between an "include file" and a "module" is that modules can have dependencies, but can be reused elsewhere. While "include files" depends on the environment where they are included. Now if you have a module that can be reused elsewhere, why not share it to the world!? So instead of copying random pieces of code from here and there, with Node.JS you got an official library repository aka NPM.
- kevinkassimo 7y ago
  You don't really need NPM hosting with Deno. What you need is an index: sources can be hosted elsewhere independently, and instead people can build sites for popular module lookups. A package manager is different from package hosting. In the case of Deno you can still build and use third party package managers (and they might be able to utilize Deno's import-maps support to achieve some "magic")
  - aikah 7y ago
    How and does deno deals with extensions built in C/C++ for instance?
    - 7y ago

cdaringe 7y ago

So many! First class TS for starters, vs TS being a bolt on which is always onboards build steps and config. Drastically improved module and security systems. And lastly, it fills a the need for a portable, JIT, statically typed scripting language that doesn't really exist ATM in the mainstream with "good" dev ergonomics. I love that the me doc calls it out as a replacement for bash and python scripts. Bash is useful for running other programs but is terrible for scripting. For those of us that drink the types kooolaid, it's lighter and "more correct" than python. I thought maybe Julia was going to fill this need, but it hasn't really taken root.