Long story short, this particular client (a restaurant) asked me to add some new content to their menu. Rather than expecting the user to scroll down a lengthy list of mouthwatering lunch options, I suggested that we add tabs to the menu in order to logically separate the menu items.

Since I already had jQuery 1.3 running the slide-show on this website I simply decided to build the menu tabs in jQuery to maintain consistency. But I was suddenly struck by an idea: why not compare how ExtCore and jQuery UI create tabs from HTML markup!

ExtCore

ExtCore can be downloaded from the ExtJS website, and an online demo of the simple tabs can be seen here.

The first step to building tabs from HTML markup using ExtCore is to reference ext-core.js in your page header. You also need to include the tabs.css file and the “images” folder containing the necessary 5 background images. (These can be found under “/examples/tabs/” of your ExtCore download ZIP.)

Note: I’m using ExtCore 3.0, although I believe 3.1 is available for download.

Next, we need to add the appropriate HTML markup for our tabs. Here’s a quick example.

As you can see from the picture above, ExtCore takes a wrapping DIV element (class “tab_container”) and converts a nested unordered list into the tabs. Subsequent child DIV elements contain the markup for each tab’s content. (The source code in this example is taken directly from the ExtCore tab example.)

The only thing to notice is that each DIV element has a CSS class assigned to it – these classes are essential to proper tab theming. The DOM ID properties are used to click back-and-forth between tabs.

Lastly, you need to include a JavaScript snippet which converts your HTML markup into a fancy tabbed widget:

jQuery UI

jQuery UI has a tab widget which is dependant on the larger jQuery library. An online demo of their tab widget can be seen here.

The first step to using tabbed content with jQuery is to reference:

• jquery-1.3.2.min.js
• jquery-ui-1.7.2.min.js

Your file versions may differ (I think jQuery 1.4 was just released), but these are the versions I’m using. I’m also using the “smoothness” theme – for some reason jQuery UI would not allow me to download the package without specifying a theme. (That may affect my analysis for speed in the next section.)

You will also need to include the CSS file and images folder included with your download of jQuery UI. In my case, it’s jquery-ui-1.7.2.css and an “images” folder containing 13 background images.

Next, write your HTML markup:

Compared to ExtCore, jQuery UI expects less HTML markup as we lose several layers of nested DIV elements. The most obvious difference between jQuery UI and ExtCore is probably that jQuery UI doesn’t need the extra CSS classes applied to the DIV elements.

Next, we add our JavaScript snippet:

Again, jQuery UI expects less code to generate the tabbed widget.

A Deeper Look

Let’s take a look at the file sizes for each library. This is about as un-scientific a study as it can get; I’m using Firebug’s “Net” tab to grab file size and download speed numbers. These numbers will probably be different for you because of any number of factors… but you get the idea.

As I already mentioned, ExtCore requires 1 JavaScript file, 1 CSS file and only 5 background images:

• ext-core.js (78.9 KB, 156ms)
• Ext.tabs.css (1.3 KB, 147ms)
• 5 png files (2.8-2.9 KB each, average 107ms)

Combing the file sizes and their download times (on my home network), you get a total of roughly 94.7 KB taking 838ms.

jQuery UI requires 2 JavaScript files, 1 CSS file and 13 background images (again, with the “smoothness” theme):

• jquery-1.3.2.min.js (55.9 KB, 116ms)
• jquery-ui-1.7.2.min.js (188.1 KB, 221ms)
• 13 png files (22.3 KB total*)

*Something interesting I noticed about the jQuery UI tabs is that my page only seemed to load 5 of the 13 background images, totaling something like 605 bytes and a total of 684ms. Perhaps someone more familiar with jQuery can explain that to me… I didn’t dig deep enough to figure out what was going on, but I’ll base my total on what Firebug says. I’m guessing that I’m not using all of the CSS background images for this theme.

Overall, that brings jQuery UI tabs to a total of roughly 245 KB taking 1021ms.

What Does That Even Mean?

According to my inaccurate, quasi-scientific study it appears that ExtCore requires slightly more code than jQuery UI. On the other hand, ExtCore also appears to be downloaded by my browser more quickly than jQuery UI. In reality, those numbers probably offset each other as the extra markup required by ExtCore increases the HTML file size. The fact that I’m using a theme on jQuery UI probably also has a slight impact on performance.

Which do I prefer?

In essence, both libraries create tabbed widgets from the same basic HTML markup – though the differences are significant enough that they’re not cross-compatible.

