IME, this tends to be a problem with frameworks in general: the goal, after all, is essentially to create a new platform on which to build, but that implicitly invalidates a whole lot of knowledge your potential users have of the underlying platform.

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.

good point, but a sunk cost. New programmers, such as young* developers learning front-end architectures for the first time, never learned all of the underlying platform. So they can spend the next ten hours achieving x amount of progress in pure javascript, or y amount of progress coding atop a framework.

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.

That only works if the framework actually does work as a complete platform, though - that is, if you can get away with forgetting (or never learning) the underlying platform once. To go back to Angular, it would mean forgetting all about the non-Angular-friendly parts of the DOM, events, etc. and never needing to use them again.

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...

Totally agree. Honestly I find the level of noise around JS frameworks to be insane. It's really not that hard to roll your own framework out of a couple simple libraries, which lets you write something perfectly tailored to your own requirements, that doesn't do a bunch of extra junk under the hood that you don't need. Unfortunately this approach doesn't have its own corporate hype machine (and why would it?) so it's usually completely missing from the conversation.

I agree that the best way is to use "just JavaScript" - crazy idea, right?! :)

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.

> 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.

That is why the only framework I use is Backbone - and only as a router. It says here are your event, njoy.

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.

React is not a framework though.

Explain to me how to do diff/patch then.

It's a view generation library, not a DOM-diffing library. That's like asking how to rotate a subtree in an RB tree library.

> view generation library

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.

your screenname is exceptionally prescient

You should include a link your project, or at least link to your GitHub profile in your profile.

I hadn't thought about including it in my profile so I went ahead and updated it. Thanks!

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.

I think its fine. From time to time a question or comment will come up related to something I've done. I've never had anyone complain about it. Usually people are happy to hear about possible solutions to a problem they're having.

There seems to be an approaching "framework overload" point where javascript (at least frameworks) will suffer some backlash and begin to push people away from them. It happened before with java and ruby for a time.