Paul Irish

Making the www great

Why I’m So Excited About Web Platform Docs

I absolutely love developing for the clientside of the web. Delivering the actual interactions and UI that all users feel is an absolutely gratifying experience. However… it’s not a piece of cake to develop for all desktop browsers, mobile browsers, and all the device/OS combinations within.

It’s hard to track down accurate info, but hey we get by with an unruly combination of Mozilla’s MDN, StackOverflow, HTML5 Please, W3C/WHATWG specs, Wikipedia, and a mental inventory of blog posts, tweets and articles strewn over the internet.

Today’s announcement of Web Platform Docs, an initiative that’s been well over a year in the making, is huge. A few reasons why I’m pumped:

  • All browser vendors are working together to document the all of the clientside web: DOM, CSS, HTML, SVG, Canvas, HTML5, JS, ES5…
  • They’ve already contributed much of their content: all of the MSDN IE reference docs, the Opera Web Standards Curriculum, many HTML5 Rocks articles,
  • Full-time technical writers from Google, Microsoft, Adobe and others authoring content around new features in addition to the strong community contributions.
  • And obviously, a much more cohesive documentation situation, making it easier for us to develop with all the information we need.
  • Mozilla’s MDN content can be contributed!
  • The content is still alpha, but we now have a single place to document the web platform.

How can you help?

  1. “Upstream” your writing. If you’ve written a widely cited article exploring a feature or documenting cross-browser bugs, gotchas, certainly you can help a educate a vastly wider audience.
  2. Contribute browser support data. We thrive on knowing the mobile/desktop compat story. PPK will be publishing his compat tables there, and you can upstream compat facts from other sources freely.
  3. Fix bugs! Already a few bugs/annoyances have been unearthed. Please report them but more importantly, we’d love help fixing them! Attach a patch to a bugzilla ticket and we can push it live ASAP.
  4. Poke around the WPD: prefixed pages to get a feel for the current content activity.
  5. Jump into #webplatform on freenode IRC or join the public-webplatform mailing list.
  6. If you have expertise in technical writing or content strategy, we’d love your help!
  7. A whole lot more! Read the WPD: Getting Started guide!

This won’t be perfect overnight and will take a while to completely supplant existing distributed documentation sources… but I’m very excited about this first, shared small step. Three cheers to making a better experience for everyone building for the web.

A Browser Benchmark That Has Your Back: RoboHornet

The past few years’ browser focus on speed has been great for us and our users. We’ve seen a huge and dramatic performance boost on benchmarks like Sunspider, Kraken, and Octane. But, these benchmarks, often crafted by JavaScript VM engineers, test raw JavaScript performance, which is rarely the bottleneck we have in our apps.

These days, our performance bottlenecks are oftentimes DOM, <canvas> API methods, SVG. Those are our priorities. So then why do we see all browser vendors competing on raw JS when we are hacking our way around to avoid the actual performance pain points? So we wanted to solve that with RoboHornet.

Today, a cross-vendor collection of developers, led by Google, is open-sourcing RoboHornet. As project lead Alex Komoroske put it, “it’s a living, dynamic benchmark that aims to use the collective efforts of the web development community and ultimately get browser vendors to fix real-world performance pain points.” Let’s look at how RoboHornet will hopefully flip the above situation on its head.

  1. Web app developers identify and isolate a specific pain point in their app
  2. That issue is reduced down to a solid benchmark
  3. Propose it to a committee of JavaScript experts from JSPerf, YUI, Google, Facebook, and others
  4. Everyone votes for which issues should make it
  5. Of the top voted items, as long as the committee thinks they are good, they head into the benchmark
  6. The RoboHornet Suite now better represents the web app developer communities biggest priorities for performance
  7. Browser vendors compete on their RoboHornet score, optimizing the slow behaviors that developers prioritize
  8. Everybody wins. Yay ice cream for everyone!

What’s in there now

