“JavaScript developer” is a description that hides tremendous diversity. While every language has a range of user skill levels, JavaScript has a remarkably fragmented community. People come to JavaScript for different reasons from different places, and this can make communication difficult. Sometimes it’s worse than that—not everyone likes everyone else.
“JavaScript developer” used to mean “web developer,” specifically a developer who spends a lot of time working in the browser. Even as JavaScript became a specialty of its own, most JavaScript developers came through a broader web practice first, learning HTML and CSS before tackling the DOM. This was my path, and is still a common one. It was reasonably easy to absorb JavaScript by example, using it as an object manipulation language before pushing into the harder corners.
Many programmers, however, started on the server-side, building code that filled templates. Server-side JavaScript existed, in the Netscape Enterprise Server, for example, but was a tiny fraction in a world dominated by Perl, Java, Python, Ruby, and ASP’s languages. Developers who spent most of their time writing code that ran on the server worked with a different set of tools and expectations, and had to shift gears as JavaScript became a more critical part of web applications. (Some of these developers generate a lot of JavaScript—JSON is, after all, JavaScript—but would prefer to think of JavaScript’s role in that as an accident.)
Another group of developers came from desktop applications, and expected more direct control over the interface. Many of these developers now understand JavaScript because the browser forces them, not because they want to.
Involuntary JavaScript creates a tremendous amount of tension around the language. Normally, the people who dislike a programming language can just work with something else. JavaScript’s browser dominance makes that hard.
Other developers, though, are much much happier and much deeper into JavaScript. The JavaScript revival that became visible with the rise of Ajax in 2005 gave the language greater credibility. Douglas Crockford’s work “Unearthing the Excellence in JavaScript,” JavaScript: The Good Parts demonstrated a powerful language lurking in a toolset many had considered trivial.
Over the past decade, JavaScript’s power and reach have grown thanks largely to a core group of developers whose focus on the language has created best practices and frameworks, while driving browser vendors to improve their implementations. Node.js emerged from this work, giving JavaScript a unique server-side framework that deeply reflects the language.
More recently, the rise of DevOps has created a distinct group of deep JavaScript developers and members, combining relentless efforts to create fast but resilient systems that can change in response to business needs. JavaScript is one component in that broader conversation, but those conversations tend to have a very different tone from other kinds of “involuntary JavaScript.”
At the same time, “compile to JavaScript” has offered an ever-larger buffer for developers who want to take advantage of JavaScript’s ubiquity, but would prefer not to work in it directly. GWT drove much of this for Java developers, but CoffeeScript, Dart, asm.js and even transpilers from newer versions of JavaScript to older versions give developers a buffer from JavaScript. New “JavaScriptish” communities are emerging.
All of these groups intersect, often within a single team and sometimes within a single person. I’ve had many conversations with people about love-hate relationships with JavaScript, often depending on the context, not just of the code, but of the project. The social interactions of these varied backgrounds can complicate conversation and make it hard to set priorities.
As an editor, I’ve learned the hard way that what looks from a distance to be a single audience is deeply fragmented. Books written for one JavaScript audience go over terribly with other audiences. It’s more than the usual beginners and more advanced readers lacking patience for books at the wrong level.
The diversity of a conference, though, makes it much easier to craft a conversation with something for almost everyone. Fluent can’t cover every corner, but I think we have enough in the program to reach all of these groups with the possible exception of developers who’d really prefer not to think about JavaScript unless they absolutely positively have to.
The community fragmentation, though, creates some challenges that aren’t entirely solvable with a broad program. The ECMAScript standards process continually strives to create a single specification that all of these groups can share. The tensions in that process over which features to add and how many often parallel the fault lines in the community. How far should the language go to accomodate programmers who expect object hierarchies to be defined with classes, for example?
I expect that JavaScript will have a bright future, but I’m not convinced that these communities will ever fit neatly together.