{"id":14727,"date":"2011-10-26T21:41:47","date_gmt":"2011-10-27T04:41:47","guid":{"rendered":"http:\/\/css-tricks.com\/?p=14727"},"modified":"2011-11-30T20:55:52","modified_gmt":"2011-12-01T03:55:52","slug":"five-questions-with-paul-irish","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/five-questions-with-paul-irish\/","title":{"rendered":"Five Questions with Paul Irish"},"content":{"rendered":"

\"\"<\/p>\n

Paul<\/a> probably doesn’t need an introduction around here. He’s this smart successful front end developer dude who’s work fuels our inner critic<\/a>. So instead of a lengthy intro, I’m just going to drop a bunch of links so we don’t have to worry about it later. <\/p>\n

Works at the Goog on the Chrome Developer Relations Team. Lead developer of Modernizr<\/a>. One of the creators of the HTML5 Boilerplate<\/a>. Member of the jQuery Team<\/a>. Creator of a bunch<\/a> of<\/a> useful<\/a> one page sites. Links up a bunch of cool stuff on Twitter<\/a>. Doesn’t like bands<\/a>. <\/p>\n

Here’s five questions<\/a> I thought would be interesting to hear Paul answer.<\/p>\n

*<\/span>Chris:<\/strong> Would we be better off or worse off if Internet Explorer decided they were going to use the WebKit rendering engine? Long term and short term. <\/h4>\n

Paul:<\/strong> Tough to say, but as it’s never going to happen, I’ll just sidestep the meat of your question. Gecko, WebKit and Trident will be around and will never merge. Ever! <\/p>\n

At this point though, the IE engineering team is so engaged that really the priority is not getting WebKit into IE, but rather fixing IE’s situation. We’re looking at yearly releases from IE, which looks pretty good. But each release is expected to last 10 years in the wild. (IE8, 9, and 10 will be supported until 2020) Compare that to Chrome and Firefox, who sunset their old versions after 6 weeks when the new version ships… and it means we’re going to have a mess of IEs to simultaneously support. So, really, our pain isn’t standards compliance and developer pain with IE’s new releases, it’s dealing with many versions of IE to design our experiences, QA against, and deal with for years after their launch. <\/p>\n

*<\/span>Chris:<\/strong> How does the development of the developer tools in WebKit work? Are they actively improved by the Chrome team, then contributed back to the WebKit project, and in turn used by Safari? Or is there collaboration there by multiple teams?<\/h4>\n

Paul:<\/strong> Chrome has a really good-sized team actively working on the Chrome Devtools. Though, while I normally call them the Chrome DevTools, I could just as well say the WebKit Inspector; virtually all the work is committed directly upstream to WebKit, so Safari and the other WebKit ports get to benefit. My buddy Peter Beverloo made a nice RSS feed of all inspector commits<\/a> if you’d like to watch the tools improve day by day.<\/p>\n

There are some features in the Chrome DevTools that are unique to Chrome: live-editing of script and heap profiling are two big examples. But I’m very excited about the work the team has done on remote debugging<\/a> as that is now available to all mobile WebKit ports, which means you’re able to profile, view network detail, and edit the CSS live on your device. So pumped for that.<\/p>\n

*<\/span>Chris:<\/strong> Chrome uses a 6-week release cycle<\/a>. So next spring Chrome will be at “Version 20”. What are the advantages to a release cycle like this? What do you say to browsers that aren’t on as quick and regular a schedule? And to the peanut gallery with their “version releases used to mean something” mutters. <\/h4>\n

Paul:<\/strong> There are three parts to this topic:<\/p>\n