back
1 comments
Briar only works on Android so it's inherently flawed.

Of course, Cabal being written in javascript is also a major minus. As an oldschool Unix hacker, I don't really get the node.js fixation for command line tools. It's a certainty that they'll never be used by a significant chunk of knowledgeable, expert Unix users that want nothing to do with node.

Finally, there is no protocol documentation anywhere that I can see. This is yet another way that these modern tools fail spectacularly. In the golden age of the Internet, published protocol documentation that allowed for multiple clients to be developed was the norm rather than the exception. Which led to robust, long living protocols and services (e.g. IRC).

Even though we're being drowned in apps, this isn't happening today and we're worse off for it.

No knowledgeable, expert Unix user I know brushes a Node program aside just because it is Node.
I don't brush aside Node programs just because they're Node. I brush them aside because they usually drag in a few MB of dependencies, and melt my (mid-level) computer with compilation (often OOM-killing everything else I'm doing on the machine, before dying to the OOM-killer itself) – but for all that, I then need to keep the entire thing on my hard drive because the compilation was mere caching, and hasn't given me an executable; I've still got the runtime overhead of Node, and everything that comes with it.

There are a few Python programs I also brush aside for this reason, though substantially fewer. Virtually every Node project I've seen is a spidery mess of dependencies bringing in dependencies bringing in yet more un-auditable dependencies; the worst Python tends to get is Tensorflow, and it's ready to run immediately (compiling C modules aside – though pip does that at installation time, making that a one-time annoyance for all but obscure C packages).

Melt your computer with compilation? A Node program?

More to the point, did you audit Tensorflow? If no, then what's your point to begin with? If yes, what made you conclude that auditing Tensorflow is doable, but usually simple NPM modules are "un-auditable"?

I didn't audit Tensorflow. But I don't install Tensorflow programs, anyway, because I don't have the resources.

The point isn't auditing, though; it's auditability. If it's auditable, then somebody's probably done it – but if it's not, you can't rely on just a spot check of a few dice-picked dependencies.

And what about these NPM modules is not auditable?
There are hundreds of them, and they are very large, and many have no clear purpose, and they keep getting new versions that change seemingly nothing, but actually change a lot.
> knowledgeable, expert Unix user

I wouldn't describe myself as that, but I think I'm a little bit past noob at this point.

I don't "brush aside" a program because it's node, but it's definitely a strike against it. I don't like dealing with the massive amount of dependencies that always seems to follow along with it.

<deleted>
I can't speak for Perl or Python, but for Ruby I have never seen a single Ruby tool that pulls in anything close to the same order of magnitude of discrete dependencies that some JS tools end up doing. I of course stand to be corrected.

I don't mind installing tools like Rollup and TypeScript. I do very much mind installing tools like Webpack and Babel.

On Pop!_OS,

    apt show python3-pip
shows six dependencies, while

    apt show npm
shows:

    nodejs (>= 6.11~), ca-certificates, node-abbrev (>= 1.1.1~), node-ajv, node-ansi, node-ansi-regex (>= 3.0~), node-ansi-styles, node-ansistyles, node-aproba, node-archy (>= 1.0~), node-are-we-there-yet, node-asap, node-asn1, node-assert-plus, node-asynckit, node-aws4, node-aws-sign2, node-balanced-match, node-bcrypt-pbkdf, node-bl, node-bluebird, node-boxen, node-brace-expansion, node-builtin-modules, node-builtins, node-cacache, node-call-limit, node-camelcase, node-caseless, node-chalk, node-chownr, node-ci-info, node-cli-boxes, node-cliui, node-clone, node-co, node-color-convert, node-color-name, node-colors, node-columnify, node-combined-stream, node-concat-map, node-concat-stream, node-config-chain, node-configstore, node-console-control-strings, node-copy-concurrently, node-core-util-is, node-crypto-random-string, node-cyclist, node-dashdash, node-debbundle-es-to-primitive, node-debug, node-decamelize, node-deep-extend, node-defaults, node-define-properties, node-delayed-stream, node-delegates, node-detect-indent, node-detect-newline, node-dot-prop, node-duplexer3, node-duplexify, node-ecc-jsbn, node-editor, node-encoding, node-end-of-stream, node-err-code, node-errno, node-es6-promise, node-escape-string-regexp, node-execa, node-extend, node-extsprintf, node-fast-deep-equal, node-find-up, node-flush-write-stream, node-forever-agent, node-form-data, node-from2, node-fs.realpath, node-fs-vacuum, node-fs-write-stream-atomic, node-function-bind, node-gauge, node-genfun, node-get-caller-file, node-getpass, node-glob (>= 7.1.2~), node-got, node-graceful-fs (>= 4.1.11~), node-gyp (>= 3.6.2~), node-har-schema, node-har-validator, node-has-flag, node-has-unicode, node-hosted-git-info (>= 2.6~), node-http-signature, node-iconv-lite, node-iferr, node-import-lazy, node-imurmurhash, node-inflight, node-inherits (>= 2.0.3~), node-ini (>= 1.3.5~), node-invert-kv, node-ip, node-ip-regex, node-isarray, node-isexe, node-is-npm, node-is-obj, node-is-path-inside, node-is-retry-allowed, node-is-stream, node-isstream, node-is-typedarray, node-jsbn, node-jsonparse, node-json-parse-better-errors, node-json-schema, node-json-schema-traverse, node-jsonstream (>= 1.3.2~), node-json-stringify-safe, node-jsprim, node-latest-version, node-lazy-property, node-lcid, node-libnpx, node-locate-path, node-lodash, node-lockfile (>= 1.0.3~), node-lowercase-keys, node-lru-cache (>= 4.1.1~), node-make-dir, node-mem, node-mime, node-mime-types, node-mimic-fn, node-minimatch, node-minimist, node-mississippi, node-mkdirp (>= 0.5.1~), node-move-concurrently, node-ms, node-mute-stream, node-nopt, node-normalize-package-data (>= 2.4~), node-npm-bundled, node-npm-package-arg (>= 6.1.1), node-npmlog (>= 4.1.2~), node-number-is-nan, node-oauth-sign, node-object-assign, node-once (>= 1.4~), node-opener, node-osenv (>= 0.1.5~), node-os-locale, node-os-tmpdir, node-package-json, node-parallel-transform, node-path-exists, node-path-is-absolute, node-path-is-inside, node-promise-inflight, node-promise-retry, node-promzard, node-performance-now, node-p-finally, node-p-is-promise, node-pify, node-p-limit, node-p-locate, node-prepend-http, node-process-nextick-args, node-proto-list, node-prr, node-pseudomap, node-psl, node-pump, node-pumpify, node-punycode, node-qs, node-qw, node-rc, node-read (>= 1.0.7~), node-readable-stream, node-read-package-json (>= 2.0.13~), node-registry-auth-token, node-registry-url, node-require-main-filename, node-require-directory, node-resolve-from (>= 4.0~), node-retry (>= 0.10.1~), node-rimraf (>= 2.6.2~), node-run-queue, node-safe-buffer, node-semver (>= 5.5~), node-set-blocking, node-sha (>= 2.0.1~), node-shebang-command, node-shebang-regex, node-signal-exit, node-slide (>= 1.1.6~), node-sorted-object, node-slash, node-semver-diff, node-spdx-correct, node-spdx-exceptions, node-spdx-expression-parse, node-spdx-license-ids, node-sshpk, node-ssri, node-stream-each, node-stream-iterate, node-stream-shift, node-strict-uri-encode, node-string-decoder, node-string-width, node-strip-ansi (>= 4.0~), node-strip-json-comments, node-strip-eof, node-supports-color, node-tar (>= 4.4~), node-term-size, node-text-table, node-through, node-through2, node-timed-out, node-tough-cookie, node-tunnel-agent, node-tweetnacl, node-typedarray, node-uid-number, node-unique-filename, node-unique-string, node-unpipe, node-url-parse-lax, node-util-deprecate, node-uuid, node-validate-npm-package-name, node-verror, node-which (>= 1.3~), node-which-module, node-wide-align, node-widest-line, node-wrap-ansi, node-wrappy, node-wcwidth.js, node-write-file-atomic, node-xdg-basedir, node-xtend, node-yargs, node-yargs-parser, node-yallist, node-y18n
What does that prove? The six dependencies are probably an order of magnitude larger than the NPM ones.

If anything, lots of small dependencies is more Unix-y than one big dependency.

> If anything, lots of small dependencies is more Unix-y than one big dependency.

Of course, as evidenced by much-used programs such as curl and git having 400 dependencies each and OpenSSL being shipped as separate libraries for every single crypto function.

pip's download size is 47.6 kB, npm's is 579 kB.

pip's installed size is 194 kB, npm's is 3,413 kB.

All numbers are from Pop!_OS apt.

If all of those dependencies are maintained by different teams, then it widens the surface area for unexpected bugs.

For something where you need security (i.e. a decentralized chat platform), this could be problematic.

We've all taken some git precommit hook that a coworker has helpfully provided, and rewritten it in bash so you don't need the entire node runtime to append a ticket number to a string.
> I don't really get the node.js fixation for command line tools.

It's simply because most developers are web developers. They use the programming language and tooling they're familiar with. I do also wish that there wasn't so much of a move to webify everything, particularly since web dev is so prone to constantly changing fads and dependency sprawl. It tends to lead to code/software that breaks all the time.

I’d say that JS desktop/web applications are becoming more prevalent due to most alternative GUI frameworks not being as simple and feature rich. I’d also say that this is most likely a side effect of most UI resources being targeted towards JS and therefore reducing the attention all other GUI tooling receives.