3 ms·
I don't see how that is worse than the alternative where every library rewrites its own version of the micromodules. With N libraries with their own version of
by epmatsw 11y ago
I don't see how that is worse than the alternative where every library rewrites its own version of the micromodules. With N libraries with their own version of leftpad, you get N copies of leftpad. With N libraries sharing versions of leftpad, you get <= N versions. Seems like a win to me...
- cuu508 11y agoIdeally you would cut down on dependencies on every level, and end up with significantly less than N dependencies. If you have 5 similar string formatting libraries that depend on leftpad, you could collapse them into one, and have a single instance of leftpad inside the combined library. Less licenses, less READMEs, less time downloading, and with tree shaking you still get similar end result.
- chris_wot 11y agoIt would nice for packages to include other packages in it...
- smacktoward 11y agoIt seems like the thing to do would be for the community to build up a single set of commonly used functions. Having one authoritative package would make that package CDN-friendly, which should cut down on the bytes-downloaded problem; and if it becomes popular enough, it could eventually be bundled with browsers or rolled into the standard for the language itself. You could call it a "standard library."
- mbreese 11y agoTheory != practice. In practice, you need to balance the overhead of an extra dependency with the benefits from sharing versions with others. When you add a dependency, you also now have a larger attack surface. Any extra dependency adds some amount of friction. Sometimes it is negligible. But, if you look at the overhead across all of your modules, it can add up quickly. In some cases, the benefits from a dependency outweigh the overhead costs. In other cases, you just write your own leftpad function and move on.