Archive for the ‘Firebug’ Category

« Older Entries

JavaScript Tabs: ExtCore vs jQuery UI

Thursday, January 21st, 2010

A while back, I built a website for a client using jQuery 1.3 because I needed a slide-show widget for the homepage. More recently I’ve been using ExtCore for small website widgets – mainly because I’m a bigger fan of ExtJS than jQuery. (ExtCore also didn’t exist at the time I built that website).

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.

ExtCore HTML Markup

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:

ExtCore JavaScript Code

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:

jQuery 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:

jQuery JavaScript Code

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?

Posted in AJAX, ExtJs, Firebug, JavaScript | 2 Comments »

Ext-Doc: ExtJS-style JavaScript Documentation

Thursday, June 25th, 2009

A while back, I posted about my struggle to find a good JavaScript documentation tool. Over the past week, I began exploring one more option which is very promising.

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.

Posted in AJAX, Blogs, ExtJs, Firebug, JavaScript | 2 Comments »

Parsing XML: jQuery vs. ExtJS

Thursday, June 18th, 2009

If you follow my blog, you’ve noticed that I constantly talk about ExtJS. I use it extensively at my office, and I know the API (for version 2.2.1) about as well as anyone not working for their company.

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?

Posted in AJAX, ExtJs, Firebug, Google, Web Development | 6 Comments »

YSlow 2.0 (beta2) Released

Wednesday, April 29th, 2009

I read earlier today that Yahoo released YSlow 2 (beta2) and I decided to give it a try.

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.

Posted in Firebug, Web Development | No Comments »

JavaScript Documentation Tools

Tuesday, March 10th, 2009

JavaScript documentation is a pain in the ass.

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.

Posted in AJAX, Firebug, Google, JavaScript, Web Development | No Comments »

« Older Entries