You typical Node project
-
This post did not contain any content.
-
This post did not contain any content.
Very true.
Python feels like that sometimes too. Except much more standard library which is much better than node modules.
-
This post did not contain any content.
the one on the right is also packages in node_modules that you're actually using and specifically requested.
-
Very true.
Python feels like that sometimes too. Except much more standard library which is much better than node modules.
Rust as well. Seems to just be a modern language thing.
-
Very true.
Python feels like that sometimes too. Except much more standard library which is much better than node modules.
also applicable to "installing modern drupal via composer".
-
This post did not contain any content.
Feels like a lot of “not inventing the wheel” - which is good? There are plenty of good wheels out there.
-
This post did not contain any content.
Off topic but what's the point of a book that thick other than novelty? Would make much more sense to just separate into volumes
-
This post did not contain any content.
Be the change you want to see in the world, people. Don't use any Node (or Rust or Python or Java or whatever) modules that have more dependencies than they absolutely, positively, 100%, for real have to. It's really not that hard. It doesn't have to be this way.
-
Rust as well. Seems to just be a modern language thing.
wrote last edited by [email protected]I sort of have a suspicion that there is some mathematical proof that, as soon as it becomes quick and easy to import an arbitrary number of dependencies into your project along with their dependencies, the size of the average project's dependencies starts to follow an exponential growth curve increasing every year, without limit.
I notice that this stuff didn't happen with package managers + autoconf/automake. It was only once it became super-trivial to do from the programmer side, that the growth curve started. I've literally had trivial projects pull in thousands of dependencies recursively, because it's easier to do that than to take literally one hour implementing a little modified-file watcher function or something.
-
Be the change you want to see in the world, people. Don't use any Node (or Rust or Python or Java or whatever) modules that have more dependencies than they absolutely, positively, 100%, for real have to. It's really not that hard. It doesn't have to be this way.
Which sounds like great, practical advice in a theoretical perfect world!
But, the reality of the situation is that professionals are usually balancing a myriad of concerns and considerations using objective and subjective evaluations of what's required of us and quite often inefficiency, whether in the form of programmatic complexity or in the form of disk storage or otherwise, has a relatively low precedent compared to everything else we need to achieve if we want happy clients and a pay check.
-
Off topic but what's the point of a book that thick other than novelty? Would make much more sense to just separate into volumes
Seems like it would break quickly with use
-
I sort of have a suspicion that there is some mathematical proof that, as soon as it becomes quick and easy to import an arbitrary number of dependencies into your project along with their dependencies, the size of the average project's dependencies starts to follow an exponential growth curve increasing every year, without limit.
I notice that this stuff didn't happen with package managers + autoconf/automake. It was only once it became super-trivial to do from the programmer side, that the growth curve started. I've literally had trivial projects pull in thousands of dependencies recursively, because it's easier to do that than to take literally one hour implementing a little modified-file watcher function or something.
Its certainly more painful to collect dependencies with cmake, so its not worth doing if you can hand roll your own easily enough.
The flip side is that by using a library, it theoretically means it should be fairly battle-tested code, and should be using appropriate APIs. File watching has a bunch of different OS specific APIs that could be used, in addition to the naive "read everything periodically" approach, so while you could knock something together in an hour, the library should be the correct approach. Sadly, at least in rust land, there are a ton of badly written libraries to wade through...
-
This post did not contain any content.
And this is why tree shaking exists.
-
Which sounds like great, practical advice in a theoretical perfect world!
But, the reality of the situation is that professionals are usually balancing a myriad of concerns and considerations using objective and subjective evaluations of what's required of us and quite often inefficiency, whether in the form of programmatic complexity or in the form of disk storage or otherwise, has a relatively low precedent compared to everything else we need to achieve if we want happy clients and a pay check.
Saying "we can't in practice reduce the complexity of our dependency tree because we need happy clients and a pay check" is like saying "we can't in practice turn on the propeller because we need to get this airplane off the ground".
-
Be the change you want to see in the world, people. Don't use any Node (or Rust or Python or Java or whatever) modules that have more dependencies than they absolutely, positively, 100%, for real have to. It's really not that hard. It doesn't have to be this way.
This applies to developers, too.
External dependencies put end users at risk, so I avoid them as much as possible. If that means I have to rethink my design or write some boring modules myself, then so be it.
-
Feels like a lot of “not inventing the wheel” - which is good? There are plenty of good wheels out there.
But I don't NEED a wheel, I just need a tarp to put over this metal frame on my patio, and for some reason the tarp manufacturer attaches wheels and plane wings to it!?
-
Feels like a lot of “not inventing the wheel” - which is good? There are plenty of good wheels out there.
Until those wheels contain malware and spyware.
-
And this is why tree shaking exists.
What is that?
-
Its certainly more painful to collect dependencies with cmake, so its not worth doing if you can hand roll your own easily enough.
The flip side is that by using a library, it theoretically means it should be fairly battle-tested code, and should be using appropriate APIs. File watching has a bunch of different OS specific APIs that could be used, in addition to the naive "read everything periodically" approach, so while you could knock something together in an hour, the library should be the correct approach. Sadly, at least in rust land, there are a ton of badly written libraries to wade through...
Yeah. I have no idea what the answer is, just describing the nature of the issue. I come from the days when you would maybe import like one library to do something special like .png reading or something, and you basically did all the rest yourself. The way programming gets done today is wild to me.
-
This post did not contain any content.
I should check Go's pkg folder...
