> but it seems indisputable that the finished product will be higher quality than the one that defers as much functionality off to external dependencies as possible. Why? Because for an external dependency to be useful, it has to address many different use cases. To do that, it has to expose abstractions that only exist to allow reuse. The unused use cases cause memory bloat (that even tree shaking won't address all of) and the abstractions slow things down at runtime.
You seem to be treating "quality" as a synonym for performance. But it doesn't matter how high-performance your GUI is if someone can't use it because, for example, it doesn't support their language or their assistive technology (e.g. screen reader or alternative input). And supporting these things requires -- guess what? -- abstractions, that take lots of time to implement if you roll your own GUI from the ground up. That's why I stand by my view, which you nicely summarized in your opening paragraph.
Your last paragraph is a tired straw man. No one has the time to develop software that's perfect in every way. When we sacrifice absolute performance, it's not necessarily for the sake of slapping together crap software to make a quick buck. Suppose I set out to solve an urgent problem in my chosen field (accessibility). Shipping my solution faster doesn't just mean that I can quit work faster and start making money. It also means the solution can start making a positive difference in users' lives sooner. In light of that, it would be irresponsible for me to obsess over maximizing speed or minimizing RAM consumption, as much as some vocal nerds might insist that I have a responsibility to do so. My real responsibility is to the users who are waiting for the solution that I'm developing. Now, that doesn't mean that I should absolutely ignore performance or resource consumption, but I shouldn't obsess over them either, and I certainly shouldn't use them as reasons to waste time developing everything from the ground up when there are so many high-quality components I can use.
You seem to be treating "quality" as a synonym for performance. But it doesn't matter how high-performance your GUI is if someone can't use it because, for example, it doesn't support their language or their assistive technology (e.g. screen reader or alternative input). And supporting these things requires -- guess what? -- abstractions, that take lots of time to implement if you roll your own GUI from the ground up. That's why I stand by my view, which you nicely summarized in your opening paragraph.
Your last paragraph is a tired straw man. No one has the time to develop software that's perfect in every way. When we sacrifice absolute performance, it's not necessarily for the sake of slapping together crap software to make a quick buck. Suppose I set out to solve an urgent problem in my chosen field (accessibility). Shipping my solution faster doesn't just mean that I can quit work faster and start making money. It also means the solution can start making a positive difference in users' lives sooner. In light of that, it would be irresponsible for me to obsess over maximizing speed or minimizing RAM consumption, as much as some vocal nerds might insist that I have a responsibility to do so. My real responsibility is to the users who are waiting for the solution that I'm developing. Now, that doesn't mean that I should absolutely ignore performance or resource consumption, but I shouldn't obsess over them either, and I certainly shouldn't use them as reasons to waste time developing everything from the ground up when there are so many high-quality components I can use.