<story><title>Micro-libraries should never be used</title><url>https://bvisness.me/microlibraries/</url></story><parent_chain><item><author>ristos</author><text>Micro-libraries are really good actually, they&amp;#x27;re highly modular, self-contained code, often making it really easy to understand what&amp;#x27;s going on.&lt;p&gt;Another advantage is that because they&amp;#x27;re so minimal and self-contained, they&amp;#x27;re often &amp;quot;completed&amp;quot;, because they achieved what they set out to do. So there&amp;#x27;s no need to continually patch it for security updates, or at least you need to do it less often, and it&amp;#x27;s less likely that you&amp;#x27;ll be dealing with breaking changes.&lt;p&gt;The UNIX philosophy is also build on the idea of small programs, just like micro-libraries, of doing one thing and one thing well, and composing those things to make larger things.&lt;p&gt;I would argue the problem is how dependencies in general are added to projects, which the blog author pointed out with left-pad. Copy-paste works, but I would argue the best way is to fork the libraries and add submodules to your project. Then if you want to pull a new version of the library, you can update the fork and review the changes. It&amp;#x27;s an explicit approach to managing it that can prevent a lot of pitfalls like malicious actors, breaking changes leading to bugs, etc.</text></item></parent_chain><comment><author>foul</author><text>Micro-libraries anywhere else are everything you said: building blocks that come after a little study of the language and its stdlib and will speed up development of non-trivial programs.&lt;p&gt;In JS and NPM they are a plague, because they promise to be a substitute for competence in basic programming theory, competence in JS, gaps and bad APIs inside JS, and &lt;i&gt;de-facto&lt;/i&gt; standards in the programming community like the oldest operating functions in libc.&lt;p&gt;There are a lot of ways for padding a number in JS and a decent dev would keep an own utility library or hell a function to copy-paste for that. But no. npm users are taught to fire and forget, and update everything, no concept of vendoring (that would have made incidents like left-pad, faker and colors less maddening, while vendoring is even bolt in npm and it&amp;#x27;s very good!). They for years copy-pasted in the wrong window, really, they should copypaste blocks of code and not npm commands. And God helps you if you type out your npm commands because bad actors have bought the trend and made millions of libraries with a hundred different scams waiting for fat fingers.&lt;p&gt;By understanding that JS in the backend is optimizing for reducing cost whatever the price, becoming Smalltalk for the browser and for PHP devs, you would expect some kind of standard to emerge for having a single way to do routine stuff. Instead in JS-world you get TypeScript, and in a future maybe WASM. JS is just doomed. Like, we are doomed if JS isn&amp;#x27;t, to be honest.</text></comment>
<story><title>Micro-libraries should never be used</title><url>https://bvisness.me/microlibraries/</url></story><parent_chain><item><author>ristos</author><text>Micro-libraries are really good actually, they&amp;#x27;re highly modular, self-contained code, often making it really easy to understand what&amp;#x27;s going on.&lt;p&gt;Another advantage is that because they&amp;#x27;re so minimal and self-contained, they&amp;#x27;re often &amp;quot;completed&amp;quot;, because they achieved what they set out to do. So there&amp;#x27;s no need to continually patch it for security updates, or at least you need to do it less often, and it&amp;#x27;s less likely that you&amp;#x27;ll be dealing with breaking changes.&lt;p&gt;The UNIX philosophy is also build on the idea of small programs, just like micro-libraries, of doing one thing and one thing well, and composing those things to make larger things.&lt;p&gt;I would argue the problem is how dependencies in general are added to projects, which the blog author pointed out with left-pad. Copy-paste works, but I would argue the best way is to fork the libraries and add submodules to your project. Then if you want to pull a new version of the library, you can update the fork and review the changes. It&amp;#x27;s an explicit approach to managing it that can prevent a lot of pitfalls like malicious actors, breaking changes leading to bugs, etc.</text></item></parent_chain><comment><author>ivan_gammel</author><text>&amp;gt; So there&amp;#x27;s no need to continually patch it for security updates, or at least you need to do it less often, and it&amp;#x27;s less likely that you&amp;#x27;ll be dealing with breaking changes.&lt;p&gt;Regardless of how supposedly good or small is the library, the frequency at which you need to &lt;i&gt;check&lt;/i&gt; for updates is the same. It doesn’t have anything to do with the perceived or original quality of the code. Every 3rd party library has at least the dependency on platform and platforms are big, they have vulnerabilities and introduce breaking changes. Then there’s a question of trust and consistency of your delivery process. You won’t adapt your routines based on specifics of every tiny piece of 3rd party code, so you probably check for updates regularly and for everything at once. Then their size is no longer an advantage.&lt;p&gt;&amp;gt; Copy-paste works, but I would argue the best way is to fork the libraries and add submodules to your project. Then if you want to pull a new version of the library, you can update the fork and review the changes.&lt;p&gt;This sounds “theoretical” and is not going to work at scale. You cannot seriously expect application level developers to understand low level details of every dependency they want to use. For a meaningful code review of merges they must be domain experts, otherwise effectiveness of such approach will be very low - they will inevitably have to trust the authors and just merge without going into details.</text></comment>