Reading the entire article he states to spend 20% of time on frameworks, libraries, and tools and 80% on "fundamentals". So he isn't against learning frameworks just don't make that the focus of your learning outside of your job because you'll learn the frameworks while trying to do your job.
I don't know about this author's day-to-day, but mine is not in the fundamentals of a language, it's in a framework.
Granted, a JS dev spends her day juggling libraries, but a Ruby dev (a Rails dev?), an iOS dev, an Android dev, etc, spends her entire day writing code for a framework, not a language.
I would even argue that software is 80% libs and frameworks and 20% fundamentals, but I digress.
I build some rather complicated things using Flask. Maybe 5% of total programming time in the last 6+ years has been spent writing code for a framework.
Now, Flask is a microframework, sure. But I see this in other work I do. Perhaps it’s the way I intentionally architect/design to have as little coupling of application with framework, but it’s an exceedingly rare event where I have to bother even thinking about the framework. At most, with a web project, it’s maybe when accessing a request or a session. Otherwise, I don’t write for a framework. I write applications that get a framework-powered web frontend, but all the work is in framework-agnostic code where it belongs.
I don't disagree that you might spend 5% in flask, but you also have auth, you have a data abstraction layer, you have session management, data persistence, tooling, and sec. All those libraries together is called a framework.
I know what a framework is, having been building with a handful of them for more than a decade. That a framework is used to deliver a web-based frontend has no bearing on intentionally designing and building a framework-agnostic backend.
For instance, auth happens via a library that is not Flask. Same for database models and persistence (that’s SQLAlchemy for the models, and a mix of ORM and straight SQL queries for db operations—again, not Flask/framework). This is starting to feel like splitting hairs, though. One of the great benefits of a microframework like Flask is that you get the freedom to design and write application code that ignores the fact that there’s a framework handling the request lifecycle. It makes for better code.
For an example of a non-microframework example, Phoenix takes this approach as well—that Phoenix isn’t your application, it’s just a web layer, and your application should be independent.
