Blog


Object.getPrototypeOf

August 14th, 2008

Historically one JavaScript property that's seen a lot of use (mostly due to its convenience) is that of __proto__. It's a quick-and-dirty way of accessing the original prototype property of the object's constructor function. For example, the following is true:

"test".__proto__ === String.prototype

// Another alternative, not using __proto__
// Only works when constructor isn't changed
"test".constructor.prototype === String.prototype

This feature has been codified in the upcoming ECMAScript 3.1 specification as a new method: Object.getPrototypeOf(object) (and is implemented in the latest Firefox nightlies).

So how can we make use of this, now standardized, functionality?

instanceOf

If you wish you could implement your own version of the instanceof operator, using pure JavaScript.

function instanceOf(object, constructor) {
  while (object != null) {
    if (object == constructor.prototype)
      return true;
    object = Object.getPrototypeOf(object);
  }
  return false;
}

instanceOf("test", String);
instanceOf(true, Boolean);

In this example we traverse up the prototype chain, checking each constructor along the way. It's an effective method and allows for great expressiveness in our code.

Super Methods

We could use this function to call a super method, while doing some inheritance.

function Person(){}

Person.prototype.kick = function(type){
  alert(type + " kick!");
}

function Norris(){}

// Inherit properties from Person
Norris.prototype = new Person();

Norris.prototype.kick = function(){
  Object.getPrototypeOf(this).kick("Roundhouse");
};

In the above code we use Object.getPrototypeOf(this) to tap in to the original, inherited, kick method. Since we have since overridden the method we don't have direct access to it, but using getPrototypeOf we can capture, and utilize, it again.

Cross-Browser Implementation

The obvious question now becomes: How do we begin using Object.getPrototypeOf today if most browsers don't have it implemented yet? In the meantime we can use something like the following code for some form of compatibility:

if ( typeof Object.getPrototypeOf !== "function" ) {
  if ( typeof "test".__proto__ === "object" ) {
    Object.getPrototypeOf = function(object){
      return object.__proto__;
    };
  } else {
    Object.getPrototypeOf = function(object){
      // May break if the constructor has been tampered with
      return object.constructor.prototype;
    };
  }
}

While it's not 100% spot-on (since the .constructor property is mutable on any object - it's fully possible that it could've been manipulated by the user at some point) the above code should serve as a "good enough" solution to tide you over until browsers have good ECMAScript 3.1 compatibility.

Why Object.getPrototypeOf?

A common question at this point (and one that's sure to come up often as new features start to trickle in from ECMAScript 3.1): Why is the method Object.getPrototypeOf("test") and not "test".getPrototypeOf() - or even just a property, like __proto__? While having a method, or property, on every object would certainly be more convenient to use it ends up being impractical for generalized use.

For example, take the following case into consideration:

var obj = { getPrototypeOf: "blah" };

Any attempt to call its getPrototypeOf method would end in failure, forcing the developer to always have to fall back to using the generalized Object.getPrototypeOf. Since most uses of getPrototypeOf would be required to work in the general case the fallback would always have to be used. Thus it's not necessary to include it as an extra property of every object.

Additionally, it makes it far easier to backport to old implementations since you no longer have to extend the Object prototype (Object.prototype.getPrototypeOf = ...;) which would've been bad in any case.

Tags: ecmascript, mozilla, javascript

DOM DocumentFragments

July 21st, 2008

I was playing around with DOM DocumentFragments recently, in JavaScript, seeing what I could make with them. Roughly speaking, a DocumentFragment is a lightweight container that can hold DOM nodes. It's part of the DOM 1 specification and is supported in all modern browsers (it was added to Internet Explorer in version 6).

In reading up on them I came across an interesting point, from the specification:

Furthermore, various operations -- such as inserting nodes as children of another Node -- may take DocumentFragment objects as arguments; this results in all the child nodes of the DocumentFragment being moved to the child list of this node.

This means that if you take a bunch of DOM nodes and append them to a fragment then you can simply append the fragment to the document, instead (and achieve the same result - as if you had appended each node individually). I instantly smelled a possible performance improvement here. I investigated a little bit further and noticed that DocumentFragments support the cloneNode method, as well. This provides all the functionality that you need to highly-optimize your DOM insertion code.

I set up a simple demo to test the theory.

Let's take the situation where you have a bunch of DOM nodes that you need to append into the document (in the demo it's 12 nodes - 8 at the top level - against a whole mess of divs).

