Node.js 0.10 landed in March, and it feels like a turning point. Not because of specific features—though the performance improvements are real—but because it signals maturity. Companies are betting on Node for production systems, not just side projects. That shift deserves examination.
Tag: JavaScript
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.
The npm Model Doesn't Work for Browsers
Six months ago, Google released AngularJS 1.0, and the framework is starting to gain serious traction. After spending the last few weeks building with it, I'm convinced it represents a fundamentally different approach to client-side development—one that feels more like building desktop applications than manipulating the DOM.
The Mental Model Shift
The database landscape is changing. For decades, relational databases like MySQL and PostgreSQL have been the default choice for web applications. But in the past few years, a new category of databases has emerged that challenges many assumptions about how we store and query data. MongoDB, one of the most popular NoSQL databases, represents a fundamentally different approach to data persistence—one that aligns naturally with how web developers actually build applications.
If you're building web applications in 2012, MongoDB deserves your attention. This isn't about abandoning relational databases entirely, but about understanding when a document-oriented approach makes more sense than tables and foreign keys.
Understanding NoSQL and Document Databases
Before diving into MongoDB specifically, it's worth understanding what NoSQL actually means and why this movement has gained so much momentum.
NoSQL doesn't mean "no SQL" but rather "not only SQL." It's an umbrella term for databases that don't follow the traditional relational model. Within NoSQL, there are several categories: document stores (like MongoDB), key-value stores (like Redis), column-family stores (like Cassandra), and graph databases (like Neo4j).
As JavaScript applications grow in complexity, testing becomes not just important—it becomes essential. Whether you're building a single-page application with Backbone.js, adding interactive features to your Rails app, or creating a Node.js server, you need confidence that your code works correctly. That's where Jasmine comes in.
Jasmine is a behavior-driven development (BDD) framework for testing JavaScript code. Unlike traditional unit testing frameworks, Jasmine focuses on describing the behavior of your code in a way that's readable and expressive. You write tests that read almost like English sentences, making it easier to understand what your code is supposed to do.
In this post, I'll walk you through everything you need to know to start testing JavaScript with Jasmine, from basic concepts to advanced techniques like spies and asynchronous testing.
What Is Jasmine?
Jasmine is a standalone JavaScript testing framework created by Pivotal Labs. It doesn't depend on any other JavaScript frameworks or libraries, and it doesn't require a DOM. This makes it perfect for testing JavaScript code in browsers, Node.js, or any other JavaScript environment.
The framework follows BDD principles, which means you describe what your code should do using nested functions called suites and specs. A suite is a group of related tests, and a spec is an individual test case. Together, they form a readable description of your application's behavior.
Introduction
The JavaScript application landscape is evolving rapidly. Just a few years ago, using JavaScript to build complex single-page applications seemed impractical. Today, we have frameworks competing to provide the best developer experience and most powerful features for building what we once thought impossible in the browser.
I've been exploring Ember.js over the past few months, and I'm impressed by its ambitious approach to solving common problems in JavaScript application development. Unlike minimalist libraries that give you just the basics, Ember provides a comprehensive solution with strong opinions about how applications should be structured. This opinionated approach might not appeal to everyone, but for teams building complex applications, having these decisions made for you can be liberating.
Introduction
Modern front-end development involves numerous repetitive tasks: minifying JavaScript, compiling CoffeeScript or LESS, running JSHint to catch errors, concatenating files, running tests, and more. Performing these tasks manually is tedious and error-prone. Forget to minify before deployment? Your users download bloated files. Skip linting? Bugs slip through that could have been caught automatically.
Build automation has long been standard practice in back-end development, with tools like Make, Rake, and Ant handling compilation and deployment tasks. But front-end development has lacked a cohesive, JavaScript-native solution—until now.
Introduction
Responsive web design has solved many problems related to building websites that work across devices—fluid grids adapt our layouts, media queries adjust our styles, and flexible images scale to fit their containers. But there's one aspect of responsive design that remains frustratingly unsolved: the responsive images problem.
The issue is straightforward: responsive websites need images that adapt not just visually but also technically. When you set max-width: 100% on an image, it scales down beautifully on mobile devices, but there's a hidden problem—that mobile device still downloaded the full-size desktop image. A user on a smartphone with a 320-pixel-wide screen doesn't need your 1200-pixel-wide hero image, yet they're downloading it anyway, wasting bandwidth and slowing down page load times.
Introduction
JavaScript applications have evolved dramatically over the past few years. What started as simple form validation scripts have transformed into complex single-page applications that rival desktop software in functionality. However, as JavaScript applications grow larger, they become increasingly difficult to maintain. Code becomes tangled, jQuery selectors proliferate, and making changes to one part of the application unexpectedly breaks another.
This is where Backbone.js comes in. Created by Jeremy Ashkenas (the same developer behind CoffeeScript and Underscore.js), Backbone provides structure to JavaScript applications by organizing code into Models, Views, Collections, and Routers. It's not a full-featured framework like some of the heavier options out there—instead, it provides the minimal structure needed to keep your code organized while staying out of your way.
Introduction
jQuery made manipulating the DOM easy. But as JavaScript applications grow, jQuery alone isn't enough. You end up with spaghetti code – event handlers everywhere, data scattered across the page, no structure.
Backbone.js solves this. Created by Jeremy Ashkenas (also behind CoffeeScript and Underscore.js), Backbone provides structure for JavaScript applications. It's not a full framework like Rails – it's a library that enforces architectural patterns.