Blog


Powering a Web Revolution

Like every web developer I've spent a lot of time using the Firebug extension to Firefox in my day-to-day development. I've found it interesting to see how my development methodologies have changed with access to that tool.

Unsurprisingly, my personal development style mirrors much of the general web dev public. But what I find most interesting is to try and track trends in web development that Firebug has single-handedly revolutionized.

Firebug Advances

Performance Profiling

Prior to Firebug there was only rudimentary analysis of JavaScript performance (using tricks like injecting timers and computing the difference). Firebug brought us the ability to analyze all function calls during a period of execution, see how they each affected each other and, probably most important, see the difference in the sub-millisecond range.

Previously none of these techniques were possible with pure-JavaScript techniques - having the ability to tap into the JavaScript engine (which Firebug does) is fundamentally important to getting good analysis.

You can see an immediate interest, by JavaScript library authors, in the performance of their code bases around the time of Firebug's introduction of profiling.

Console logging with object introspection

Logging statements has always been possible with JavaScript (and, most infamously, with the alert() function) however Firebug gave us something significant: The ability to click and introspect into logged objects. This includes the ability to click DOM nodes (and see their properties and methods) and even normal objects (like Arrays or Object literals).

Firebug has to maintain a lot references to point to where these objects exist - and it wouldn't be possible in pure-JavaScript without introducing an excessive number of memory leaks.

Current Styles / CSS Rules

There had existed some tools for examining the current CSS style values of a DOM element (such as its dimensions and positioning) but Firebug brought a whole new level of inspection: The ability to see which stylesheet rules were introducing specific styling on an element. Not to mention the ability to edit the rules in-line (along with disabling them outright).

This level of inspection completely overhauled Web Design - and has been able to detach many web designers from their IDE-of-choice into a more agnostic view of CSS design. Absolutely the biggest short-coming of this feature is its inability to work cross-browser (although, that argument can certainly be used for most Firebug features).

Network Performance

Firebug's network tab gave developers the ability to see - in very real terms - two things: 1) How long a resource was taking to load and 2) How the loading of that resource was blocking the loading of other resources. #2 is especially important, seeing that the execution of JavaScript blocks other actions from occurring can be an eye-opening experience to most developers. Or even seeing how a slow-loading stat tracking script can prevent the further display of the page.

XMLHttpRequest Inspection

While XMLHttpRequest use existed prior to the existence of Firebug it was horribly hard to debug - it was rarely obvious where errors were occurring - on the client-side? on the server-side? in the transmission? The ability to see how the requests occurred - and very importantly - how long they took (and even how frequently they occurred!) has done much to improve the overall quality of Ajax use on web pages.

JavaScript Debugging

I would've said that JavaScript Debugging was a piece of that equation, as well, however Venkman definitely lead the way, in that respect (and has been a de-facto debugger for quite some time).

I'd argue that these trends wouldn't be where they are right now if it weren't for Firebug - and that tools are the primary reason for a development strategy's success. As a corollary look at the relative success of web standards - I'd argue that adherence to HTML or CSS wouldn't be where it is today without the tools to verify a page's compliance.

How to Improve

The question now becomes: What are the next set of tools that Firebug can introduce that will revolutionize its respective areas of development?

I'd like to propose a couple, possible, areas of interest:

JavaScript Library Analysis

As it stands Firebug's JavaScript function analysis is, perhaps, too finely-grained to provide help in many instances - especially when the use of JavaScript libraries is at play. For example, when using jQuery, you're generally more concerned with finding out how fast, or slow, a particular method is - or a selector - not the performance of all the individual internal methods of jQuery.

I began some of this analysis with my Deep Profiling jQuery Apps experiment but that's really only a test. Smart integration of JavaScript library knowledge into Firebug can provide significant details about how your code should be performing.

Visual Performance Profiling

Application performance profiling is rather clumsy right now, we have a number of disparate resources (network performance, rendering performance, script performance) that we need to mentally merge to create a full picture of what's happening. To counter this I'd like to propose a way of visually viewing how components of a site affect its overall performance. Perhaps a way to break things down like this:

  • Header: 300ms: 20ms Transmission + 20ms Parsing + 60ms CSS + 200ms JavaScript
  • Google Ad: [BLOCKING RENDERING] 600ms: 20ms Transmission + 20ms Parsing + 20ms CSS + 240ms JavaScript + 300ms Frame Loading
  • Sidebar: 400ms: 40ms Transmission + 40ms Parsing + 80ms CSS + 240ms JavaScript

