Two years ago, choosing a JavaScript framework felt like Russian roulette. Would it survive? Would it change completely? Would something better emerge next month? Starting 2016, those questions feel answerable. The landscape has stabilized enough to make informed choices.
This isn't declaring winners—it's acknowledging that viable options exist and the churn has slowed.
Last year's post was titled "JavaScript in 2014: The Year Everything Changed (Again)." This year feels different. Not "everything changed again"—more "things settled into place." ES2015 shipped, React matured, patterns emerged. This was JavaScript growing up.
ES2015 (ES6) finalized in June. But unlike most standards, developers had been using it for months via Babel. The finalization formalized what was already practice.
The shift from "experimental features" to "standard language" matters psychologically. Teams that resisted transpiling because ES6 felt unstable are now adopting it. Babel moved from optional to essential infrastructure.
Node.js 4.0 releases this month, and it's not just a version bump—it's the reunification of Node.js and io.js. After a year of fork drama, the community is back together under a foundation governance model. This is as much about politics as technology.
Understanding what happened and why it matters reveals tensions in open source governance.
ECMAScript 2015 (ES6) was officially finalized this week. After six years since ES5, JavaScript has classes, modules, arrow functions, promises, and dozens of other features. This should feel momentous, but the reality is most developers have been using these features for months via Babel.
The standard finalizing doesn't change what we write—it changes the legitimacy of writing it.
Facebook open-sourced React Native this week, and the pitch is bold: write native mobile apps using JavaScript and React. Not hybrid apps like PhoneGap—actual native apps with native performance and native UI components.
This is ambitious. The question is whether JavaScript's "write once, run anywhere" promise finally delivers or disappoints again.
The ES6 transpiler landscape has a clear leader: Babel. Renamed from 6to5 just last month, Babel is rapidly becoming the standard way to write modern JavaScript today. After a year of Traceur vs 6to5 debates, the community is consolidating.
Twelve months ago, the JavaScript landscape looked different. Angular dominated frontend. Grunt was the build tool. ES5 was the language. Bower handled frontend packages. Node was interesting but niche.
Today, everything's in flux. React is challenging Angular. Gulp is challenging Grunt. ES6 is being used via transpilers. npm is taking over from Bower. Node powers build tools everywhere.
Let's look at what changed and what it means.
The next version of JavaScript—ES6, or ECMAScript 2015 as it'll officially be called—is taking shape. Finalization is expected next year, but transpilers like Traceur let us use features today. The question is: which features are stable enough to bet on, and which might change?
React showed up last May at JSConf, and the initial reaction was skepticism. Facebook's pitch—"we're putting HTML in JavaScript"—sounded like a regression to the bad old days of mixing presentation and logic. But after spending time with it, I think React is asking the right questions, even if the answers feel uncomfortable.
After building several single-page applications with Backbone over the past year, I'm struck by a pattern: we're rediscovering problems server-side frameworks solved a decade ago. Memory leaks, state management, routing—these aren't new challenges. But solving them in JavaScript, in the browser, with no page refreshes, creates constraints that make old solutions inadequate.