In other words, you're asking folks to not just learn something new, but also forget something they've perhaps invested a great deal of time and energy into already.
Sometimes, that tradeoff is worthwhile. But it's never free.
As an analogy, the difference between x and y is why, in decades past, so many inexperienced programmers started coding C without ever learning assembly - and then later, so many people started codig in a high-level interpreted language without ever learning C/C++. (Which may have been the language the interpreter was coded in, or even available directy if they needed it, such as in very performance-oriented code.)
* a general observation, more rigorously read: inexperienced.
I haven't written any assembly in many years now, but for a good while it was still pretty important to maintain that knowledge - you never knew when you'd need to use it for a routine here or there that was just too slow or cumbersome in C. And still, long, long after that, debugging C required at least some assembly knowledge if you wanted to get home in time for supper.
And this is where I see folks getting into the weeds with stuff like Angular: if you completely forget (or never learn) the underlying platform, it's entirely too easy to get stuck when it comes to debugging or even performance issues: you know it shouldn't take 3 seconds to render the page, but if you can't look under the abstraction then you're hosed.
So eventually, you're stuck learning the whole stack anyway. And now it's not a sunk cost: you have to forget what lies beneath every time you sit down...
But I don't think it's a good idea to lump disparate things together under the rubric "JS frameworks". Saying "things like Angular or React" is not really saying much except that they're both written in the same programming language, IMO.
You're right; my underlying point was out of all of the frameworks or libraries I've tried that are supposed to abstract away from many aspects (DOM manipulation, AJAX calls, etc) I've found them being overly complex. I'll be more specific next time and expound on my thoughts.
I do use a lot of libraries though. But libraries are different beasts, they solve your problems and not try to hide it from you.
The unix ideology of single purpose, easy to debug tools chained together is the only way to stay sane in the industry. But we have not got that memo yet.
If any framework has "magic happens" step, you are probably safer not using it.
If it were simply a view generation library you could use a dom-diffing library to diff it. But React does full lifecycle management in addition to "generation".
The fact that you can't use React along with other libraries in the same space means its a framework.
I purposefully didn't include a link to it in my comment, possibly to my own detriment, because I didn't want to come across as someone who was trying to hop on the topic of the article to simply promote my library.
After many years of dealing with various frontend frameworks I've essentially taken a curmudgeon attitude with many of them and find it far easier to simply write my applications using just JavaScript and maybe some messaging library to get the decoupling I want (I've posted on HN before about my little library called msngr.js that I use in many of my projects now because I am in love with messaging patterns). I find these far easier to understand than any of the frameworks that provide "magic" of sorts where automatic things happen for you.
The last time I used Angular was picking up a project other developers did. It had a good separation but felt very overly complex. But I feel that way with most frameworks (especially react).
I think the key takeaway here is that Angular, React, etc; these frameworks are not for everyone and are not for every project. If a framework forces a way of development that helps keep productivity higher then it's probably a good fit at least for that team. As a plus almost any of these frameworks can be used with great success for prototyping. So I think there is always value there.