4 ms·

That's not how it works. Here's a scenario. You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders th

That's not how it works. Here's a scenario. You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB. Worse, you pull in different libraries and they all pull in different versions of their own dependencies, with lots of duplication of similar but slightly different code. Node_modules usually ends up like this. The point is not writing the resize code yourself. It's the cultural effect of friction. If pulling in the resize library means you need to chase down the dependencies yourself, first, you're more aware of the cost, and second, the library author will probably give you knobs to eliminate dependencies. Perhaps you only pull in a JPEG decoder because that's all you need, and you exclude the metadata functionality. It's an example, but can you see how adding friction to pulling in every extra transitive dependency would have the effect of librabry authors giving engineers options to prune the dependency tree? The easier a library is to use, the more popular it will be, and a library that has you chasing dependencies won't be easy to use.

lmm 1y ago
> You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB. This is more likely to happen in C++, where any library that isn't header-only is forced to be an all encompassing framework, precisely because of all that packaging friction. In an ecosystem with decent package management your image resizing library will have a core library and then extensions for each image format, and you can pull in only the ones you actually need, because it didn't cost them anything to split up their library into 30 tiny pieces.
- nolist_policy 1y ago
  Do you have an example?
- barrkel 1y ago
  Actually I think a big part of the problem in C++ is the low level of abstraction of the standard library. It isn't friction that might cause an image resizing library to be all-encompassing; it's the lack of an abstract Image class in the standard library which would enable a resizing library to live side by side with image encoders and decoders, instead of needing to bundle them together. The C++ standard library isn't rich enough. It doesn't have enough concepts for a good ecosystem of smaller components.
MonkeyClub 1y ago
> The easier a library is to use, the more popular it will be You're thinking correctly on principle, but I think this is also the cause of the issue: it's too easy to pull in a Node dependency even thoughtlessly, so it's become popular. It would require adding friction to move back from that and render it less easy, which would probably give rise to a new, easy and frictionless solution that ends up in the same place.

lmm 1y ago

> You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB. This is more likely to happen in C++, where any library that isn't header-only is forced to be an all encompassing framework, precisely because of all that packaging friction. In an ecosystem with decent package management your image resizing library will have a core library and then extensions for each image format, and you can pull in only the ones you actually need, because it didn't cost them anything to split up their library into 30 tiny pieces.

nolist_policy 1y ago
Do you have an example?
barrkel 1y ago
Actually I think a big part of the problem in C++ is the low level of abstraction of the standard library. It isn't friction that might cause an image resizing library to be all-encompassing; it's the lack of an abstract Image class in the standard library which would enable a resizing library to live side by side with image encoders and decoders, instead of needing to bundle them together. The C++ standard library isn't rich enough. It doesn't have enough concepts for a good ecosystem of smaller components.

MonkeyClub 1y ago

> The easier a library is to use, the more popular it will be You're thinking correctly on principle, but I think this is also the cause of the issue: it's too easy to pull in a Node dependency even thoughtlessly, so it's become popular. It would require adding friction to move back from that and render it less easy, which would probably give rise to a new, easy and frictionless solution that ends up in the same place.