The current items that RoboHornet tests captures the major pain points of jQuery, Google Apps, Google Maps, Ember, Handlebars and Cappuccino:

  • Adding rows to an existing table
  • Adding columns to an existing table
  • Descendant selectors at different DOM depths
  • Converting a 2D canvas to a data URI
  • Clearing a 2D canvas
  • Table render speed after innerHTML.
  • Scrolling speed using scrollTop
  • Resizing columns in a table
  • Resizing SVGs
  • ES5 getter/setters
  • Referencing the arguments array
  • Scrolling lots of animated GIFs
  • The affect of forcing a reflow by calling offsetHeight
  • Replacing a number of DOM nodes using the Range API
  • localStorage write performance
  • localStorage read performance

You can vote on and review incoming tests in the issue tracker.

RoboHornet represents you

The project is still in alpha and we’d love to get your involvement to better represent everyone. We’re using Benchmark.js internally, as its experience on jsPerf has proven it a trustworthy and reliable benchmark harness.

  1. Please take a look at the site
  2. Watch the RoboHornet Github project
  3. Read how you can be more involved
  4. Submit the performance pain points that your apps run up against.

While you’re at it, go check out the full review of RoboHornet at Tom’s Hardware

Academic Research on Browsers, Frontend Development, and Debugging

University-level education has never really touched too directly on what we do as frontend developers. I know I was self-taught in the ways of the browser, as were all of my friends. Luckily the sort of webapp work we do these days is quite sophisticated so those CS graduates bring much of the great ideas to the JavaScript community. (Alex Sexton has been a personal inspiration here)

Early last year, something clicked in my head when I saw this video: Crossing the Chasm: Pitching Security Research to Mainstream Browser Vendors.

You mean.. there are academics… who are doing research on browsers.. in universities? My my! You mean bright minds think about the same things as us and don’t publish them on Octopress? ;)

Turns out it’s quite an active area of research. So, I’ve put together a list of academic papers, talks, and researchers all centered around frontend development and browsers (Please chime in on the comments if you know of more):


Gibraltar: Exposing Hardware Devices to Web Pages Using AJAX UC San Diego, Microsoft Research, Univ. of Singapore, 2012

Modeling and Reasoning about DOM Events Brown University, 2012

Don’t Repeat Yourself: Automatically Synthesizing Client-side Validation Code for Web Applications University of Illinois at Chicago, 2012


Who Killed My Battery: Analyzing Mobile Browser Energy Consumption Stanford, 2012

How far can client-only solutions go for mobile browser speed? ACM Digital Library, 2012

Race Detection for Web Applications Sofia University & ETH Zurich & IBM T.J. Watson Research Center, 2012

Leo Meyerovich - Berkeley Rsearch UC Berkeley, 2009 (Parallel Browser Execution, Security)

James Mickens - Microsoft Research Microsoft, 2004- (Performance, localStorage, Mashups, Speculative Execution

james mickens is amazing
James Mickens, the Galactic Viceroy of Research Magnificence at Microsoft Research, does awesome work. The above shot is from his MIX11 talk Making Better Web Apps For Today’s Browsers.

Debugging & Tools

Timelapse - Interactive record/reply with Webkit inspector Univ. of Washington, 2012

Cleanroom: Edit-Time Error Detection with the Uniqueness Heuristic Univ. of Washington, 2010

Firebug Research - Academic papers related to Firebug Various, 2012

Realtime Performance Visualizations using Node.js How to NODE, 2011

How Programmers Debug, Revisited: An Information Foraging Theory Perspective Wentworth, OSU, & IBM TJ Watson Research Center, 2010


Crossing the Chasm: Pitching Security Research to Mainstream Browser Vendors Carnegie Mellon, 2011

Benjamin Livshits - Microsoft Research Microsoft, 2004-2012 (Malware, Privacy, JS Benchmarking, JS Compression, JS Static Analysis, Security)

Dynamics of JavaScript Purdue, 2011

Adam Barth - Research Various, 2007- (XSS, CRSF, Security…)

Data Visualization

Highlights of the Infovis Conference, VisWeek 2011 2011


Gregor Richards - JS Research at Purdue Purdue, 2009-2011

Cleanroom University of British Columbia, 2011-2012

Anders Møller - Research Aarhus University, 2002-

Non-JavaScript Tooling

Whyline for Java Natural Programming, 2009

Stacks Plorer Media Computing Group, 2012

Omniscient debugging with TOD Pleiad, 2007

The Elm Programming Language Elm Lang, 2011-2012 (a type-safe, functional reactive language that compiles to HTML, CSS, and JavaScript)