4 ms·
I agree. Your points about size and speed are valid. I think what made me defensive was the implication that these CLI libraries can be easily replaced with so
by nick_ 6y ago
I agree. Your points about size and speed are valid.
I think what made me defensive was the implication that these CLI libraries can be easily replaced with some small hand-coded solution. This particular library adds color coding, a structured help message based on the configuration, and some building blocks for DI, etc. Getting that stuff right in a hand-coded solution that isn't thousands of lines would take most developers a lot more time and effort.
- erikbye 6y ago> these CLI libraries can be easily replaced with some small hand-coded solution. If that was your takeaway from what I wrote that was definitely not my intention. I do not think that. I am sure several of these libraries are well-crafted, the developer(s) behind them might be excellent and have cared a great deal about performance and did their best to optimize every function. My point was more: people tend to pull in a lot more functionality/features than they need, and the few things you do need, it is often better to write yourself (you may disagree again). This will often give you the most optimized solution, and the one with the smallest binary. In another HN thread, someone mentioned Unity and the size of the binary required just to display a pixel, a square, or whatever their example was--although their example was not an apple-for-apple comparison and not quite fair, the point still stands, that Unity is a general solution, and if your only requirement is drawing a pixel, of course Unity is not the correct solution.