What Chrome means for developers

google_chromeBy now, you've surely seen every blogger on the planet sound off on Google's new browser.  There are dozens of reasons why this is an important development, and hundreds more if you speculate on ulterior motives.  I'll leave you to consider the overall market impact of this new browser, but if you develop web applications, there are some specific implications that I believe we're going to see in the next 18 months or so.

First, consider how Google's introduction of Chrome differs from the birth of any other browser.  After all, it's been a long time since a new browser garnered this sort of attention.  Not since Microsoft introduced Internet Explorer have we seen a browser hit the market as a predestined market contender.  Firefox, Opera, and Apple's Safari have built sizeable market share since their introductions, but it's happened over time.


frog Like the frog who's boiled because it doesn't notice the warming water, the web application development community hasn't seemed to notice that we're now developing for, and testing on quite a few browsers, and they really don't behave very consistently.

Chrome is going to be a shock to the system.  I really think there's going to be a significant collective realization that we're in big trouble here.  Sure, the WebKit rendering engine was already in use in Safari, but with a market share that started at zip and grew slowly, I know plenty of people who just ignored it.  But now, we've got IE in at least three major releases (6, 7, 8), FireFox in two major releases, Safari, and Chrome.

As if that weren't bad enough, the rendering engine is only part of the problem.  Both FireFox (in its upcoming 3.1 release) and Chrome are making a lot of noise about "improvements" they're making to JavaScript.  Am I alone in believing that this is going to cause all sorts of our newly-popular AJAX applications to start having issues?

Something's going to have to change.

I believe we're going to see a shift in how web UI's are built, because we just can't sustain manually checking and testing on all of these platforms anymore. That could mean a move to rendering technologies like Flash, SilverLight, or Air, or it could mean we start seeing more cross-platform JavaScript UI libraries.  Hopefully, we'll see both.

When we first started building web applications, we did so in part because it was a whole lot easier to deploy applications when we didn't have to worry about installing on individual workstations.  Why didn't we want to deploy to all those workstations?  Because they were all different from one another, and you couldn't count on them all to behave the same.

Hey - is it getting warm in here?

By the way, be sure to check out this great comic about Chrome - it says volumes.

Reblog this post [with Zemanta]

6 Replies to “What Chrome means for developers”

  1. The pain factor of deving web apps (even for an intranet) against the browsers we allow has been enough for me to start pinning for a GUI project. Frankly I think the problem is with CSS and HTML; both are poorly suited for what their claim is. HTML mixes in styling and CSS is a poor language to style something wit; web Pages are not print documents. Why can't I style elements the way I would a WPF GUI or a client app? It's almost enough to make a guy want to just do CANVAS based UIs…

    Btw, it's funny how the comments to that comic totally missed the point of why yet another fricken browser is a very tramatic thing for us Web Devs.

    Also, great blog. You got a new reader.

    1. Thanks, Lucas, and welcome.

      I'm really hopeful that in the same way that bank failures have finally driven us to be aware of and deal with our financial mess, this browser mess will finally drive software developers to acknowledge that we're in a world of hurt in terms of building our UI's.

      I hope so, anyway.

  2. The pain factor of deving web apps (even for an intranet) against the browsers we allow has been enough for me to start pinning for a GUI project. Frankly I think the problem is with CSS and HTML; both are poorly suited for what their claim is. HTML mixes in styling and CSS is a poor language to style something wit; web Pages are not print documents. Why can't I style elements the way I would a WPF GUI or a client app? It's almost enough to make a guy want to just do CANVAS based UIs…

    Btw, it's funny how the comments to that comic totally missed the point of why yet another fricken browser is a very tramatic thing for us Web Devs.

    Also, great blog. You got a new reader.

  3. Thanks, Lucas, and welcome.

    I'm really hopeful that in the same way that bank failures have finally driven us to be aware of and deal with our financial mess, this browser mess will finally drive software developers to acknowledge that we're in a world of hurt in terms of building our UI's.

    I hope so, anyway.

  4. Pingback: A WebKit powered Internet Explorer makes sense - WinExtra
  5. Pingback: A WebKit powered Internet Explorer makes sense — Shooting at Bubbles

Comments are closed.