Angular 2 has been in development for over a year, and beta just landed. The reaction is mixed: excitement about modern architecture, frustration about breaking compatibility with Angular 1. Google chose to rebuild rather than evolve, and that decision will define Angular's future.
The question is whether the improvements justify abandoning millions of lines of Angular 1 code.
Google introduced the term "Progressive Web Apps" recently, describing web applications that progressively enhance to feel native. With service workers enabling offline functionality and app-like experiences, this could fundamentally change mobile web development.
Or it could be mobile web's latest disappointment. We've been here before.
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.
A year ago, browserify was the dominant module bundler and webpack was the confusing alternative. Today, webpack is becoming the default choice. This shift happened quickly and reveals what developers actually value versus what they claim to value.
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 JavaScript ecosystem has a problem: fatigue. Not the concept—the actual exhaustion developers feel trying to keep up. A new build tool every few months. Frameworks rise and fall in a year. Best practices change before you finish reading the blog post explaining them.
This isn't healthy. It's not sustainable. And it's actively harmful to teams trying to build production applications.
Microservices are the hot backend architecture: small, independent services instead of monolithic applications. The benefits—independent deployment, technology diversity, team autonomy—are compelling. But most SPAs remain monolithic. We're distributing the backend while keeping the frontend as one large application. Should frontend be microservices too?
"Isomorphic JavaScript" is gaining traction—write code that runs on both server and client. Render on the server for fast initial load, hydrate on the client for interactivity. The promise is having your cake and eating it too: server-side performance with client-side dynamism.
After building a few isomorphic applications, my take: it's powerful but not simple. You're not writing code once, you're writing code that accommodates two environments.
A pattern is emerging across frameworks: organize UIs as trees of self-contained components. React does it with JSX. Web Components do it with custom elements. Angular 2 (being developed now) is redesigning around components. This convergence is interesting—but the implementations are incompatible.