4 ms·

Cant resist digging at Node.js even when writing up how infinitely better Node.js is at dealing with packages than python, haha: > Let’s try removing is-odd to

Cant resist digging at Node.js even when writing up how infinitely better Node.js is at dealing with packages than python, haha: > Let’s try removing is-odd to demonstrate how badly designed this package is: You literally just deleted is-even 's dependency on is-odd then have the audacity to be shocked that it broke? There's a lot of hatred for the small package philosophy of node.js, but it's also a huge win, stands a good chance of being why javascript has been such a winner, gotten so far: very explicit small things that say what they do on the tin. Rather than repeat yourself by making a copy pasted is-even and then maintaining both, it makes perfect sense to compose functionality, to build off what we have. And it is easier to understand the scope of what a package is & what it can do when it is explicitly limited in scope. This is another place where there is lots of loud vociferous animosity against what is, but it's there for good reason. And with rare rare exception- left-pad rage-quit deliberate breakage, for example, it serves well. With the exception that yes, inventorying your stuff is hard.

zdragnar 4y ago
It would be nice if major node packages invested time in re-inventing the wheel, just a little bit. Back when I used it, I really appreciated how little bloat Hapi added to node modules, compared with webpack for example. Obviously there's a world of difference in what problems the two solve, but still...
kdazzle 4y ago
I’m biased, but I do like Python’s package management much better than Node. Even just regular old virtualenvs. Can’t tell you how many times deleting the node packages dir and reinstalling fixes a weird issue, but that’s happened very rarely for me on the python side. Also, having to comb through a bunch of node packages of dubious quality to find some sort of standard approach happens way too often. Like take python requests vs axios.
- revskill 4y ago
  I've tried with venv before, and the console (Iterm) just get broken.
- phailhaus 4y ago
  I'd say that Node's package management has run laps around Python's, to the point where it's pretty embarrassing. Since it's relatively new, it was able to hit the ground running with best practices: 1. Declarative package manifests. Python's ecosystem is still a mess of various approaches, and the fact that you have to run the setup.py script to determine dependencies is a nightmare. Because of this, running dependency resolution and installing is an order of magnitude faster in Node than in Python. 2. Drop-dead simple isolated environments: everything's in `node_modules`. You literally can't make a mistake by blindly running `npm install` in the project dir. With Python it's on you to manage your virtualenv, which boils down to PATH manipulation and symlinks that you'll have to remember to undo when switching around. There's no default for what to call your venv either, so it's on you to settle on a standard and gitignore it. Every time you run `pip install`, you have to hesitate and make sure you're in the right environment, or else risk borking the wrong env (or your global!) 3. Out-of-the-box comprehensive lockfile support. Debugging Python dependency issues is a nightmare. There's literally no way to figure out why a dependency was installed without using 3rd party tools (like pipdeptree). In Node, simply running `npm install` will automatically generate a proper lockfile. I work full stack, and the difference is like night and day. I barely think about dependency management in Node.
  - gen220 4y ago
    Respectfully, this reads like you're using outdated Python tools. Give Poetry [1] a shot, it has all the things you've listed here. Just as Node.js has come a long way in the last 5 years, Python has, too. Albeit, in a fashion that was much less centralized, arguably to Python's detriment. [1]: https://python-poetry.org/history/#100---2019-12-12 https://python-poetry.org/history/#100---2019-12-12, released 1.0 in 2019/12.
    - phailhaus 4y ago
      Oh yeah, I've used Poetry. I'm talking about Python out of the box. The dependency management ecosystem is super fractured and relies on 3rd party tools developing their own standards, and even then, they can't overcome fundamental limitations. For example, Poetry is great but locking/installation still takes way longer than Node because there are no declarative manifests.
Kwpolska 4y ago
There’s a place for small packages, but is-even/is-odd is a bit too small to be a reasonable package. It is far easier to just write `x % 2 === 0` inline, which is an obvious idiom, instead of installing and importing a separate package for this. The use of is-odd by is-even can be confusing for users. For example, you may call isEven(0.5) and get the following error: RangeError: is-odd expects an integer. at isOdd (/tmp/mynodeproject/node_modules/is-odd/index.js:17:11) at isEven (/tmp/mynodeproject/node_modules/is-even/index.js:13:11) at Object.<anonymous> (/tmp/mynodeproject/index.js:3:13) (But the main point of the demonstration was to showcase dependency resolution and where it looks for packages.)
- rektide 4y ago
  isEven is in thay stack trace - should not confuse anyone with even a basic introductory level fluency at coding. Is it too small? What if latter the language evolves BigInt? Donwe suffer a patchwork of libraries which have & havent upgraded, sussing around each time to find out? I think the key thing to recognize is that this is all opinion. Many people dont like the availability of many opions, the ease at which dependencies have grown. And that's fine, there's some real pain here to having ballooning package trees. There's a pevel of conceit though that I feel that often arises, where we mock & shiv packages like is-even . But to me, it's not absolute, it's a matter of taste & preference. It looks weird to outsiders, but it has been enormously powerful & helpful, has been such a key successful element of JS that npm arose & made package management easy & package publishing easy & that we begat a new behavior of capturing all the little helpful things we do & making them available. Maybe there are good reasons for inlining simple things, but it's not clear to me what the gains really are, or what's wrong with is-even.
  - rektide 4y ago
    Doubling down, there's just huge conceit that small modules are bad. And no evidence. People just love to hate. Dark side is easy & convenient & in reach, and one gains social clout, feels elite, by shitting on others. Boo to you. It's not easy, it's not tame, but it's unclear what negativity beyond mild inconvenience has been generated. And much of the harm can be diffused with more sensible protection, not simply giving all modules access to everything. Systems like WASI are finally engineering inbuilt protection to sensibly de-risk imports; this is a fault of runtimes for not offering us protection, not our burgeoning package ecosystems for having value, growing. It's still unclear what the worthwhile protests are.