Judging both frameworks as they stand in my examples, I will say that I like the conciseness (is that a word?) of jQuery with regards to both HTML markup and JavaScript code. But I also like that ExtCore requires fewer files. As someone who uses the larger ExtJS framework a great deal, I’ll say that I am very likely to choose ExtCore over jQuery UI most days of the week.

Are there any ExtCore or jQuery UI users out there? What do you think?

Ext-Doc is a JavaScript documentation tool which creates by far the best looking documentation. Created and maintained by several members of the ExtJS community, Ext-Doc outputs your documentation using a template mimicking the ExtJS documentation. The tool is compatible on both Windows and Mac/Linux (it runs off Java) and fairly easy to setup.

So far, I’ve only encountered three issues:

1. The instructional Wiki on Ext-Doc site (hosted on Google Code) is simply terrible. It’s clear that the focus has been on developing the tool itself, but there’s close to zero documentation supporting it. If you need help, you have to search the ExtJS message boards.
2. The documentation output by the tool cannot be viewed locally – it must be uploaded to a server as it relies on Ajax.
3. The documentation tags are different from some of the other JS documentation tools

The first issue is obviously frustrating, particularly as the Java JAR file will hit errors and give you no reason why anything fails. Searching through the ExtJS forum and talking with the community has helped me get started, but this is a huge flaw and is (in my opinion) preventing Ext-Doc from being the defacto JavaScript documentation tool available. If they can get their Wiki up to date then this tool will certainly make an impact.

The second issue is actually pretty easy to work around on Microsoft Vista. Since Vista comes packaged with IIS7, you can simply tell the .BAT file to output the documentation to your local host’s root. This way, you can update and view your docs without having to copy/paste or FTP files to a web server.

Lastly, the tags used to document your JavaScript code are different in Ext-Doc than in JSDoc Toolkit (which is what I had been using). I don’t know if either tool is actually consistent with documentation standards in JAVA, but I wish that all of these JavaScript tools would use the same set of tags. It would make testing other tools much easier, and consistency in documentation is really important. Douglas Crockford (if you’re reading this), can we PLEASE get this discussion in front of the ECMA Standards board?

At the very least, I’m biased towards this new Ext-Doc tool (not really so new, actually) because I use ExtJS and I love their documentation. Once I get my tags updated, I think I’ll be very happy with this tool.

I recently came across a situation that has me frustrated because ExtJS doesn’t seem to have a built-in utility to solve my problem. Obviously, I can code something custom. . . but I’m frustrated because it’s more work than necessary and far from elegant.

The story begins about a year ago. My company (GFX International) has been working on an enterprise software solution for some time, and the developers wrote a method using jQuery (v1.2.6) to parse an XHTML server response returned during 500 errors. The idea is to create a popup window with the error message (one line of code), which is parsed from a rather long XHTML document (the default 500 error page returned by .NET).

The jQuery method is actually quite elegant and works perfectly.

getErrorText: function (response) {
    var errorCode = response.status;

    if (errorCode == 401 || errorCode == 403) {
        return 'You are not permitted to perform this action.';
    }

    //the custom error page has a DIV tag with this ID
    var errorMessage = $(response.responseText).find("div#errortext").html();

    if (!errorMessage) {
        //in DEBUG mode, we don't use custom error page.
        errorMessage = $(response.responseText).find("h2").html();
    }

    return errorMessage;
}

Over the past 9 months since I was hired as our Web Developer, I’ve redesigned the UI of this application so that it is built almost entirely on ExtJS widgets and extensions. The problem with the above method is that this now is the only place in the application where we use jQuery – meaning we have to include the jQuery library for only 2 lines of code.

My initial thought was: “I’ll just re-write this method using ExtJS and remove our dependency on jQuery!” Sounds easy enough, but in reality it’s actually a pain in the ass for several reasons.

First, the response variable returned during the 500 error is not a valid XML document. . . it’s not even valid HTML. The .NET framework generates a detailed error message contained within HTML tags, but after closing the final HTML tag is appends a stack of executed code lines leading up to the error. This section of appended data breaks the XML/HTML validity, essentially making it impossible for me to just throw the response variable into an DOMparser() object.

Second, ExtJS has no built-in utility for parsing a generic XML string for a specified value. In jQuery, every variable called by $(someVariable) is checked (1) to see if it’s a string, and if so (2) to see if it is HTML code (using a regular expression match). If jQuery believes your variable to be an HTML chunk, it runs it through a clean() method to convert the HTML string into DOM nodes (getting rid of any junk. . . *cough* .NET stack trace).

