"What JS Framework?" is not the question

whud'up?

I'm hearing a lot of talk about JS framework lately and by "lately" I mean the past 4 years. I have to admit that I took a rather active part in this debate.
It will seem that once all aspects of live-streamer latest features have been covered, the modern JS developer dives into that old debate of "What JS framework should we use?", but nowadays you can count me out on this one for I think I've seen the light and have the answer which suites my questions.

To be clear, you're not going to leave this post with an answer to that question, since I believe the question has become irrelevant (at least for me). Hopefully I will be able to make you see where I'm coming from and perhaps change your perspective over this matter (or at least, get your opinions on it).

You see - I think we're asking the wrong question.
Lets start from a simpler question which is "What do we seek in frameworks?"
There are several requirements from a framework which you probably all aware of (simple impl., easy learning curve, functionality, etc...), but I've narrowed it down to this:

A safe path for solving complex application problems and provide an easy maintenance

Wait, let me get the stick out of my arse and explain what I mean in simple words.
You basically want some guidelines to take you from the requirements the product team has sent into a realization of what the code you need to write should look like. These guidelines will also ensure you that the end result will do what it should in the best way possible (considering performance among other) and also give us a clear path for modifying it easily and enhance it with little effort.
Are you sensing where I'm going with this? not yet? keep reading.

So say I found a JS Framework which does answer these requirements I've mentioned above for a specific feature I'm about to implement, and you know what, it seems that this framework can also fit other features that are on the pipe, but wait... it doesn't quite fit that last feature and not this one and oh man... not again.
This probably the reason new frameworks are released every second. It is because none of these frameworks solve ALL the complexities the rich web application presents. I never encountered one which does, but I will be happy to be proven wrong.

If we get back to the thing we seek in a framework the more experienced developers among you might smell something familiar. Isn't this what Design Patterns are all about?
Very early on the software development history some smart people (4 in particular) realized that there are many problems in software development, and that these problems may appear in many different forms and formats but most (dare I say all) fit into these patterns and can be solved by them. It is also important to notice that it was also realized back then that there are more then a single pattern for there are more then a single type of problem.
Now you are probably saying "well duh!", but hey - weren't we arguing about that single framework which answer all a minute ago... ?

So if I was to use Vanilla JS, I would probably go and use the design pattern which fits the problem I have at hand. Maybe a "Singleton" fits here, but there the "Command" design pattern fits better, every feature, or sub-feature, demands it's most suitable solution.
This is great, but I don't want to re-invent the wheel for each of these patterns and re-implement it, so I will look under the frameworks at hand. Sadly these frameworks have their own way of solving problem which sometimes, due to their overall inner implementation and agenda, sail far-far away from the design pattern which is the most suitable, for instance some frameworks strongly believe in Singletons but neglecting the Command design pattern altogether.

ok, ok hold on.
I'm not saying that there isn't any room for JS Frameworks and I'm definitely not saying that you shouldn't use libraries. All I'm saying is that you can't argue that the tool you've happened to choose, say a hammer, is also a great screwdriver. It's just not, and if you'll try to force it into becoming a screwdriver you either break the screw or your hand.
Even a Letherman multi-tool has it's limitation. There isn't a framework which answer all software problems, so for the love of god, stopping arguing over it.

but wait there for a sec, what about these Design Patterns? can we take advantage of them?
sure! why the hell not?
They are out there and do not enforce any language or syntax for they are mere concepts. So if you still want to pick a JS framework, pick the one which allows you to incorporate your chosen design pattern without risking the entire structure of the application.

I think that in today's world we are starting to realize that frameworks not only masks us from understanding the JS under-the-hood but they mask us from the design patterns we need to learn and understand. The same as I want modularity when coding, I also want it in my tools, libraries, and frameworks. This is, BTW, the reason I believe ReactJS caught up with the developers community for it offered a solution for the "V" in MVC. Forget the whole "Flux", "Redux" and other shit that is popping out now, I'm talking about ReactJS alone - it doesn't tie your hands in any way to use whatever design pattern you want (and even then some might argue that it does).

So what's the bottom line?
Learn about Design Patterns. See which one fit your problem and seek to implement the best solution. If your JS Framework holds you from doing that, you have the wrong framework. The more skinny the framework you use, the better. If you can reduce into a library, like say Backbone, that will even give you more freedom.

("Backbone is a library, not a framework, and plays well with others."  Backbone docs)

And... for the love of god, stop asking which JS Framework to use :)

Take care