Paul probably doesn’t need an introduction around here. He’s this smart successful front end developer dude who’s work fuels our inner critic. 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.
Works at the Goog on the Chrome Developer Relations Team. Lead developer of Modernizr. One of the creators of the HTML5 Boilerplate. Member of the jQuery Team. Creator of a bunch of useful one page sites. Links up a bunch of cool stuff on Twitter. Doesn’t like bands.
Here’s five questions I thought would be interesting to hear Paul answer.
*Chris: 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.
Paul: 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!
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.
*Chris: 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?
Paul: 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 if you’d like to watch the tools improve day by day.
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 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.
*Chris: Chrome uses a 6-week release cycle. 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.
Paul: There are three parts to this topic:
- browser release frequency
- browser version half-life
Versioning: Jeff Atwood wrote recently about the Infinite Version and detailed some of the engineering work behind Chrome’s update architecture. Web apps iterate quickly (Github ships to production 10+ times a day); I think it’s fine that browsers ship with quick iterations, and version numbers are merely just a means to keep track. Applying semantics to version numbers isn’t going to work unless we go back in time and Knuth makes demands that everyone abides by. (Webkit is at version 535, FWIW).
Half-life: If Chrome didn’t update all its users upon every release, all 120+ million Chrome users would be split across 16 versions. However, with the IE teams new engineering energy, we’re seeing a great new browser shipping annually from them, but without a clear picture of how users will be moved to the latest and greatest. I wrote about this a lot more recently.
*Chris: The picture that this paints is pretty grim. Do you really think it will get that bad? If IE can get on the auto-updating browser bandwagon, this problem should melt away pretty quickly right?
Paul: It’s tricky. Even if IE10+ are auto-updating (*fingers-crossed*), we’ll still have a slow death of IE8 (slow slow slow death, that is. I think we”ll always be in for a lot of pain. So, in order to keep yourself sustainably sane, be sure to develop awesome stuff.
Oh and I didn’t mention the situation on mobile, where we have lots of different browsers with unique feature sets. I suppose I should mention the value of feature detection now. That’s certainly key to making great experiences that can adapt to all the various browsers viewing your craftsmanship. Writing your own feature detects is tough, so I recommend you hop over to Modernizr’s site and create a small custom build of just the few tests you need.
*Chris: How about some advice for the people. What do front end developers need to be doing these days to be “doing it right”?
Paul: A lot! amirite? First, you’re deciding: am I making a webapp or a site? Is it for mobile or desktop? Responsive with top-down media queries or mobile-first responsive with bubble-up styles? Oh wait, I hear content-first was best. It’s tricky to keep track of all this so I’m a big proponent of not reinventing all wheels each project.
Ideally you use HTML5 Boilerplate to kick off new projects, use Bootstrap or your own custom equivalent. Making good use of preprocessors like SASS is also a huge timesaver and using Compass means you can let that manage all the prefix knowledge for you. Also hopefully you are experimenting with new features to stay ahead of the curve. There’s a lot of exciting stuff already in browsers that nobody has explored yet. Like you do, Chris, I’m happy to see people write down what they have discovered; helps out everyone and yourself. :)