Loving WebKit: The Web Inspector Redesign is Huge

Posted: October 06, 2008 Comments(4)

I get excited about new software, sometimes to a fault. I also get equally excited about significant software updates that end up representing a significant change for the better. A piece of software with which I am consistently impressed with is WebKit. WebKit has another great factor in that it’s free, and you’re able to check out the latest and greatest using readily available Nightly Builds.

Not only am I a big fan of WebKit because it’s an extremely solid engine in and of itself, the developers get it. They’re consistently implementing features we all want to use, all the while refining their lightweight, reliable engine.

The Web Inspector Redesign

The WebKit team recently hit another grand slam with me in giving some love to the Web Inspector; it’s been redesigned. There is so much to say about the redesign, but that’s better left to the team itself. Instead, I’d like to briefly cover what I’m loving about the update.

Screenshot of the redesigned Web Inspector

The first change I was in love with was the decision to have the Web Inspector default as a panel in the browser itself as opposed to a separate window. Every time I use the Web Inspector in Safari, I always end up toggling that option and using a panel instead. Although it’s a tiny, fairly specific personal preference, I’m glad to see it changed.

I’m a big fan of the direction in which the interface changes are headed. I think the grouped information organization method will help developers do exactly what they want to do when they want to do it. Additionally, the interface now includes the console on every panel: awesome. Integration of the error and warning counts: awesome.

The Elements Panel

The Elements panel has had quite a bit of work done as well. Visually it’s quite similar but the WebKit team notes that a number of changes have been made under the hood. Specific to the way I work is:

  • Automatic updates – the DOM tree will update when nodes are added to or removed from the inspected page.
  • Inspect clicked elements – enabling the new inspect mode lets you hover around the page to find a node to inspect. Clicking on a node in the page will focus it in the Elements panel and turn off the inspect mode. This was contributed by Matt Lilek.

Of particular importance to me is the first item above: automatic updates. In this age of ‘JavaScript everywhere’ I’ve become increasingly dependent on the DOM as represented in the viewport, not the initial rendering. My workflow consists of using View Source as one reference (representing the initial document load) and comparing that to the living DOM. This is great news for me considering the way I work.

Inspecting clicked elements is something I’ve found myself doing all the time via Firebug lately. I’m not sure where I picked up the habit, and I don’t think it’s a bad one, but it’s great to see the feature available in the Web Inspector.

The Web Inspector update also includes style property editing. I’ve noticed that many developers are in the habit of using live CSS editing to fine tune things before committing to a stylesheet. I’ve never found myself in the habit, but I’m glad to see it in the Web Inspector update; it will be very attractive for many people. On top of that, the Elements panel lets you edit just about every aspect of your document live, making it quite an impressive tool by itself.

The Scripts Panel

I don’t believe any modern Web developer can make it very long without writing at least a small bit of JavaScript. That’s not to say that JavaScript represents a burden we all have to deal with, quite the contrary. JavaScript should be a technology all modern Web developers have on their utility belt.

The previous JavaScript debugger of the Web Inspector has been completely replaced with an integrated debugger: awesome. The debugger itself has been given a great jump start, incorporating some consistency with Firebug. You’re able to check out all the script resources present in the current document. You can set breakpoints, pause, resume, and step through the code. The Scripts panel also provides a sidebar consisting of the current call stack and in-scope variables. This is a great direction for the Scripts panel and I can’t wait to see it evolve even further.

If I had it my way, the Scripts panel would next include tracing of Ajax calls a la Firebug. I use that feature all the time. Having the ability to visually note when a call is made, when a call is completed, as well as the details of the call itself (e.g. response) has proven to be very valuable to me. Sure there are workarounds in logging much of the data, but it’s a great thing to have it all baked in.

I love WebKit

There is tons of information in the official Web Inspector redesign article, and I highly recommend you check it out as soon as possible. WebKit has always been half a step short of my full adoption primarily due to a lack of developer features, but this update has solidified my opinion that I’ll be using WebKit as a primary environment sooner than later. The features keeping me from switching have been menial things, but features I’ve become very comfortable with. The features are now making their way into nightly builds, and I couldn’t be more excited.

Get my newsletter

Receive periodic updates right in the mail!
  • This field is for validation purposes and should be left unchanged.

Comments

  1. Riddle: it definitely is. Check out Firebug for Firefox.

    I always surf in Safari because it’s so much quicker than Firefox (quick enough that I don’t really miss addons), but I couldn’t imagine developing without Firebug. Seeing this update, maybe that could change.

    …Although Firebug’s AJAX monitoring is invaluable and it would be a pain to not have that.

  2. While I’m still wed to Firefox and Firebug for developing, I’m definitely going to have to check Webkit out.

    It’s nice to see developer tools on most of the major browsers ( Opera/IE8/Webkit) – I can’t express how nice it’s going to be to use these tools instead of having to hard-code debugging script/css into a page when debugging browser-specific issues.

Leave a Reply

Your email address will not be published. Required fields are marked *