| > But with that being said, in the JavaScript world, the tooling treat developers more like "users" rather than "engineers". For example: Tooling really is about becoming a user. It takes a dozen different file types and shoves them through at least a dozen different type-specific pieces of software. Understanding any one of those to any real degree would take weeks to months. Just JS itself would require understanding transpilers, minifiers (an optimizing compiler), how NPM works, how these work with all the other tools, various module bundling styles, map files, feature differences for literally 10 versions of JS, browser JS limitations (eg, Chrome and FF break the JS spec for tail calls), JS API differences and polyfills, hot reloading techniques, and wrapping an entire server instance into all of this. I'm sure there are other parts I'm not thinking of. I did the hand-rolling of all this stuff for several years before jumping on to create-react-app. I've spent many days reading the documentation only to have to read it all again when the next major version drops and everything changes in slightly incompatible ways. I love learning, but on the whole, this adds very little value to most of the projects I've worked on (though some really did need hand-rolling for very niche requirements). I rather like laving all the tooling to domain experts who know far more about it than I ever will. I'd rather be a "user" and leave all my engineering headspace for the problems at hand. |