var elems = [
        document.createElement("hr"),
        text( document.createElement("b"), "Links:" ),
        document.createTextNode(" "),
        text( document.createElement("a"), "Link A" ),
        document.createTextNode(" | "),
        text( document.createElement("a"), "Link B" ),
        document.createTextNode(" | "),
        text( document.createElement("a"), "Link C" )
];

function text(node, txt){
        node.appendChild( document.createTextNode(txt) );
        return node;
}

Normal Append

If we wanted to append these nodes into the document we would probably do it in this traditional manner: Looping through the nodes and cloning them individually (so that we can continue to append them all throughout the document).

var div = document.getElementsByTagName("div");

for ( var i = 0; i < div.length; i++ ) {
        for ( var e = 0; e < elems.length; e++ ) {
                div[i].appendChild( elems[e].cloneNode(true) );
        }
}

DocumentFragment Append

However, when we bring DocumentFragments into the picture we can immediately see a different structure. To start we append all our nodes into the fragment itself (built using the createDocumentFragment method).

But the interesting point comes when it's time to actually insert the nodes into the document: We only have to call appendChild and cloneNode once for all the nodes!

var div = document.getElementsByTagName("div");

var fragment = document.createDocumentFragment();
for ( var e = 0; e < elems.length; e++ ) {
        fragment.appendChild( elems[e] );
}

for ( var i = 0; i < div.length; i++ ) {
        div[i].appendChild( fragment.cloneNode(true) );
}

Setting some time stamps we can see our results pay off in spades:

Browser Normal (ms) Fragment (ms)
Firefox 3.0.1 90 47
Safari 3.1.2 156 44
Opera 9.51 208 95
IE 6 401 140
IE 7 230 61
IE 8b1 120 40

As it turns out: A method that is largely ignored in modern web development can provide some serious (2-3x) performance improvements to your DOM manipulation.

Tags: javascript, dom

JavaScript Micro-Templating

July 16th, 2008

I've had a little utility that I've been kicking around for some time now that I've found to be quite useful in my JavaScript application-building endeavors. It's a super-simple templating function that is fast, caches quickly, and is easy to use. I have a couple tricks that I use to make it real fun to mess with.

Here's the source code to the templating function (a more-refined version of this code will be in my upcoming book Secrets of the JavaScript Ninja):

