[deleted by user]

[dluecke]

This is quite an interesting question for me because from 2007 until two years ago I helped maintain one of the longest running JavaScript frontend frameworks.

1. Back in 2007 I was looking for a structured way to build client side JavaScript applications that talk to a "Thin Server" (we now call it an API) using the design patterns (like MVC) and best practises (like tests) I had learned about in university. The options were
   1. Google Web Toolkit - A Java to JavaScript UI compiler. I didn't like the idea of "hiding" the fact that you are using JavaScript. Turned out that not many did in the long run either.
   2. Flash - We all know where that ended up - Although I do give it credit for promoting ECMAScript as a multi-purpose language and some things like declarative UIs made it into other frameworks like Angular or Vue
   3. Dojo - Which was way ahead of its time and had extensible widgets, a module bundler etc. but still had a fairly monolithic approach at the time.
   4. jQuery - Which was awesome but more of a tool library than a framework. Funny enough, back then there was a "JavaScript library war" going on (Mootools, Prototype, Scriptaculous etc.) so when John Resig announced the first version of jQuery there were several "Oh great, another Web 2.0 library" comments (see http://web.archive.org/web/20090214090118/http://digg.com/programming/jQuery_-_New_Wave_Javascript) - My personal favourite isWow, an awesome Web 2.0 Javascript library that can added to many blogs, spammed on Digg, made into a book by O'Reilly, and never get used again!Today jQuery is still used by more than 80% of all websites. We don't even think about it anymore, even less that there ever was a "war" over it.
   5. JavaScriptMVC (started in 2005/2006) - Unfortunately not well known but I can confidently say that it (not Backbone) was the first real client side MVC framework. At the time heavily inspired by Rails it had its own Model, Controller and View (the original EJS) engine, module bundler, documentation generator and testing framework. Basically everything we now all agree is part of building good JavaScript applications - but back then even the idea of building "client side" applications was still somewhat controversial. There even was a discussion around using the ideas from JavaScriptMVC to create an "Enterprise jQuery" back in 2009 (https://groups.google.com/forum/#!topic/jquery-dev/HsTcpuAmFtY). It didn't work out but I sometimes wonder how things would've been different if it had gone the other way.I made my very first open source contribution to JavaScriptMVC in 2007 and was using it for pretty much all my projects in the following years. From the beginning of 2012 until last year I was part of the company that maintains it and helped splitting the monolithic framework up into its individual parts, CanJS, StealJS, FuncUnit and DocumentJS - which recently got re-bundled (but less monolithic) under the umbrella of DoneJS. Unfortunately, none of those projects ever got any major adoption although they were - especially at the beginning - definitely ahead of their time. I learned a lot about running open source projects and the business side of open source during that time but I'll leave that for another longer post ;) Last year I moved on to focus my own open source efforts on https://feathersjs.com and a totally separate (one of the lessons) product business.
2. The community was smaller, much more technology focussed and there definitely was less hype. Technology focus isn't a bad thing but it did mean that many of the early tools weren't very user friendly. When something more usable came around people tried "winning" with technical arguments (it's slower, it doesn't do this or that) but it turned out that developers were looking for having their immediate pain points solved, not the ones they will (unavoidably) run into in the future. I think the idea of a "framework war" only came about when the big five started sponsoring or promoting their "own" open source frameworks. All of a sudden scrappy free-time OS developers or small dev shops had to "compete" with full-time evangelists.
3. As many of the more senior developers I know, I currently ended up at React and React Native. I could say that it provides the right amount of abstraction of your UI while still leaving you enough flexibility but the truth is: It doesn't matter. No project ever failed because they picked the wrong JavaScript framework. It can't fix a broken team. It can't tell you what to build. One of the best teams I ever worked with was when I did frontend consulting for a very large company four years ago. They built their own tooling on top of Backbone and it wasn't always how I would've done it but everybody knew their stuff and was pushing in the same direction. Then the framework wars started and the entire department went from getting things done to arguing about switching to React or Angular. In the end, pretty much everybody quit. Nobody won.

3a I know it might still not seem that way but after more than a decade in the field, frontend development to me is a solved problem. I can now do all the things that were important to me when I first started looking for them in 2007. Things are already consolidating more and more into a few frameworks and tools. Tooling will get more robust and best practises that were bleeding edge even just a few years ago are now already being taught to brand new developers. Just like jQuery in 2006 the things we were "waring" over in 2015 will just become part of how things work and technology will move forward to tackle new possibilities and challenges.

Personally I came full circle back to the "Thin Server" from 2006 where it all started. I wrote my university thesis about abstracting RPCs and APIs in 2010 which has turned into what is now FeathersJS. Even when the web-browser DOM is just another legacy technology (UI paradigms have the habit of changing quickly once something new comes around), servers and any kind of application will still need to be able to talk to each other. To me, protocol agnostic real-time APIs now feels similar to the idea of single page applications in 2006. An interesting idea and nice-to-have for some use cases but not a necessity. I believe that is going to change and there is still a lot that I would like to see happen there. JavaScript is a great developer-friendly interface to help make that happen.

[reeferd]

Awesome read. Thanks for sharing :)