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.
However, I also left the conference thinking about the landscaped displayed by the topics covered at the event. Even before the event I felt that the community is dying in a sea of solutions with no mental model on how all the parts fit together. The range of topics and solutions discussed at the conference solidified this notion in my head. And I fear for those who are trying to take it all in. Its extremely overwhelming. So what is about to occur here in my writings is my attempt to paint a picture of the JavaScript landscape.
Before I begin I think we should acknowledge that there is JavaScript. Yup, there it is. Now you have people like myself who love it and love it exactly how it is. I love it so much that I agree with Angus Croll and Dan Webb's notion of "be the water, my friend". Which is a quote from Bruce Lee that simply expresses the value of forming oneself to an environment not trying to change the environment to oneself. Which I agree with. Now, don't get me wrong. For those of you who want to make it look different than it is by nature (e.g Coffeescript, Dart, etc…), go for it, do what makes the most sense for your brain. Love JS and love whatever dialect fancies your thoughts. For my brain. I like the "be the water, my friend" approach. My main point here is that if you are coming to JavaScript realize that there are those who think in just plain JavaScript and there are those who think in a dialect of JavaScript first and then secondly in strait up JavaScript. (i.e. List of languages that compile to JS). Or, maybe a person does not even want to mask JavaScript they just write it, bend it, and force it to look like another language (i.e. Classical inheritance using classes). Again, my message here is for a person to just realize and acknowledge this divide by logging its reality in your brain. This divide between JavaScript developers, IMO comes from two groups of people. Those of us who have only ever known JavaScript as a first language in contrast to those who come to JavaScript from the trenches of another language. I'm totally ok with this divide as long as no one gets dogmatic about the topic. If anything I think this divide has been beneficial as we spec. out ES6. Which if you are not knowledgable about the evolution of the specification (i.e. version of JS) its goes a little something like this.
ES3 > ES5 > ES6 aka Harmony or ES.next
As of today, the reality is the majority of us write code based on the ES3 specification. However things are changing and polyfills rule the day. And for the most part ES5 has good support from modern JavaScript engines shipped within browsers. ES6, not so much!
Ok, so with the first great divide behind let us move on to the next divide. This divide is one that should not be too difficult to understand as its been historically a common division in our industry. Its most commonly spoken about as Client-side JavaScript v.s. Server-side JavaScript. Pragmatically this could be consider a divide between those who Node and those who don't. Node is changing the landscape on the server front as well as on the client. And you should be aware of it as the JS movement on the server-side is dramatically effecting those of us who historically have been client-side JavaScript developers. At the end of the day its just JavaScript. But the host environment (Standalone Implementation of JS Engine v.s. Browser JS Engine) is a pretty major division especially when it comes time to groking a host environment and all its gory intricacies be it the DOM or the server. The infusion of JS server-side solutions combined with client-side components (e.g tower.js, derby, wakanda, meteor, flatiron) into the community should be a clear indicator that JavaScript on the server is here to stay and worth taking serious. Additionally, realize that many of the JavaScript solutions transcend the client only or server only environment and are being used on both sides (e.g. underscore.js). As well, many are toying with code re-reuse (mostly relevant to applications architecture) between the front and back-end. This has been labeled by many JavaScript luminaries as a pipe-dream. I believe there is even a solution in this area being worked on called Pipedream.
Next, we have the part of the landscape that seems to be painted with the many libraries, frameworks, plugins, UI widgets, and third-party code that one uses for a desktop/laptop, tablet, or phone either with the intent on running in a browser or being ported from JS to native. Which, believe it or not, its possible to write native applications on all of the previously mentioned devices by starting with and porting a JavaScript code base to native code. Yes, JavaScript world domination is upon us. Anyhow, this part of the landscape is basically the content for most JavaScript Conferences.
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.
First off we have what I like to call "Complete JS solutions". These solutions try and do it all. If you have a JavaScript development problem they will try and provide a comprehensive & cohesive solution. Meaning they try and do it all so you don't have to glue anything together. And if they don't do it now, they are working on it. And when something new comes along they will likely be adding it. These solution providers have not gotten the hipster memo about micro solutions, that is "loosely coupled modules are the future and large, tightly-bound monolithic libraries are the past". I mostly poke fun with that last statement and quote but like most assertions it has a mix of objective truth and subjective flaws. To be clear, complete solutions have there place regardless of a developers leanings, myself included. So enough with my commentary, below I highlight the most complete JavaScript application solutions.
Complete JavaScript Application Solutions
(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.
Parts of a Complete JavaScript Application Solution
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
Templating Parts
Build Parts (Concatenating, Minifying, Linting, deploying and often more)
Server Parts
(This was a small preview of some of the most depended on node solutions/packages. Really a small tip of the iceberg)
Testing Parts
Documentation Parts
Wow. And, Wow! This is a sea of solutions to be navigated that should make even the most skilled JS developer weep as they journey its waters. Additionally consider that some of these parts run on the client. Some run on the server. And some run on both, by design, as well as by nature. After all its just JavaScript.
A sobering reality must now be mentioned. I've only expressed here in my breakdown the tip of the iceberg as it pertains to the solutions based on the JavaScript language. Realize as well, I didn't even dive that deep into the touch/moblie or sever-side space. And I pretty much ignored the gaming space. Each of these spaces really deserve there own picture. But since its not my attempt to be comprehensive here but instead just paint a picture I hope you will forgive me if I left out a particular part or a specific solution. Whats important here is the landscape, and well, taking it all in. Its a lot to take in. But hopefully I've given here a place to start. A place to build a mental model of the landscape.