The YSlow Firebug plugin already provides some level of analysis on your site - but it's much more holistic (giving you generic tips for files and pieces of code). Whereas a more specific approach would be greatly appreciated.

Ajax Improvements

We currently have the ability to view XMLHttpRequests as they occur, which is great, but some additions could be made that would serve to be quite helpful, such as:

  • The ability to manipulate a request and re-submit it. If you're attempting to see how different inputs will affect your site, this would be a great way to play back requests or see how they can be best improved.
  • Right now Firebug only lets you know the basic textual output that's coming from the server-side. Having it be able to tell you if incoming XML, JSON, or even HTML is syntactically correct (and even being able to navigate the resulting structures - as the browser would see them) would be a huge boon. As it stands it can be quite frustrating to receive a slightly-malformed response from a server and be stuck trying to figure out what's going wrong.
  • Better JSON/JSONP integration is essential. There are a large number of Ajax requests being done through dynamic script tag injection - and those are completely unmonitored by Firebug's XMLHttpRequest tracking. Being able to see what requests and responses look like - and where errors may be occurring - would be immensely useful.

Rendering Performance Analysis

While we have fantastic tools for digging in to the performance of JavaScript - CSS is a complete unknown. How much overhead do our stylesheets provide? How many elements does this CSS rule affect? Does this rule cause a costly reflow to occur? and how many times? How long does it take to render a particular portion of a page? Would changing the structure of my page help to improved perceived rendering speed?

Virtually all of these questions are un-answered and we need a tool to help provide a solid response.

Security Analysis

Security is one area that has seen virtually no attention in the respect of user tools. Most developers have no idea how secure their web site is or how vulnerable it may be to attacks. There needs to be easily-accessible tools for testing:

  • SQL Injection attacks
  • XSS Injection
  • Susceptibility to Spoofing (Data Encryption)

At the very least. The problem here is that while these tools will be incredibly useful for developers to improve their web sites - it'll also encourage malicious behavior. Although, arguably, those that wish to be malicious already have the tools to do so.

Standards Integration

Inline support for analyzing the standards-compliance of a page. Being able to see notes next to specific elements, attributes, CSS rules, etc. that show information on how they don't comply with particular standards - or even how they could be improved to match standards.

This includes inline strictness warnings for JavaScript (produced by the JavaScript engine).

I think that compliance should go a step further, as well, and look to provide information on Microformat and RDFa compliance - pointing out specific errors and helping sites to become better formatted.

Finally - RSS and Atom standards compliance. Notifying a developer that their site's RSS/Atom feed is malformed would allow them to immediately make a more compliant feed (a common area of mistakes).

Internet Explorer Support

The final, and perhaps most difficult, item that should occur would be a port of Firebug over to Internet Explorer. Both Safari and Opera have web developer tools integrated into their browsers - however Internet Explorer still consumes a majority market share and there's no good tools in sight. (I, personally, use CompanionJS but it's still a far cry from the full suite of utilities that Firebug provides - especially in the realm of DOM/CSS.)

