Create React App launched this week, and it's the most significant React ecosystem development since Redux. Not because of what it does—setting up React projects—but how it does it: zero configuration, hidden complexity, sane defaults.
This is Facebook acknowledging JavaScript tooling is too complex and doing something about it.
TypeScript has been around since 2012, but 2016 feels like its inflection point. Angular 2's TypeScript requirement, VS Code's excellent TypeScript support, and large companies adopting it signal shifting momentum. But JavaScript developers remain divided on whether static types are improvement or burden.
TypeScript is winning—just not unanimously.
Vue.js 2.0 is in development and coming this year. What started as Evan You's personal project in 2014 has become a legitimate third option alongside React and Angular. Vue's growth, especially in Asia, proves a framework can succeed outside the Facebook/Google ecosystem.
The question is whether Vue's "progressive framework" philosophy is genuinely better or just different.
HTTP/2 is shipping in browsers and servers throughout 2016. The protocol brings multiplexing, server push, and binary framing—fundamental changes that supposedly invalidate HTTP/1.1 optimization practices like domain sharding and sprite sheets.
Reality is messier. Not all browsers support it. Not all servers either. And some HTTP/1.1 optimizations still help. The transition period is awkward.
async/await reached Stage 4 this month, meaning it's officially part of the next ECMAScript version (ES2017). After years of callbacks and promise chains, JavaScript finally gets syntax for asynchronous code that reads like synchronous code.
This isn't hyperbole—async/await is the most significant JavaScript language feature since Promises.
This week, the JavaScript ecosystem had a wake-up call. A developer unpublished a tiny npm package—11 lines of code—and broke thousands of projects including major ones like Babel and React. The incident exposed fundamental fragility in how npm dependencies work.
The technical fix was quick. The implications aren't.
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.
Facebook released GraphQL to open source this week. It's their internal data query language, used in production for years, now available for everyone. The pitch: instead of REST endpoints with fixed responses, clients query for exactly what they need.
This is radically different from REST, and if it catches on, it changes how we think about APIs entirely.
The React community is experimenting with writing CSS in JavaScript—inline styles defined as objects, styling colocated with components, no separate stylesheets. This violates web development orthodoxy so completely that the reaction ranges from "interesting" to "what heresy is this?"
After building with CSS-in-JS approaches, I think the heresy might be onto something. But the trade-offs are real.