As someone who mostly codes in Python, I don't understand, why JS gets new framework so often. What is the reason behind? Is Javascript makes thing easy to develop a new framework? Why doesn't Python get new framework so often?
BTW, If you want to see what that combination looks like in a more suited language then look towards ClojureScript or Elm.
* JS is possibly the largest programming language community in the world
* There are a lot of shortcomings in "the web platform" for app-style development
* Most JS developers are primarily developers in another language with a stronger culture and set of ideas/idioms
It's basically the cambrian explosion.
Do a search of https://npmjs.com/ for a framework you want a synonym to, and you will probably find it.
For me, some tools simple ring better in the JS way than others... if it's too cobbled, and relies on strange markup behaviors I like it less. If it's really class centric I tend to like it less, though ES7 classes and React isn't too bad. It just depends on your likes.
I really don't like seeing certain patterns in JS (factories and di/ioc) as they simply aren't needed and only add complexity.
So package adoption is hard because of this. If you make it a pain for implementing developers to use your code, they're more likely to just write their own code.
That's why I think the old style ala jQuery or Google Maps API of packaging everything manually as just namespacing-objects still makes the most sense, with the fewest tradeoffs. You give the user a single, minified JS file to either copy or reference on your CDN. It's a least-common-denominator solution and it lets the implementing developer figure out how to fit it into their workflow.
Seriously though, it's a non-problem now. There is no way I'd go back to anything else. Webpack and browserify are the only way to go. </religion>
Yes, there is a certain purism to doing your own modules and IIFEs and JS, but it's like claiming that code is only fast when it's asm. </realcoders>
Besides it can all be optimised out if you add the closure compiler plus relevant comments </nobodyactuallydoesthat>
A base set of packages, for your external functionality, your core (shared functionality) and the rest makes a lot of sense, and isn't that hard to do. In the end it's pretty easy to reason about, and with sourcemaps and better build tools it's easy to use. Though having to have a watcher or build process when JS changes takes some getting used to... if you're used to compiling server code, it really isn't bad...
I consider them somewhat fluffy and learn just to say nice job and move on.
It definitely did with django, pylons, flask, turbogears, web2py, . . . I didn't know which way to turn.
PHP had the same thing with cakePHP, symphony, drupal, and so forth. I remember rolling my own using smarty long ago, because I couldn't decide.
It's easy to get into making/sharing something, but has no (strict) guidelines on how things are structured or work. So you have countless ways to do one thing.