Infrequently Noted

Side-by-side versions of different browsers are critical for us webdevs. On some browsers, it's because multi-year-old versions are still prevalent (luckily, you can start ignoring them). In the case of Chrome, nearly all users are up-to-date with the very latest Stable release. Being the forward thinking chap/gal you are you want to try out new stuff like WebGL that's only available in the Dev channel. But you don't want to mistakenly build something that uses features users don't have yet. What to do? Side-by-side installs, a.k.a. the Canary channel! Now you can test with Stable while plotting world domination on Dev. Awesome.

This new version will auto-update with the new hotness at roughly the same rate as today's Dev channel but will allow you to install and run it alongside a Stable channel version of Chrome. This new channel is Windows-only for now, but you have VMs for testing anyway, right? Happy testing!

You can get yours here. Note that these are Dev Channel builds, so they contain the new hotness. Also, the new bugs. Caveat emptor.

Huge props to Robert Shield who has been working through the endless details of this effort for months.

So you're making the new shiny — 'cause that's how you roll — and you're thinking to yourself "hrm, I've told users of legacy browsers to get Chrome Frame or upgrade, but there's this new awesome feature in the Chrome Developer Channel...but it's not in the version of Chrome Frame I'm testing with. I thought I was on the Dev channel?"

Indeed, if you installed GCF prior to the Beta release, you would have been on the Dev version, but when the Beta was pushed, all existing GCF users were moved to it as a one-time transition. That means you might not be getting the new shiny features we're pouring into Dev as quickly as you anticipated...but fear not! There's a new Dev Channel Release available. If you're developing sites with GCF and you want to see what's coming, I highly recommend getting and testing against this version. You won't be moved to Beta again, so this uninstall/reinstall is a one-time change.

As folks begin to use and test with GCF, one of the first many try is to use the OptInUrls registry key to over-ride a site's preference about which renderer to use. This tends to cause confusion and spurious bug reports because many sites employ server-side User-Agent detection to send different content to different browsers. Since GCF uses IE's network stack and reports a slightly modified IE User-Agent instead of Chrome's UA, server-side detection may send IE-specialized content instead of Chrome-friendly content. This includes many large sites like Yahoo, GMail, and most sites built with GWT's server-side detection.

These are not bugs.

Those sites are working as intended and GCF is operating correctly. What's happening, instead, is that by adding sites to the OptInUrls list that do not understand GCF, you're breaking the contract at the core of how GCF works: existing content works the way it always has. It's only when you're sure that a site is sending browser-neutral content (usually when it's your site) that you should ever add a site to the OptInUrls list for your system or organization. As usual, if you've got questions about GCF that aren't answered in the FAQs or docs, you can ask them on the Google Group for the project. The whole team is subscribed to the list and we're focused on helping you make awesome apps, so stop by, say howdy, and let us know how it's going.

Today we launched our first Beta release of Google Chrome Frame (aka "GCF").

In some ways it's a strange product; it's working best when you notice it least. As a developer, you shouldn't have to think much about it other than to include the header or meta tag or and optionally add a couple of lines of script to prompt users to install the plugin -- a process which notably doesn't require a restart and doesn't take users off of your site. There's no new tool to learn, no new language you have to wrap your head around...in fact, the hardest part might just be putting down all the habits we've collected for catering to legacy browsers. The new features in Chrome Frame are all the existing features you haven't been able to exercise yet.

As I've begun to build exclusively to modern browsers, the experience of concerted un-learning of hacks and the ability to write directly to the platform again, sans toolkit, has been eye opening. Yes, there's still a lot that can be improved in DOM, CSS, and HTML, but things are moving, and the tools we need now aren't the tools we have today. Better yet, there's every indication that things are progressing fast enough that instead of building tools to bring up the rear, we'll be building them to shield ourselves from the ferocious pace of improvement should we need them at all.

If you're starting a new project today, I encourage you to prototype to HTML5 and modern features and then think hard about what you're building and for whom. Do these apps really need to run on legacy browsers? Why not just use GCF to make that pain and expense go away. Once you've experienced how good modern web development can be -- how rich and fast the apps you can deliver are -- I'm convinced that you'll find it hard to go back. The rich, open, interoperable web is the platform of the future, and I couldn't be happier that GCF is going to help deliver that future.

I had the pleasure and honor of speaking on Google Chrome Frame (slides) at JSConf this past weekend. The conference was small enough that meeting some large percent of the awesome people there was feasible yet large enough that it drew many of the folks doing some of the most interesting work in the JavaScript community today. Frameworks were well represented, as was server-side JS. If you can only go to one conference a year, I can recommend JSConf without reservation. As a speaker, Chris and the organizers treated us better than anyone could hope for, and as an attendee the quality of the content and the hallway conversations left me constantly with the feeling that I was lucky to be where I was but sad that I was probably also missing something else that was awesome.

For some reason Chris — fearless pirate leader that he is — thought it hilarious to have me follow not only Billy Hoffman's outstanding security talk, but also Brendan Eich's never-fail wit and delivery. Funny in that "watching people walk the plank...good times" sort of way. I was also between a bunch of people who (apparently) know how to drink and a truly awesome Google-sponsored party. No pressure. None at all.

Somewhat counter-intuitively my talk focused not on what JavaScript can do, but why we'll be using less of it in the near future; at least for the things we're currently burning bandwidth and CPU. HTML5, CSS 3, and developers who are liberated to take advantage of them are going to kill off a lot of code. Take, for example, the slides for my talk. The only JS library that's included is for prompting users to install Google Chrome Frame. GCF will accelerate the transition to new standards and new ways of building apps. We'll build faster apps not by employing ever-more exotic ways of mangling JavaScript or by giving up the simplicity and directness of HTML and CSS, but rather by simplifying what we write and what we send over the wire.

I'll be talking more about this at Google I/O next month, so if you missed JSConf, hopefully I'll see you there.