// Simple JavaScript Templating
// John Resig - http://ejohn.org/ - MIT Licensed
(function(){
  var cache = {};
 
  this.tmpl = function tmpl(str, data){
    // Figure out if we're getting a template, or if we need to
    // load the template - and be sure to cache the result.
    var fn = !/\W/.test(str) ?
      cache[str] = cache[str] ||
        tmpl(document.getElementById(str).innerHTML) :
     
      // Generate a reusable function that will serve as a template
      // generator (and which will be cached).
      new Function("obj",
        "var p=[],print=function(){p.push.apply(p,arguments);};" +
       
        // Introduce the data as local variables using with(){}
        "with(obj){p.push('" +
       
        // Convert the template into pure JavaScript
        str
          .replace(/[\r\t\n]/g, " ")
          .split("<%").join("\t")
          .replace(/((^|%>)[^\t]*)'/g, "$1\r")
          .replace(/\t=(.*?)%>/g, "',$1,'")
          .split("\t").join("');")
          .split("%>").join("p.push('")
          .split("\r").join("\\'")
      + "');}return p.join('');");
   
    // Provide some basic currying to the user
    return data ? fn( data ) : fn;
  };
})();

You would use it against templates written like this (it doesn't have to be in this particular manner - but it's a style that I enjoy):

<script type="text/html" id="item_tmpl">
  <div id="<%=id%>" class="<%=(i % 2 == 1 ? " even" : "")%>">
    <div class="grid_1 alpha right">
      <img class="righted" src="<%=profile_image_url%>"/>
    </div>
    <div class="grid_6 omega contents">
      <p><b><a href="/<%=from_user%>"><%=from_user%></a>:</b> <%=text%></p>
    </div>
  </div>
</script>

You can also inline script:

<script type="text/html" id="user_tmpl">
  <% for ( var i = 0; i < users.length; i++ ) { %>
    <li><a href="<%=users[i].url%>"><%=users[i].name%></a></li>
  <% } %>
</script>

Quick tip: Embedding scripts in your page that have a unknown content-type (such is the case here - the browser doesn't know how to execute a text/html script) are simply ignored by the browser - and by search engines and screenreaders. It's a perfect cloaking device for sneaking templates into your page. I like to use this technique for quick-and-dirty cases where I just need a little template or two on the page and want something light and fast.

and you would use it from script like so:

var results = document.getElementById("results");
results.innerHTML = tmpl("item_tmpl", dataObject);

You could pre-compile the results for later use. If you call the templating function with only an ID (or a template code) then it'll return a pre-compiled function that you can execute later:

var show_user = tmpl("item_tmpl"), html = "";
for ( var i = 0; i < users.length; i++ ) {
  html += show_user( users[i] );
}

The biggest falling-down of the method, at this point, is the parsing/conversion code - it could probably use a little love. It does use one technique that I enjoy, though: If you're searching and replacing through a string with a static search and a static replace it's faster to perform the action with .split("match").join("replace") - which seems counter-intuitive but it manages to work that way in most modern browsers. (There are changes going in place to grossly improve the performance of .replace(/match/g, "replace") in the next version of Firefox - so the previous statement won't be the case for long.)

Feel free to have fun with it - I'd be very curious to see what mutations occur with the script. Since it's so simple it seems like there's a lot that can still be done with it.

Tags: javascript

HTML 5 data- Attributes

July 13th, 2008

A new feature being introduced in HTML 5 is the addition of custom data attributes. This is a, seemingly, bizarre addition to the specification - but actually provides a number of useful benefits.

Simply, the specification for custom data attributes states that any attribute that starts with "data-" will be treated as a storage area for private data (private in the sense that the end user can't see it - it doesn't affect layout or presentation).

This allows you to write valid HTML markup (passing an HTML 5 validator) while, simultaneously, embedding data within your page. A quick example:

<li class="user" data-name="John Resig" data-city="Boston"
     data-lang="js" data-food="Bacon">
  <b>John says:</b> <span>Hello, how are you?</span>
</li>

The above will be perfectly valid HTML 5. This should be a welcome addition to nearly every JavaScript developer. The question of the best means of attaching raw data to HTML elements - in a valid manner - has been a long-lingering question. Frameworks have tried to deal with this in different manners, two solutions being:

  1. Using HTML, but with a custom DTD.
  2. Using XHTML, with a specific namespace.

The addition of this prefix completely routes around both issues (including any extra markup for validation or needing to be valid XHTML) with this effective addition.

On top of this a simple JavaScript API is presented to access these attribute values (in addition to the normal get/setAttribute):

var user = document.getElementsByTagName("li")[0];
var pos = 0, span = user.getElementsByTagName("span")[0];

var phrases = [
  {name: "city", prefix: "I am from "},
  {name: "food", prefix: "I like to eat "},
  {name: "lang", prefix: "I like to program in "}
];

user.addEventListener( "click", function(){
  var phrase = phrases[ pos++ ];
  // Use the .dataset property
  span.innerHTML = phrase.prefix + user.dataset[ phrase.name ];
}, false);

The .dataset property behaves very similarly to the the .attributes property (but it only works as a map of key-value pairs). While no browsers have implemented this exact DOM property, it's not hugely needed - the above code could be done with the critical line replaced with:

span.innerHTML = phrase.prefix +
  user.getAttribute("data-" + phrase.name );

I think what is most enticing about this whole specification is that you don't have to wait for any browser to implement anything in order to begin using it. By starting to use data- prefixes on your HTML metadata today you'll be safe in knowing that it'll continue to work well into the future. The time at which the HTML 5 validator is integrated into the full W3C validator your site will already be compliant (assuming, of course, you're already valid HTML 5 and using the HTML 5 Doctype).

Tags: html5, data, dom, javascript

jQuery LiveSearch

July 8th, 2008

A fun blog post popped up yesterday in which John Nunemaker ported a Quicksilver-style Live Search to jQuery. Taking a look at his code, I decided to have a little fun and re-port it to jQuery - trying to use the functional style that jQuery promotes. I think the end result is quite simple and elegant.

The final code - compare with John's port:

jQuery.fn.liveUpdate = function(list){
  list = jQuery(list);

  if ( list.length ) {
    var rows = list.children('li'),
      cache = rows.map(function(){
        return this.innerHTML.toLowerCase();
      });
     
    this
      .keyup(filter).keyup()
      .parents('form').submit(function(){
        return false;
      });
  }
   
  return this;
   
  function filter(){
    var term = jQuery.trim( jQuery(this).val().toLowerCase() ), scores = [];
   
    if ( !term ) {
      rows.show();
    } else {
      rows.hide();

      cache.each(function(i){
        var score = this.score(term);
        if (score > 0) { scores.push([score, i]); }
      });

      jQuery.each(scores.sort(function(a, b){return b[0] - a[0];}), function(){
        jQuery(rows[ this[1] ]).show();
      });
    }
  }
};

A couple points to note:

  • .liveUpdate() no longer takes an element ID - it now accepts any jQuery selector (this is the only notable API change that I made).
  • All state is stored in simple variables and accessed via closures, as opposed to as properties of an instance object.
  • Only one function is used - and that's stored away within the function itself (greatly simplifying the resulting code).
  • DOM queries are only done once and cached up front.
  • .map() is used to simplify the creation of new arrays of information.

Tags: javascript, jquery

jQuery Plugins, Size, and Storage

July 2nd, 2008

There is no such thing as a JavaScript plugin contends James Coglan. I completely agree that there are no, specific, techniques within the JavaScript language that make "plugins" possible (such as the ability to namespace code and import it, or some such).

HOWEVER - I will contend that such a thing as plugins exist and are logically distinct from "random JavaScript code that manipulates other JavaScript code" as long as the following points are met:

  1. There have to be explicit points upon which a plugin can attach. James notes the most common one in jQuery (jQuery.fn) but we have tons more - events, animations, selectors - all over the board for developers to snap in to.
  2. Even more importantly: Those points have to be documented or, at the very least, be under some sort of agreement that they will be treated like a normal piece of the user-facing API. In jQuery we treat all plugin extension points as "user-facing API" and only ever change them in major releases (if at all) and always provide an alternative for authors to use.
  3. Finally, there has to be some sort of repository for navigating these plugins. This is a huge differentiator. Simply referring to "code in the wild" as plugins doesn't really cut it if there's no commitment to hosting them and keeping their documentation and examples alive.

We take our plugin architecture very seriously in the jQuery project and are constantly looking for ways to improve (looking at plugins, reading their code, seeing what we can provide to make their lives easier).

Alex Russell of Dojo recently built a sleek 6kb version of Dojo - presumably for use on mobile platforms. He states in his post that:

Even so-called “lightweight” libraries like jQuery are far too heavy for some environments…not because they (like Dojo) pull in all the code needed to use them, but because they do it all up-front. Often the best time to pay the expense of loading, parsing, and executing JavaScript code is when the user takes an action that needs the enhancement to run.

The way it's worded you would assume that you were paying a large, up-front, cost to using jQuery when, in fact, there is very little overhead. jQuery has been shown to be the fastest loading JavaScript library for non-cached code and considerably fast for cached code.

Arguably a mini-Dojo would be able to provide an extra edge in this respect - however any gains that you would make up-front (which would be minimal - mini-Dojo is only about half the size of jQuery, as it stands) would have to contend with any future overhead incurred by loading additional components at a later time.

I frequently queue up long pages to read on my iPhone while I travel the subway system here in Boston and I think I'd be quite upset if I got halfway through a page, clicked a hide/show link, and found out that the action wasn't able to work since the requisite functionality hadn't been loaded yet.

There is a cost to loading "all" of jQuery up front, absolutely - however there are numerous benefits: It's highly cacheable, you never have to worry about what you do/don't have loaded, the API, documentation, tutorials, and examples are all dramatically simpler since you never have to worry about having extra components or making sure that they're being included correctly.

And, as always, if you're particularly excited about breaking jQuery down into little chunks you can grab the individual pieces from SVN and build a custom copy.

I was out of town when it happened but the release of the Google Ajax Library CDN (which includes the current release of jQuery) was incredibly cool. I've had a few requests from users wondering how this release came about. While I can't speak for the other projects, I can, at least, speak for what happened with jQuery.

Dion and I had been discussing solutions for providing better hosting solutions to JavaScript libraries for a long time (at least a year or two). Progress kept getting stalled at different points but persevered and got the release up at Google. I'm really glad to see this come about and I'm sure that jQuery users will certainly appreciate this release.

I have a couple points of concern with the release, namely:

  • How do we push a new release out? Currently we have to contact the guys at Google to get it pushed through - a way to automate this and do it programatically would be greatly appreciated (we could integrate it right into our release scripts).
  • How do new pieces of code get added? There's no way for other projects to get added to the repository - some sort of process for joining would be ideal.
  • SSL? Having an SSL-based CDN would be very useful, as well. However I suspect that if a site is going so far as to have SSL on their pages then they're probably not pulling their source code from an external site.

Other than that, though, I'm quite pleased with the release. The more that people pull from there the faster it'll be for everyone who uses JavaScript libraries (cutting away that initial download time).

Tags: jquery, javascript

eval() Kerfuffle

July 2nd, 2008

Last week it came out that, in Firefox (and other Gecko-based browsers) you could dip into the private scope of a function using eval, like so:

// Getting "private" variables
var obj = (function() {
  var a = 21;
  return {
    // public function must reference 'a'
    fn: function() {a;}
  };
})();

var foo;
eval('foo=a', obj.fn);
console.log(foo); // 21
 

I think the common response to seeing the above was something like: WUH!?!?

As can be seen in the ensuing discussions.

Perhaps more interestingly is the dig in to try and figure out how on earth this feature made it in to the language to being with. Brendan Eich provides some insight:

3.2 <fur> 1998-04-23 17:30: Initial checkin of JavaScript 1.3, migrated from JSFUN13_BRANCH in /m/ src repository

This eval extension, if memory serves (I was in mozilla.org at the time, not in the JS group at Netscape) originated in conversations with Microsoft's rep during ECMA-262 standardization, trying to reach agreement on a way to eval in other scopes.

At this point, however, it's pretty safe to say that since so few people know about it, and that (hopefully) there are no important sites relying upon its behavior, it can be stricken from the record.

Which it has been.

It's been a crazy ride but you can expect to see this feature gone in Firefox 3.1 (the next release of Firefox, set to debut this year).

Tags: firefox, mozilla, javascript, links

Powering a Web Revolution

July 1st, 2008

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

· « Previous entries

Current Projects

jQuery JavaScript Library

jQuery

Comprehensive DOM, Event, Animation, and Ajax JavaScript Library.

Recent Projects

Pro JavaScript Techniques

JavaScript Book

The best techniques for professional JavaScript. Published by Apress.

More Projects...

Hosting provided by the cool dudes at Engine Yard.