This could probably be remedied if there was a really good pure-JavaScript Firebug (although the overhead associated with many of Firebug's features would lead to an astronomically-sized implementation). The current "Firebug Lite" is something of a joke - only vaguely functioning in modern browsers.


Not only do I want to see Firebug improve - it's imperative that Firebug continue to improve, for the sake of web developers everywhere. If it simply stalls and works into a stasis of bug fixes then web developers will be stuck with the current set of tools for quite some time. While other browsers are improving at a rapid pace, it'll still be quite some time before they are able to match the current feature-set of Firebug.

Since so much of web development ecosystem is currently linked to the health of a single tool advances have to be made now and they have to be made quickly in order for the web to flourish and survive as a development medium.

Tags: development, firefox, firebug, javascript, css, programming

JavaScript Updates in Firefox 3.0a3

Firefox 3.0a3 has just been released, including a number of changes and new features. A list of some of the major new features can be found on the Mozilla site.

However, there are a number of changes and additions that are particularly relevant to JavaScript developers, in particular, that I would like to take the opportunity to highlight.

(This reminds me, if you don't yet subscribe to The Burning Edge, I highly recommend it; it does weekly recaps of the changes that have gone into Firefox, highlighting important features or bug fixes.)

clientLeft and clientTop are now supported.

These two properties have long been a part of Internet Explorer and are now making their way into Firefox. This is to complement the clientHeight and clientWidth properties that already exist.

What these properties provide can be best described through a diagram; luckily, the Mozilla Developers Wiki already has some nice ones, so I'm just going to repost them here:

clientLeft

clientTop

While they're not terribly exciting properties to have, it's good to finally have a full set to work with.

You can hide cookies from scripts.

This one might seem rather innocuous, at first, but is a huge win in the Cross-Site Scripting (XSS) war. More often, than not, the true reward for performing some form of XSS is snagging valuable session information from a user's cookies. This relies on the fact that client-side JavaScript is able to access all of the cookies set and sent by the server. However, this is no longer the case. An HttpOnly flag, proposed and implemented by Microsoft in Internet Explorer 6, is now available in Firefox 3.0. A server, when setting a new cookie, can include the HttpOnly flag and know that the JavaScript won't have access to it. Of course, this isn't completely effective until all browsers have this property implemented, but it's certainly a step in the right direction.

Example:

Set-Cookie: sessionid=1234567; domain=mozilla.org; HttpOnly

You can mark resources as being available offline.

This is an interesting feature that doesn't, yet, have a specification-home (although, some suspect that it'll be adopted by the WHATWG). It provides the ability, for the user, to specify individual resources for special caching, should the browser move into offline mode.

In my personal tests, I was able to get it such that an XML file, specified exclusively as an "Offline Resource", was able to be retrieved, using an XMLHttpRequest, even while being disconnected from the Internet. You can view a demo here (Make sure that you're running, at least Firefox 3.0a3.) The relevant code, from the test page, is as follows:

...
<head>
    <link rel="offline-resource" href="test.xml"/>
    <title>Offline Resource Test</title>
    <script>
    window.onload = function(){
        var button = document.getElementById("button");
        button.onclick = function(){
            var xhr = new XMLHttpRequest();
            xhr.open( "GET", "test.xml", true );
            xhr.onreadystatechange = function(){
                if ( xhr.readyState == 4 ) {
                    alert( xhr.responseXML
                        .documentElement.firstChild.textContent );
                }
            };
            xhr.send( null );
        };
    };
    </script>
</head>
...

The important line being:

<link rel="offline-resource" href="test.xml"/>
which allows you to make the browser pre-cache the test.xml file, for later use. This can be done with a number of resource files (CSS, Images, etc.) and is not just limited to pieces of data; which makes it immensely useful. Mark Finkle has some more details on his blog.

RegExps have a new /y flag.

This feature has trickled down to us from the upcoming ECMAScript 4 (JavaScript 2) specification. More information about /y can be found there. In a nutshell: It allows you to start a regular expression leaving off where the last match, of the last expression, ended. In Perl, this is similar to placing a \G at the beginning of your regular expression.

JavaScript: Remove the first instance of 'dog' after the first instance of 'cat'.

var str = "mouse dog mouse cat dog";
str.match(/cat/);
str = str.replace(/ dog/y, "");
>> str == "mouse dog mouse cat"

Perl:

my $str = "mouse dog mouse cat dog";
$str =~ /cat/;
$str =~ s/\G dog//;
>> str eq "mouse dog mouse cat"

You can create new nodes in DOM Inspector.

A minor, but useful and important, feature addition to the built-in Firefox DOM Inspector. This new feature is perfect for performing additional testing on live pages, to see their effect. A quick demonstration of how it works:

There's a new menu option allowing you to insert a node in relation to the selected node:

Once selected, you can then insert an element (with namespace) or a text node:

Giving you a nice new result:

How to try all of this at home!

Mozilla provides full builds of the latest bleeding-edge installs. You can find them linked to the individual Burning Edge blog posts, or at the following URL:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Tags: webdev, development, javascript, programming, web

JavaScript Development Tools

This past week I attended Mashup Camp here in Boston - and was frequently asked what tools I used in development. I was quick to mention Firebug (I mean, I was giving a presentation on it, after all) - but I then thought about the other tools that I use in development and decided to expand on my list.

Firebug - I know that this has been said a thousand times, but let this be number 1001 - Firebug is a fantastic web development tool. In addition to all the features that everyone knows about, I've been using it extensively for a number of tasks:

  1. Optimizing the speed of large JavaScript codebases using the profile tool.
  2. Finding the source of slow page loads using the Net tool.
  3. Hunting down weird CSS results by looking at the resulting styles in the CSS tab.
  4. Giving presentations on JavaScript/jQuery.

I plan on writing about each of those much more. The end result is a Firefox extension that's worth its virtual weight in gold.

Packer - The ultimate JavaScript compression tool. The next best thing to using GZip compression. I use this extensively in jQuery, so I know most of its ins-and-outs. Depending on the file, I frequently get files compressed down to 25-30% of their original size.

Rhino - I love Rhino. It's essentially a collection of Java code that compiles JavaScript into Java. We use this all over the place to build jQuery. It's great because we can take JavaScript code, like Packer, and run it on any server that has Java - all in the background, and all without ever opening a browser. Additionally, we get the benefit of only ever having to code in one programming language for the entire project.

Selenium IDE - This is the newest weapon in my arsenal. It's a Firefox Extension version of the popular Selenium test suite. It is glorious. You hit the record button, click around your web site, hit stop - then play back the results. Save the script and use it again later to do some automated testing. I've used this on a couple sites now - it's great for testing dynamic web applications. (Just add in some sort of a "reset the database" callback to your code, and you can run all the tests on your server, remotely.)

I plan on writing and demoing all of these tools some more within the upcoming weeks - they're immensely useful, and I couldn't live without them.

Tags: mashupcamp, web, development, tools, programming, javascript

FUELing the Firefox

If you're ever spent time trying to grok Firefox Extension development (especially if you're coming from a pure web development background). You'll find that there's a lot that you have to learn to get up to speed. To name a few: XPCOM, RDF, XUL, and XBL in addition to a huge number of custom APIs for the different aspects of Firefox (Bookmarks, File I/O, Adding Buttons, Menus).

My first major project at Mozilla is to work with Mark Finkle and develop a JavaScript Library for use by Extension developers. If you're very new to extension development, then this will help you out, completely. We extrapolate out all the complex concepts into one, simple, package. The best part is that this whole thing is going to be available in the whole Mozilla platform (Firefox, Thunderbird, Seamonkey, XULRunner); and in multiple versions (for example FF 1.5-3.0).

We use very little of the actual underlying terminology and naming conventions present in the existing code base (this is bound to irk most established developers), and instead have adopted much of the terminology already present in JavaScript/DOM development. You can see evidence of this in our early API planning for versions 0.1 (Plan) and 0.2 (Plan).

In a nutshell, for 0.1, here's what we're tackling: Preferences, Events, Observers, Extensions, Toolbars, and Buttons; and the kind of improvement that you can expect:

Accessing a Boolean Preference

// 'Old' XPCOM way
var prefValue = false;
try {
   prefValue = gPrefService.getBoolPref(this.domain);
} catch (e) {
}

// 'New' FUEL way
var prefValue = Preferences.get(this.domain, false);

Watching for a change in a preference (obvserver).

// "Old" XPCOM way
gPrefService
    .QueryInterface(Components.interfaces.nsIPrefBranch2)
    .addObserver(this.promptDomain, this, false);

// "New" FUEL way
Preferences.addEvent( this.promptDomain, this );

Setting a unicode preference.

// "Old" XPCOM way
try {
    var str = Components.classes["@mozilla.org/supports-string;1"]
        .createInstance(Components.interfaces.nsISupportsString);
    str.data = aURL;

    gPrefService.setComplexValue("browser.startup.homepage",
        Components.interfaces.nsISupportsString, str);
} catch (ex) {
    dump("Failed to set the home page.\n"+ex+"\n");
}

// "New" FUEL way
Preferences.set("browser.startup.homepage", aURL);

We're really excited about where this is going, and we'd love some feedback. Feel free to comment on the wiki, find us on irc, or drop us an email. Here's Mark's take on the project. I'm really excited to be working with him and the whole developer relations team.

Tags: development, programming, javascript, firefox, mozilla, library

JavaScript Books

Secrets of the JavaScript Ninja

JavaScript Secrets

Secret techniques of top JavaScript programmers.

Pro JavaScript Techniques

Pro JavaScript

The best techniques for professional JavaScript. Published by Apress.

Micro Updates

John Resig Twitter Updates

@jeresig

Infrequent, short, updates and links.

JavaScript Jobs



Hosting provided by: Ruby Hosting by Engine Yard