| so maybe everyone should just wait 20 years before they understand any differences, and then they're ready to go? "one that can be "fixed" by a few lines of code in your build pipeline" Why do I even need a "build pipeline" for some projects? If you actually think much of this npm/gulp/sass/build stuff will age well, and you'll be able to go back to a "build pipeline" for a project 7 years from now.... it's very likely not going to work. "In the last 20 years of professional software development I've never ever encountered a situation where the time "downloading libraries" was worth more than a rounding error in a weekly budget." Hrm... just last week - "npm install" on a project took 45 minutes. Then... welp, gotta do it again on the server too. 345 meg of stuff, multiple dozens of which were complete duplicates of each other. That's 90 minutes waiting, 45 of which not even sure how much time is left (2 mins? 5 seconds? an hour?) while the machine slowed to a crawl. "I don't have to download the source libraries, then make changes, then recompile, and build and publish and push just to get a half-decent default when I can just reference these over here from a CDN" - that certainly is a valid technical choice. You can spend hours downloading, configuring, learning something that wasn't bootstrap and delivering less than "way better than bootstrap" UI/UX... that's a bad technical choice. You're right about aliasing commands, building stuff to save yourself time, but avoiding prebuilt stuff that is perfectly suitable for a project in pursuit of pixel-level control when it's not necessary (for most projects) is wasting time. |
I'd hope that people with misguided optimization agendas that effectively cost me as an employer money will be weeded out before 20 years pass.
The QED is the rest of your post; I don't care about your problem with NPM, I neither mentioned it nor do I used it beyond amusement purposes.