[Jach]

There are tradeoffs everywhere. The parent made it sound like libraries and frameworks are always going to make you go faster, of course that's not always the case and I don't think the parent believes that. It's very often worth it to descend a level or two to do your job, some things can be done faster, lower, though it's rarely worth it to descend all the way to the bare metal or deeper (but sometimes necessary). Another but echoes your conclusion, sometimes a bit of knowledge at those layers will indirectly help at the layers above.

When the subject of many layered JS frameworks and dependency graphs with hundreds of mini libraries comes up I'm always reminded of Rasmus's 30 second ajax tutorial: https://web.archive.org/web/20060507105529/http://news.php.n... (And the modern equivalent: http://youmightnotneedjquery.com/) Very often libraries and frameworks are brought in because they "help us go faster [because of x,y,z]" with some x,y,zs like "we don't have to think about that problem" or "the global architecture/structure is taken care of", but the cost of dependencies sometimes outweighs the cost of thinking about the problem and doing it yourself. Libraries and frameworks are tradeoffs, you'll likely use a lot of them if you look at every layer you can actually influence, but they're not necessarily net boons.

[greenshackle2]

Yeah, I can agree with that. You'll get the most value out of understanding the 1 or 2 layers below. Digging all the way to bare metal is usually not necessary or practical, though it may help once in a long while.

For example, ORMs. If you try to use an ORM without knowing SQL you will have a bad time as soon as you hit performance issues or you have to do something that doesn't fit quite nicely into the ORM model. I have yet to see a project that uses an ORM that doesn't use SQL in places.

ORMs are not necessarily net positive. They make some things simpler at the cost of an extra layer of indirection.

Going a level deeper, knowing how query planners work at a high level will help writing performant SQL queries.

Going as far as understanding how your RDMS is implemented should not typically be necessary. It would help for finding bugs in the RDMS, but that should be very rare.