[ music | Ulrich Schnauss – Blumenwiese Neben Autobahn ]

Quick note to anyone subscribed to my old RSS feeds: I’ve moved to WordPress, and while all the old bookmarks work, old RSS feed URLs don’t. You’ll need to update them. Thanks.

So, like a brazilian other Photoshop and Dreamweaver users, I was happy to read all the new info Adobe was releasing about the CS4 suite. I’m fairly certain I would undergo severe withdrawl symptoms without PS and DW. As I read over the What’s New in Dreamweaver PDF, I discovered something I had been wishing Adobe (and previously, Macromedia) would address for a while, the less than stellar in-app preview renderer. It was marginally better than IE, but in no way kept up with Friefox, Safari, or Opera. They’re integrating a leading edge open source rendering engine into the app, specifically Webkit.

View your web pages under real-world browser conditions with the new Live View—while
still retaining direct access to the code. This new rendering mode, which uses the open source
rendering engine WebKit, displays your designs like a standards-based browser.
Changes to the code are immediately reflected in the rendered display.

I’m thrilled that finally the in-app view won’t suck. However, this will trigger yet another wave of “OMG Gecko is dead, Webkit roolz” posts from people who don’t understand what they’re talking about. Webkit is a great engine, and so is Gecko. But the two engines serve two different agendas. Webkit is about being lightweight and easy to pick up and easy to embed. Gecko is about being heavy duty, and does a lot more than just HTML. It has a heftier learning curve as well. If you want to embed an easy to learn web engine, grab Webkit. If you want to leverage an entire web platform, Gecko is your choice. They both have advantages and disadvantages, and are best in different scenarios.

To quote Nokia developer Oleg Romaxa in a recent interview,

Nokia will use the best browser for the job. Currently, we cannot make a full-featured and integrated browser with WebKit in mobile. But with Mozilla, we do not need to do anything, we can take existing models and API’s which are available. Also, NPAPI support is already in the Gecko web rendering engine.

Nokia was looking for a platform on which to build a browser for their products like the Nokia Internet Tablet. No one sensible is going to argue that Webkit can’t be part of an excellent browser, just look at Safari or Google Chrome. However, Webkit’s narrower focus meant that for Nokia, the better choice was Gecko.

For Adobe, Webkit was a better choice as it’s more easily embedded into other apps, and doesn’t come with a lot of things they didn’t need, such as XUL, plugin support, etc. Webkit is just part of the development environment. On the opposite end of the spectrum is NVu and KompoZer, which are web editors built entirely on Gecko. They leverage the platform Gecko provides, something you can’t accomplish with Webkit.