Paul Irish

Making the www great

Interview on Treehouse

The great folks at Treehouse sat down with me for 30 minutes to talk about frontend development, my background, HTML5 Boilerplate and tooling.

A few highlights:

  • 3:40 Where’d I grow up? What was I into? (Also, the supercool IE4 DHTML event I went to!)
  • 14:45 What’s my favorite feature inside the HTML5 Boilerplate?
  • 18:34 Will web development even out where we don’t need to fuss over so many fallback scenarios?
  • 22:52 Are abstractions okay? Should you always learn what’s going on under the covers first?

I’ve also updated the interview listing on my About page. <3z

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