webpack has been around for two years, but it's starting to get attention as an alternative to browserify and RequireJS. After spending time configuring it, my reaction is: this is simultaneously brilliant and needlessly complex. The concepts are right, but the API fights you.
Category: Web Development
Google I/O happened this week, and the most interesting announcement wasn't a product—it was Material Design, Google's new design language. After years of being the engineering company that can't design, Google is making a comprehensive bet on unified, opinionated aesthetics. Whether this works depends on execution and adoption.
What Material Design Claims To Be
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?
The Transpiler Bet
Something interesting is happening: developers are abandoning Bower and installing frontend dependencies with npm. This seems wrong—npm was designed for Node.js, and browser code has different constraints. But the trend is real, and understanding why reveals tensions in how we think about frontend packaging.
The Two Package Managers Problem
Gulp launched last July as an alternative to Grunt, and the pitch is compelling: write code instead of configuration, use streams for efficiency, make builds faster. After migrating several Grunt projects to Gulp, I have thoughts about what's actually different and what's just rebranded complexity.
The Configuration vs Code Argument
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.
The Separation of Concerns Debate
Bootstrap 3 shipped in August with a complete rewrite, and the most significant change wasn't technical—it was philosophical. Bootstrap finally embraced mobile-first design, which Foundation has championed from the start. Now that both frameworks share this foundation (pun intended), the differences are more interesting.
The Mobile-First Shift
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.
The SPA Promise and Reality
Yeoman hit 1.0 last month, and I've been watching its evolution with interest. It's not just a scaffolding tool—it's Google's Chrome team making a bet about how frontend development should work. That bet is basically: conventions over configuration, and automation over manual setup.
The Setup Tax
Twitter released Bower six months ago, and it's gaining traction for managing frontend dependencies. But using it raises an interesting question: why does frontend need a separate package manager? The answer reveals fundamental differences in how we think about server-side versus client-side code.