I enjoyed the Fluent Conference! I enjoyed the quality and range of talks. I enjoyed the professionalism, especially Nicholas C. Zakas classy sports jacket. I thought the selection of speakers and topics were relevant and timely.
I only have one legitimate complaint (besides the box lunches), which is the fact that too many great talks were given at the same time. I suppose this might be a clever marketing ploy to get me to throw down the 400 dollars for the conference videos. Thing is, the talks and workshops might just be worth the cost.
At any rate. I left the conference intrigued, inspired, and replenished. And I guess for me, thats how I judge a conference.
ES3 > ES5 > ES6 aka Harmony or ES.next
A developers choice in these matters (i.e libs, frameworks, plugins, widgets etc…) creates a divide between how they do things and how they are seen by the community at large. Which is fine. Thats just the reality of any community. Its more important that we not point fingers here and become egotistical about our views but instead simply try to wrap our heads around the landscape. Its best to acknowledge that a solutions merit is tied directly to the skill/knowledge/career/biases of the person swinging the solutions. As a consultant I might advise a solution I would never use myself and in fact believe to be extremely flawed. However based on the intricacies of the team and the individuals the solution might fit like a glove. It might be a horrible solution and an even worse tool for the job but succeeding isn't dependent upon the tools alone. Its a person's desire to succeed that matters most.
So. What does this portion of the landscape look like? This is sort of the million dollar question at its finest. I'm going to attempt to break it down for you into some semantics I feel might add some clarification but also might add some confusion. But heck, I'm going to give it a shot anyhow as I don't see many people attempting to communicate a broad overview of this space.
(i.e. includes the follow: module loader, build tools, widgets, architecture/infrastructure, full-stack options, templates, documentation, testing, touch)
If you want a suite of tools from a single source these are the players trying to play that game each to a varying degree of completeness and success.
Now, as a subcategory to these complete solutions you have what I like to call the "parts" to a complete solution. I will break these down into logic chunks, but again, I'm not sure I will get the semantics perfect (Warning: this has a front-end slant to it as that is my innate work history bias). I'm simply going to break the parts down in to the categories that make sense to my brain. Keep in mind the above "Complete Solutions" typically contain each of the following parts. Or said another way the "Complete Solutions" typically attempt to offer a solution for each category I am about to mention.
Application Architecture/Infrastructure Parts
Full-stack Application Architecture/Infrastructure Parts
Touch Application Architecture & UI Parts
Touch Platform Parts (convert JS and friends to native, for touch devices)
(only mention here so that one can understand its part in the puzzle)
UI Widget Parts
(don't forget about the billion jQuery plugins too)
Core/Base (aka micro solutions) Utility Parts
(pretty much anything found on micro.js as well as a billion jQuery plugins)
Touch Core/Base Utility Parts
Packaging, Modules (AMD, commonJS, Harmony), and Dependency Management Parts
Build Parts (Concatenating, Minifying, Linting, deploying and often more)
(This was a small preview of some of the most depended on node solutions/packages. Really a small tip of the iceberg)