ExtJS does have a similar utility: Ext.query(selector, root). Unfortunately for me, this means that I can only parse an exisiting DOM node. Since my response variable isn’t part of the DOM (or even formatted as a proper DOM element) this method doesn’t really help me until I solve the first problem.

After posting this problem on the ExtJS message board, a member of their support team suggested that I simply build a regular expression to parse my response object. Obviously, this would solve my problem. However, it’s not an elegant solution; regular expressions are ugly at best (they are in fact my nemesis), and this solution fails to solve similar problems faced by other ExtJS users (I assume others have encountered this problem). The bottom line is that this type of utility would make a reasonable and very useful addition to the ExtJS library. . . so why isn’t one available?

I’ve been a big fan of the Firebug plugin, and so far I’m impressed with the improvements. I suppose time will tell (I’ve been using it for about an hour now), but I like the new UI. More importantly, the changes in their website grading scale seem to be worth while. YSlow now offers developers to select “Small Site of Blog” as an option when grading – a feature which makes the grade much more relevant in such cases.

However, I did notice that YSlow grades on an A thru F basis, including grade E (as in better than F, worse than D). I’m not sure what schools the Yahoo developers graduated from, but I’ve never had a teacher who gave Es. Odd, but I’m obviously nitpicking.

And while I do like the UI improvements, they seem to be better suited for when Firebug is a separate window rather than docked at the bottom of the browser. It’s a bit annoying to have to scroll constantly to read the output.

I haven’t read much about what else YSlow 2 will offer when it’s out of beta testing, but so far Yahoo has done an excellent job. It’s long overdue.

I’ve complained about this on my blog before, but I’ve spent the past week or so trying to test the handful of JavaScript documentation tools that are available and I’m actually starting to get mad. Why? Because there’s little standardization, and you have to be a computer scientist to get some of the tools to work.

Working on a Windows machine seems to further tie my hands, as (again) the tools all seem to use command line processes. While this isn’t a major handicap, I’m lucky in that I know what I’m doing — the average (or beginner) programmer is going to quickly get lost.

In an ongoing effort to explore my options as a JavaScript developer, here’s a review of the tools I’ve tried so far:

JS Doc Toolkit

After downloading the ZIP file, it’s pretty basic to extract. The project uses JAVA to walk the filesystem, parse your JS files, and build your documentation. The readme file is pretty self-explanatory, and walks you through using the command line (Mac, Linux, or Windows). I wrote a simple .BAT file to do the work for me… and I’m now a double-click away from fresh documentation.

YUI DOC

I’m already very critical of YUI, and I personally think this tool just sucks.

Not only do you have to know Python to run YUI DOC, but it doesn’t even work with the current version of Python! Are you kidding me? It needs to run on v2.4.3 – when v2.6.1 and v3.0.1 are available. That’s just retarded, and because I don’t feel like installing an older version of Python onto either of my machines (I have Vista and MacOSX) I simply gave up.

I also don’t like the output on YUI’s own documentation site, so I’m not really crying about this.

jGrouse

jGrouse is another JAVA-based tool which runs on top of the ANT platform.

Honestly, I had a hell of a time installing and running jGrouse. I had to re-install JAVA on my machine because I didn’t have the SDK with tools.jar installed… oy vey.

Once I finally got jGrouse running, I noticed that it didn’t pick up most of the comments I already had written for JS Doc Toolkit. Boo urns.

ScriptDoc

Here’s a framework you don’t have to install – it comes builtin with the Aptana IDE!

I haven’t been using the Aptana IDE much, but I might start. The interface is slick, and the fact that it has ScriptDoc builtin with the IDE is gravy.

Lessons Learned

If I weren’t doing a bunch of .NET development side-by-side with JavaScript, I would absolutely be using Aptana… and ScriptDoc. It’s by far the easiest documentation tool available, and clearly the best choice for Windows users.

JS Doc Toolkit is a close second, and (for now) the option I’m going with.

I have to say that it really bothers me that JavaScript documentation is not standarized at this point. Not only is setting up a tool a pain in the ass, but many of the tools want your documentation parameters in a specific order – which is just confusing. The parameters aren’t standardized across all of the documentation tools, which is even more confusing and frustrating if you want to change tools.

UPDATE (6/25/09): New post on Ext-Doc tool.

1. I do a lot of JavaScript and AJAX development
2. I’m a complete snob about using Firebug
3. I’m definitely not a fan of Safari (see It’s Official: I Hate Safari, and I Hate Safari, part 2 for reference)

I heard that Apple just released Safari 4 (BETA), which touts improvements in a handful of areas. As someone who openly hates Safari, my excitement regarding this release was easily contained.

