And then it was revealed:

Windows["Microsoft Edge"] = new Browser();

I gotta believe the origins of the name go back to IE8’s “version targeting” scheme. Remember this?

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

A snarky, clever backhanded rant against the JavaScript-only crowd. Good for a chuckle:

They aren’t really on your site to read your article or check what time their train leaves - they’re really there to marvel at your buttery-smooth, hardware-accelerated 60fps animations and 1337 client-side javascript skillz that mean you can browse the entire site without ever once touching the server after the first page-load… just as long as you don’t mind that first page-load being 3MB in size, crapping out on unreliable mobile connections and taking whole seconds between DOM-ready and the UI actually appearing.

Yes. Yes it does. Some great stats in here including this gem:

O’Neill Clothing saw perhaps the most impressive increases after their conversion to mobile-ready. Transactions went up 112.50% on iPhones and 333.33% on Android. Conversions rang in at 65.71% on the iPhone and 407.32% on Android. Total revenue cleared 101.25% on iPhone and 591.42% on Android.

Wow.

Stuart Langridge beautifully illustrates all of the possible scenarios within which JavaScript availability is not guaranteed. Plan accordingly.

Bruce Lawson is dead-on with his critique of Apple’s feedback on Web Components:

Implementation is hard. Too hard for the developers at Apple, it appears. So Web developers must faff around adding ARIA and tab index and keyboard listeners (so most won’t) and the inevitable consequence of making accessibility hard is that assistive technology users will suffer.

We (browser makers and web developers) need to be willing to put in the effort to make things better for everyone else. Sadly, few seem interested.

Thanks for calling this out Bruce!

This is a brilliant post from Scott Jehl about optimizing page render by getting particular about how (and when) certain assets load. He uses the real-world site Wired as a test bed for putting the ideas into practice, cutting perceived load time by a full 8.5 seconds!

Abstraction can be helpful, but it also complicates things and leads to slower performance. Andrea Giammarchi provides lots of details here in examining a complex app scenario with the good old fashioned DOM vs. a handful of frameworks. Bonus points for the fact that most of the video evidence tests are being run on non-iOS devices!

No, the DOM is not your problem, the fact you brought an over-engineered abstraction on top of a deadly simple task, like a table that needs some quick update, is the real problem you don’t want to see.

If you dig Andrea’s post, you should also check out this post from the Filament Group.

Interesting insights from Thierry Koblentz on the unintended consequences of using will-change to identify elements likely to change in the interface.

A beautifully insightful piece from Jared Spool. Lots of gold in here.

It’s one thing to say design is important and to put phrases like “delivering best-of-class customer experiences” into the corporate mission statement. It’s another thing to change a corporation to truly make design a competitive advantage.

A few thoughts on cleaner Sass output from Anthony Dispezio. He secret? Using generic mixins in concert with @extend.