zdragnar 4y ago

It would be nice if major node packages invested time in re-inventing the wheel, just a little bit. Back when I used it, I really appreciated how little bloat Hapi added to node modules, compared with webpack for example. Obviously there's a world of difference in what problems the two solve, but still...

kdazzle 4y ago

I’m biased, but I do like Python’s package management much better than Node. Even just regular old virtualenvs. Can’t tell you how many times deleting the node packages dir and reinstalling fixes a weird issue, but that’s happened very rarely for me on the python side. Also, having to comb through a bunch of node packages of dubious quality to find some sort of standard approach happens way too often. Like take python requests vs axios.

revskill 4y ago
I've tried with venv before, and the console (Iterm) just get broken.
phailhaus 4y ago
I'd say that Node's package management has run laps around Python's, to the point where it's pretty embarrassing. Since it's relatively new, it was able to hit the ground running with best practices: 1. Declarative package manifests. Python's ecosystem is still a mess of various approaches, and the fact that you have to run the setup.py script to determine dependencies is a nightmare. Because of this, running dependency resolution and installing is an order of magnitude faster in Node than in Python. 2. Drop-dead simple isolated environments: everything's in `node_modules`. You literally can't make a mistake by blindly running `npm install` in the project dir. With Python it's on you to manage your virtualenv, which boils down to PATH manipulation and symlinks that you'll have to remember to undo when switching around. There's no default for what to call your venv either, so it's on you to settle on a standard and gitignore it. Every time you run `pip install`, you have to hesitate and make sure you're in the right environment, or else risk borking the wrong env (or your global!) 3. Out-of-the-box comprehensive lockfile support. Debugging Python dependency issues is a nightmare. There's literally no way to figure out why a dependency was installed without using 3rd party tools (like pipdeptree). In Node, simply running `npm install` will automatically generate a proper lockfile. I work full stack, and the difference is like night and day. I barely think about dependency management in Node.
- gen220 4y ago
  Respectfully, this reads like you're using outdated Python tools. Give Poetry [1] a shot, it has all the things you've listed here. Just as Node.js has come a long way in the last 5 years, Python has, too. Albeit, in a fashion that was much less centralized, arguably to Python's detriment. [1]: https://python-poetry.org/history/#100---2019-12-12 https://python-poetry.org/history/#100---2019-12-12, released 1.0 in 2019/12.
  - phailhaus 4y ago
    Oh yeah, I've used Poetry. I'm talking about Python out of the box. The dependency management ecosystem is super fractured and relies on 3rd party tools developing their own standards, and even then, they can't overcome fundamental limitations. For example, Poetry is great but locking/installation still takes way longer than Node because there are no declarative manifests.

Kwpolska 4y ago

There’s a place for small packages, but is-even/is-odd is a bit too small to be a reasonable package. It is far easier to just write `x % 2 === 0` inline, which is an obvious idiom, instead of installing and importing a separate package for this. The use of is-odd by is-even can be confusing for users. For example, you may call isEven(0.5) and get the following error: RangeError: is-odd expects an integer. at isOdd (/tmp/mynodeproject/node_modules/is-odd/index.js:17:11) at isEven (/tmp/mynodeproject/node_modules/is-even/index.js:13:11) at Object.<anonymous> (/tmp/mynodeproject/index.js:3:13) (But the main point of the demonstration was to showcase dependency resolution and where it looks for packages.)

rektide 4y ago
isEven is in thay stack trace - should not confuse anyone with even a basic introductory level fluency at coding. Is it too small? What if latter the language evolves BigInt? Donwe suffer a patchwork of libraries which have & havent upgraded, sussing around each time to find out? I think the key thing to recognize is that this is all opinion. Many people dont like the availability of many opions, the ease at which dependencies have grown. And that's fine, there's some real pain here to having ballooning package trees. There's a pevel of conceit though that I feel that often arises, where we mock & shiv packages like is-even . But to me, it's not absolute, it's a matter of taste & preference. It looks weird to outsiders, but it has been enormously powerful & helpful, has been such a key successful element of JS that npm arose & made package management easy & package publishing easy & that we begat a new behavior of capturing all the little helpful things we do & making them available. Maybe there are good reasons for inlining simple things, but it's not clear to me what the gains really are, or what's wrong with is-even.
- rektide 4y ago
  Doubling down, there's just huge conceit that small modules are bad. And no evidence. People just love to hate. Dark side is easy & convenient & in reach, and one gains social clout, feels elite, by shitting on others. Boo to you. It's not easy, it's not tame, but it's unclear what negativity beyond mild inconvenience has been generated. And much of the harm can be diffused with more sensible protection, not simply giving all modules access to everything. Systems like WASI are finally engineering inbuilt protection to sensibly de-risk imports; this is a fault of runtimes for not offering us protection, not our burgeoning package ecosystems for having value, growing. It's still unclear what the worthwhile protests are.