Articles

Writing Testable JavaScript

Print
PDF

We’ve all been there: that bit of JavaScript functionality that started out as just a handful of lines grows to a dozen, then two dozen, then more. Along the way, a function picks up a few more arguments; a conditional picks up a few more conditions. And then one day, the bug report comes in: something’s broken, and it’s up to us to untangle the mess.

As we ask our client-side code to take on more and more responsibilities—indeed, whole applications are living largely in the browser these days—two things are becoming clear. One, we can’t just point and click our way through testing that things are working as we expect; automated tests are key to having confidence in our code. Two, we’re probably going to have to change how we write our code in order to make it possible to write tests.

Really, we need to change how we code? Yes—because even if we know that automated tests are a good thing, most of us are probably only able to write integration tests right now. Integration tests are valuable because they focus on how the pieces of an application work together, but what they don’t do is tell us whether individual units of functionality are behaving as expected.

That’s where unit testing comes in. And we’ll have a very hard time writing unit tests until we start writing testable JavaScript.

Unit vs. integration: what’s the difference?

Writing integration tests is usually fairly straightforward: we simply write code that describes how a user interacts

The Design of Code: Organizing JavaScript

Print
PDF

Great design is a product of care and attention applied to areas that matter, resulting in a useful, understandable, and hopefully beautiful user interface. But don’t be fooled into thinking that design is left only for designers.

There is a lot of design in code, and I don’t mean code that builds the user interface—I mean the design of code.

Well-designed code is much easier to maintain, optimize, and extend, making for more efficient developers. That means more focus and energy can be spent on building great things, which makes everyone happy—users, developers, and stakeholders.

There are three high-level, language-agnostic aspects to code design that are particularly important.

  1. System architecture—The basic layout of the codebase. Rules that govern how various components, such as models, views, and controllers, interact with each other.
  2. Maintainability—How well can the code be improved and extended?
  3. Reusability—How reusable are the application’s components? How easily can each implementation of a component be customized?

In looser languages, specifically JavaScript, it takes a bit of discipline to write well-designed code. The JavaScript environment is so forgiving that it’s easy to throw bits and pieces everywhere and still have things work. Establishing system architecture early (and sticking to it!) provides constraints to your codebase, ensuring consistency throughout.

One approach I’m fond of consists of a tried-and-true software design pattern, the module pattern, whose extensible structure lends itself to a solid system architecture and a maintainable codebase. I like building modules within a jQuery plugin, which makes for beautiful reusability, provides robust options, and exposes a well-crafted API.

Below,

Matt Mullenweg on Yahoo-Tumblr

Print
PDF
31

On Yahoo-Tumblr

Yahoo

It now looks pretty certain that Yahoo has pulled off a deal to buy Tumblr for 1.1B. The relationship between WordPress and Tumblr has always been pretty friendly: Tumblr’s own blog used to be on WP, WordPress.com supports Tumblr as a Publicize option alongside Twitter and Facebook, our Akismet team sends them daily emails of splogs on the service, and there’s healthy import and export traffic both ways. (Imports have actually spiked on the rumors even though it’s Sunday: normally we import 400-600 posts an hour from Tumblr, last hour it was over 72,000.)

News like this, whether from a friend or a competitor, is always bittersweet: I’m curious to see what the creative folks behind Tumblr do with their new resources, both personal and corporate, but I’m more interested to know what they would have done over the next 5-10 years as an independent company. I think we’re at the cusp of understanding the ultimate value of web publishing platforms, particularly ones that work cross-domain, and while Yahoo’s all-cash deal by some metrics, like revenue, is very generous, I think it’s a tenth of the value that will be created in these platforms over the coming years.

Update: Some people are reading too much into the import numbers — I don’t think there will be an exodus from Tumblr. For more color read the comments on this post.


http://www.alistapart.com/

Read Full Article

MapBox Develops an Open Source Vector Format for Maps

Print
PDF

MapBox has developed an open source vector format to power the future of our web maps. Vector tiles rethink web maps from the ground up, providing a single efficient format to power raster tiles, interactive features, geojson streams, mobile renderers, and much more.

The MapBox team quietly started powering MapBox Streets, our worldwide base map, with vector tiles several months ago. Now with hundreds of millions of map views across thousands of subscribers, the stability and scalability wins are clear. We want to share our vision for where we are taking vector tiles and what this means for the future direction of MapBox.

http://www.alistapart.com/

Read Full Article

Paul Irish on Chrome Moving to Blink

Print
PDF

I know you’ve been asked this plenty of times already, but: no new vendor prefixes, right? Right?

Nope, none! They’re great in theory but turns out they fail in practice, so we’re joining and the and moving away them. There’s a few parts to this.

Firstly, we won’t be migrating the existing -webkit- prefixed properties to a -chrome- or -blink- prefix, that’d just make extra work for everyone. Secondly, we inherited some existing properties that are prefixed. Some, like -webkit-transform, are standards track and we work with the CSS WG to move ahead those standards while we fix any remaining issues in our implementation and we’ll unprefix them when they’re ready. Others, like -webkit-box-reflect are not standards track and we’ll bring them to standards bodies or responsibly deprecate these on a case-by-case basis. Lastly, we’re not introducing any new CSS properties behind a prefix.

Pinky swear?

Totes. New stuff will be available to experiment with behind a flag you can turn on in about:flags called “Experimental Web Platform Features”. When the feature is ready, it’ll graduate to Canary, and then follow its ~12 week path down through Dev Channel, Beta to all users at Stable.

The is documented and, in fact, WebKit just nailed down their going forward. If you’re really into prefix drama (and who isn’t!) Chris Wilson and I discussed this a lot more on [37:20].

How long before we can try Blink out in Chrome?

Blink’s been in Chrome Canary as