What’s new in Safari 4? Besides a bunch of (in my opinion) minor and pointless UI changes, the browser will support HTML 5 and CSS effects. (I wrote a previous post about why I think CSS effects are a bad idea.) However, I was interested in two particular improvements — the Nitro engine, and the Developer Tools.

The Nitro engine (according to the press release) basically allows Safari to process JavaScript exponentially faster than both IE and Firefox. This is cool, and actually very useful… and by useful, I mean that applications relying heavily on JavaScript and AJAX will process information more quickly.

Safari also added some improvements to the debugging features in the Developer Toolbar. Namely, it looks like Apple has added the ability to see XHR actions and their request/response headers. This is pretty cool, though it doesn’t actually catch the POST parameters used in the requests like Firebug does… and that’s a huge feature to miss. Nonetheless, it makes my life easier to debug JavaScript in Safari.

My overall first impression: Safari 4 BETA is a good step forward (I’m testing the Windows Vista version). It still doesn’t make me want to stop using Firefox, but it will start making my life easier as a JavaScript developer. I guess I can’t say that I still hate Safari… but I’m far from being a fan.

One last thought: as Safari 4 is just a BETA version, I’ll be curious to see the finished 4.0 release.

As I near the completion of a software iteration, I have begun testing across all other browsers. Apple’s Safari (at least on Windows) is by far the worst browser when it comes to debugging JS code.

Why do I say that? Isn’t Apple supposed to be way ahead of Microsoft in just about everything???

For starters… I do like that Safari has a ‘Developer’ section built-in to the browser. That’s awesome! …except that it lacks something really important — a decent JavaScript debugger!

To further illustrate my point, the Apple developer docs are just as bad: they expect you to insert JS code into your own code so that your errors show up in their console debugger. You mean I have to add code just so your software works? No! The folks at Firebug figured that problem out… why couldn’t Apple?

It gets worse… even after adding the

window.console.log();

code to my own script, the Safari console log isn’t even helpful! It gives me an undefined error in a file… but I have 2000 lines of code! Can you be more specific???

I officially hate Safari. I never really used it before, but now I loathe the browser. I wouldn’t even bother to test in it if my client didn’t primarily use Mac products…

Has anyone found a great JS debugger for Safari?

However, when one has to figure out why something looks shitty in Internet Explorer… you’re basically up Shit Creek with no paddle. (That’s technical-speak for ‘You’re pretty much fucked”)

I’ve been trying to use a tool called DebugBar in IE7, but I’m only mildly impressed. There’s no CSS or JS debugger, so I’ve only found it useful for monitoring the console. As I do a lot of AJAX work, it is helpful… and for-better or for-worse, it’s the best thing I’ve found so far.

I’ve been confounded by a CSS issue recently in IE7, so I did yet another Google search for a CSS tool that I can use in IE. As luck would have it, I did find a useful tool… one which is actually pretty ingenious.

Called Joshascript DiscHover, you simply add the link to your favorites. Once you’ve navigated to the page where you need a CSS debugger, you select the link from your favorites list…

…and nothing happens!

Just kidding. The directions on the download page are fuzzy, but once you have clicked on your “favorite” link, you can left-click anywhere on your page and a popup appears detailing the CSS of that DOM element.

Pretty cool! I’m hoping this solves my issue in IE… if this tool doesn’t help me, you’ll definitely hear about it.

Now, I’ve known for years now that Firebug is like the single best web development tool available. I use it extensively on every project that I touch, be it professional or freelance.

The funny thing is… not every developer uses or even knows about it! I can’t imagine trying to debug CSS or JavaScript without it, namely because Firebug is so painlessly simple to use.

I was on a conference call the other day with an outsourced developer, and we were talking about some CSS issues that his team was facing. During the screencast, I opened their test site in my browser… and within seconds I had pinpointed the exact line in their CSS file causing the problem. The developer (who shall remain nameless) was floored.

I think I was more confused by the fact that no one on this guy’s team was using Firebug. Maybe I’m just enlightened (or spoiled), but in an age where technology is always changing and becoming more complex one would hope that programmers used the best tools available.

I do, however, have a major issue with Firebug — it’s only available (as fully functional) on the Firefox browser. I work in a corporate environment, and the majority of corporate employees use either Internet Explorer (using Windows) or Safari (using Mac).

There aren’t really any good tools for IE that do anything close to what Firebug can do. As a web developer, I make sure to thoroughly test my code across the major browsers — but isolating CSS and JS problems can be a major pain in the arse.

The bottom line: use Firebug.