There's a chapter about mental models: https://github.com/zakirullin/cognitive-load?tab=readme-ov-f...

Yes, and I hope I made a point that it's not the right approach always.

> If you've internalized the mental models of the project into your long-term memory, you won't experience a high cognitive load ... If you keep the cognitive load low, people can contribute to your codebase within the first few hours of joining your company.

Yes, if you really are having new joiners often, and you expect them to be onboarded quickly. That happens for a specific segment of the software industry, not generally.

If you're working with the same people all the time, and it's the nth time someone made a mistake in a huge frontend JS codebase (pre-Angular/React) trying to wrangle with plain events and DOM state, a new framework (like React and co) that abstracts away events and DOM state management was perhaps the right choice.

This way of thinking and abstraction is so popular now that it's taken almost for granted by people who started learning programming for the web recently. For these people, using plain JS might be higher cognitive load, so

> Lots of cool architectures, fancy libraries and trendy technologies were used. In other words, the author had created a high cognitive load for us.

that's not a universal statement.

Do I personally believe there are better levels of abstraction, and simpler frameworks than React, Express, Django, Spring, Laravel, etc.? Yes, but if the developers you are hiring/teaching/working with are familiar with those, and it's working for them, then maybe that is the right choice to use.

The main statement I agree with in the article (apart from the goal of reducing cognitive load) comes much later, in

> So, why pay the price of high cognitive load for such a layered architecture, if it doesn't pay off in the future? Plus, in most cases, that future of replacing some core component never happens.

where the main problem is having the wrong reasons or wrong choice of architecture. It's not necessarily that abstraction/architecture is bad. I feel like the message of "you should keep it simple" is overemphasized in the rest of the article. Maybe that's in response to overengineering in the industry or the author's experience.