Minimalism – An undervalued development skill

Perfection comes not when you have nothing more to add but when you have nothing left to take away.

I think you're right generally, but not universally. There are cases where it makes sense to use a one size fits all dependency and cases where it doesn't. I think the author is right that at least some of the time, it's better to DIY certain features at the risk of needing more work later than to pull bloat into a project. Responsiveness matters for how polished an application feels. Someone web browsing with an i9-9900k computer and gigabit fiber won't notice at all, others will to varying degrees. Some people rely on Hughsnet satellite because no one will run cable to them and cell service is crap. It's my experience that people like that with slow connections or slow hardware have to frequently endure garbage-tier UX because developers preferred overwrought 3rd party tools to rolling their own features, to no apparent benefit. (Dev time included in some cases) Even in the middle ground, 300ms vs 150ms matters. While "disadvantaged users" may not seem like a low hanging fruit to go after, If you impress someone like that in your audience, standing out as having more polish than usual on your product, they'll assume the best about your engineering ability and maybe even turn into a grassroots marketer for you.

This applies at all levels of the stack, even hardware. I realize the author is talking about javascript, but I can think of several hardware projects where minimalism is clearly superior.

At a previous employer (whom I cannot talk about), we were working on an ASIC. The ASIC team was new, brought in for the job, and was eager to include every possible feature that stakeholders wanted. The stakeholders seem to view this as a "its my birthday" kind of scenario, and so asked for lots of features (it wasn't going to cost them anything, after all). We had one senior hardware engineer, who was not on this ASIC team that was asked to sit in on meetings, and he was the "no" man. Somebody would request a feature, and he'd sketch out on the whiteboard what it would cost in chip area, power, and verification time. The ASIC was delivered more or less on time, and was wildly successful (I think, I'd left the company by this time). If it wasn't for this "no" man, I think they'd still be trying to verify all the features other teams had asked for.

I never worked at Intel, and I don't know the inside story, but I'm guessing the same thing happened with their server NICs. The original 10G and its respin (82598, 82599) were simply brilliant in their simplicity, and they were one of the first full speed 10G NICs in terms of packet rate. Flash forward to the 40g / 10g xl7xxx series, where you have a kitchen sink worth of features, and the host has to do crazy things to deal with limitations in a basic core feature of an ethernet NIC (no more than 8 DMA s/g segs per emitted TSO packet). Flash forward again to the 100g columbiaville, which seems to be more of the same -- with the same TSO bug!

Kinda anecdotal, but I've been working on OSS libraries for the last few years and what I've learned is very similar: 80% of the features aren't used by anyone, and if someone really wants something they just open an issue.

Without javascript this shows a blank page. And it's about minimalism?