Carpenters still use harvested, dried, milled lumber. Chefs still use harvested, dried, milled flour.
Frameworks are tools and building blocks like this, but for software. Not using them is not like an artisan carpenter using lumber from the store. Itβs like a carpenter making their own boards, or a chef making her own flour. It is not really relevant to efficient, performant software, it is more like an art for the sake of it.
Libraries are closer to raw (but still refined) materials than frameworks. Frameworks impose structure on users, libraries ask users to plug them in where appropriate.
> It is not really relevant to efficient, performant software, it is more like an art for the sake of it.
This statement sort of presumes frameworks are a necessary prerequisite to software, which isn't the case.
Tools, maybe, but I have yet to see anything that calls itself a "framework" (i.e. Spring, Angular, Django, Salesforce) that doesn't a) bloat the hell out of the binary, b) use more memory than it can possibly justify, c) create impossible-to-diagnose problems, d) not actually provide anything except overhead.
The best framework I've used is probably MonoGame. It abstracts away accelerated 2D graphics across multiple platforms, asset loading, and input handling, among a few other things. You write your game not against DirectX, but against the concepts it introduces. Unlike modern ideas of frameworks, it doesn't preach to you that you need to name things certain ways, or impose other slightly-pedantic notions on you.
Instead, it's focused on getting out of your way. Most other frameworks seem to love getting in your way, because they see themselves as so important.
Frameworks are tools and building blocks like this, but for software. Not using them is not like an artisan carpenter using lumber from the store. Itβs like a carpenter making their own boards, or a chef making her own flour. It is not really relevant to efficient, performant software, it is more like an art for the sake of it.