What’s come up since the last time I did any sort of Javascript performance comparison? Well, Google Chrome and its JS engine (“V8″), for one. Also, something of a new era in Javascript handling that attempts to optimize how browsers handle it by converting it to bytecode (or, in the case of JavaScriptCore/Squirrelfish Extreme/Nitro, directly to native machine code). In addition, there’s been some new benchmarks arrive on the scene, which allows us to tease out bias from any particular one.

It’s amazing, really, to compare these numbers against the linked benchmark from a mere 1.5 years ago. Opera went from being the top of the heap with 9.5 to being a lazy 3rd or 4th place. And Chrome, of course, decimated the competition (so far). Read on for the testing methodology and the results.

The tests

I chose four different benchmarks, three of which are entirely Javascript and one of which is mostly Javascript.

1. Dromaeo is a large, comprehensive benchmark that optionally incorporates some of the other benchmarks we’re looking at today. It was created by the Mozilla Corporation. It offers several test suites, but the one used here was the Dromaeo subset of tests
2. SunSpider is a benchmark created by the folks behind WebKit. It quickly became and remains one of the most popular and venerated Javascript benchmarks available.
3. V8 Benchmark is a benchmark application designed by Google to test its V8 Javascript engine. It’s actually a very short and simple benchmark that fantastically favors Google’s browser (and Safari).
4. Peacekeeper is a new browser benchmark by FutureMark. It’s supposed to test not just Javascript performance, but some rendering performance as well. As you will notice below, the numbers seem a little funny, as it appears to favor Safari (WebKit + Nitro) by a significant margin

The Hardware

All tests were run in Safe Mode (where applicable; meaning that no additional plugins or widgets were loaded) on the following hardware:

• Intel Core2 Quad @ 2.4GHz
• 4GB RAM
• Windows 7 build 7229, x64 Ultimate Edition

The Data

What follows is the raw data table. Jump down for the summary.

The Conclusion

So what does this data tell us?

For starters, it means that the much-vaunted but long-developed Tracemonkey javascript engine in Firefox 3.5 is already a distant third-place player, if not fourth-place. Chrome’s V8 engine outperforms it by no less than a factor of 2 on just about every test. In fact, Chrome 3 on Windows 7 is the fastest browser available, period. Now, Chrome is a very simplistic browser (not even a print preview) and it remains to be seen if its competitive edge in terms of rendering and javascript speed will hold true when it’s got other things to worry about (i.e. plugins).

Safari 4 is a combination of the WebKit rendering engine (like Chrome) and JavaScriptCore, which is the umbrella project name for WebKit javascript engine. While the SquirrelFish engine in Safari 3.1 was fast (doing the JIT bytecode compiling that Firefox 3.5 is doing now…), the new SquirrelFish Extreme engine actually compiles to native machine code. It pulls respectable performance across all tests, usually ranking just behind Chrome…. with the notable exception of the Peacekeeper benchmark, where it takes the lead score. Unfortunately for Safari, its greatest accomplish with version 4 is only managing to not look completely horrible on other platforms, so needless to say it isn’t going to be a contender for the Win32 crown anytime soon.

How far Opera has fallen from grace. Whereas a couple of years ago it sported the fastest rendering, some of the greatest features, and a great javascript stack, it was quickly eclipsed by the flurry of development happening in other browsers recently. The beta of version 10.00 improves javascript performance significantly, although Opera’s own efforts toward bytecode-based javascript handling aren’t scheduled to land until well after 10.00.

Internet Explorer is, well, still Internet Explorer. While version 8 is a remarkable improvement over version 7, just as 7 was a spectacular improvement over 6, it is still the last shriveled pickle at the bottom of the jar, limping by in each and every benchmark. Microsoft, in their latest FUD to paint IE8 as a wunder-browser, correctly point out that javascript speed isn’t everything, but both benchmark and simple user testing are enough to point out that Microsoft’s browser team is working hard just to stay in the race; they’re not gaining ground at all.

After the initial learning curve, this has all been going swimmingly. I merged my first development branch into the trunk yesterday, and this branch just so happens to dovetail nicely into the whole point of this post, which is the YUI compressor, an open-source javascript and CSS minification tool developed by Yahoo’s YUI team.

The Problem

To understand quickly why one should minify production client-side code, consider only that with the upward trend of size in javascript libraries (and the necessary files for such libraries), it’s possibly to be downloading a lot of client-side code in a typical web application, especially as its scope grows.

For a long time, I was using Dean Edward’s Packer, as was everyone, because its Base62 encoding produced the very lowest file size. However, what should have been obvious to everyone is that eval(bunch_of_stuff_goes_here) is making the browser do a lot more work, and this is a problem on dinosaurs like IE6.

To make matters worse, the nature of such encoding also meant that for servers which tried to compress outgoing content like javascript (either with zlib or gzip), the compression ratio suffered. Just look at this table that Julien Lecomte posted last August.

I said to myself, “Hey, we use a lot of this stuff, and we still support a lot of users with slow computers and slow browsers.” So, I moved our project from a Packer-based compression to a YUI-based compression, and turned on server-side GZIP compression for javascript files. The only problem was that I was storing the javascript files already minified, and simply pasted them into a large a couple of large global .js files. I had to keep a separate source directory, along with any customizations.

This got to be a pain in the ass, as you might well expect, and so when it occurred to me that I might be able to use the YUI library at build-time in our Netbeans project, I immediately sprung into action.

This was around April, and one night while attending Sungard Summit in Anaheim. I did the initial work to get our Netbeans project into a state that could use the YUI compressor at build-time, creating separate source file directories and breaking our massive javascript file into modules; I did the same with our CSS, splitting it up based on what it decorated.

There are a few tutorials about using the YUI library. Some of them involve adding the YUI library to Ant’s classpath (didn’t want to go down this route); a lot of them involve invoking the library as an external executable during the build process, which is messy.

The solution I finally settled on was yui-compressor-ant-task, a small library that allows Ant to use YUI as a build task. By adding this library and the YUI compressor library to our common libraries folder, and enabling them at build only (and not for deploying in the web archive), it makes using the compressor pretty easy.

Here’s part of our build.xml:

<!--
   * minify will concatenate all of our non-TinyMCE javascripts and stylesheets
   * then use the YUI compressor library to compress them
   -->
   <target name="minify">
       <!--${libs} is path to the downloaded jars -->
       <property
           name="yui-compressor.jar"
           location="${file.reference.yuicompressor.jar}" />
       <property
           name="yui-compressor-ant-task.jar"
           location="${file.reference.yui-compressor-ant-task.jar}" />
 
       <path id="task.classpath">
           <pathelement location="${yui-compressor.jar}" />
           <pathelement location="${yui-compressor-ant-task.jar}" />
       </path>
 
       <!-- yui-compressor task definition -->
       <taskdef
           name="yui-compressor"
           classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
 
           <classpath refid="task.classpath" />
       </taskdef>
 
       <!-- concatenation of javascript -->
       <echo message="Building global javascript" />
       <concat destfile="${build.dir}/web/common/js/global.js" force="no">
           <!-- explicitly order js concat because ordering matters here -->
           <fileset dir="${build.dir}" includes="web/common/js/jquery.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.bgiframe.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.hoverIntent.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.core.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.autocomplete.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.datepicker.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.tabs.js" />
           <fileset dir="${build.dir}" includes="web/common/js/tablesort.js" />
           <fileset dir="${build.dir}" includes="web/common/js/customsort.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.blockUI.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.form.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.ifixpng.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.superfish.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.cluetip.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.scrollTo.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.jqModal.js" />
           <fileset dir="${build.dir}" includes="web/common/js/validation.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.timeentry.js" />
       </concat>
 
       <!-- concatenation of cascading stylesheets -->
       <echo message="Building global cascading stylesheets" />
       <concat destfile="${build.dir}/web/common/css/global.css" force="no">
           <fileset dir="${build.dir}" includes="web/common/css/base.css" />
           <fileset dir="${build.dir}" includes="web/common/css/superfish.css" />
           <fileset dir="${build.dir}" includes="web/common/css/announcements.css" />
           <fileset dir="${build.dir}" includes="web/common/css/myvt.css" />
           <fileset dir="${build.dir}" includes="web/common/css/forms.css" />
           <fileset dir="${build.dir}" includes="web/common/css/cluetip.css" />   
           <fileset dir="${build.dir}" includes="web/common/css/tables.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.tabs.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.datepicker.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.autocomplete.css" />
           <fileset dir="${build.dir}" includes="web/common/css/linkspan.css" />
           <fileset dir="${build.dir}" includes="web/common/css/stepMenu.css" />
           <fileset dir="${build.dir}" includes="web/common/css/print.css" />
           <fileset dir="${build.dir}" includes="web/common/css/youHaveMessages.css" />
       </concat>
 
       <!-- invoke compressor -->
       <yui-compressor warn="false" charset="UTF-8" fromdir="${build.dir}" todir="${build.dir}">
           <include name="web/common/js/global.js" />
           <include name="web/common/css/global.css" />
       </yui-compressor>
 
   </target>
 
   <!--
   * purge-src takes our compressed files, moves them to the base /common dir
   * and deletes the source js and css dirs from the build dir
   -->
   <target name="purge-src" depends="minify">
       <echo message="Purging javascript and stylesheet sources" />
 
       <move file="${build.dir}/web/common/js/global-min.js" tofile="${build.dir}/web/common/global.js"/>
       <move file="${build.dir}/web/common/css/global-min.css" tofile="${build.dir}/web/common/global.css"/>
 
       <delete dir="${build.dir}/web/common/js" />
       <delete dir="${build.dir}/web/common/css" />
 
   </target>

What you see there is essentially four steps.

1. Concatenate all the constituent source files into a global.js and a global.css
2. Compress both of these files, which creates global-min.js and global-min.css (default behavior)
3. Move these files out of the source directories and into the root of the common web directory as global.js and global.css
4. Delete the source directories in our build folder so they don’t get deployed with the web archive

Because certain browsers (IE) break without explicit ordering, we unfortunately can’t just use “*.js” and “*.css” in our concatenation step, but having to explicitly list our components in the build file certainly isn’t the end of the world. The nice thing is that the Ant task will even print out handy statistics on just how much you’ve been able to compress the files down. In our case, we have about 441.8KB of common Javascript and CSS in our source code that, by the time it gets sent to the user, has been minified and/or gzipped to about 89KB.

The Problem

Admissions needed help. They had been moved from their former product, Exeter, to Banner’s native admissions module. But Banner’s interface stinks, and there was no decent way for counselors to do, well, anything. They relied on daily reports run out of an Excel pivot table by the executive directory of admissions, and therefore they lived on paper. The counselors needed a better way to get their work done and stay on top (figuratively speaking) of their recruits.

Enter my department. It fell to us, after some discussion, to build a tool that would be initial for undergraduate counselors, to let them slice and dice their data as needed. After a pilot run, it will gradually be expanded to include graduate and transfer admissions, as well as reporting tools for directors and and other muckity-mucks.

The current iteration is 4808 lines of code, for both the views and the comment submissions servlet. Most of it was written by me, though some was reused code, and the initial servlet skeleton was written by my boss.

Setting Parameters

The first thing an admissions counselor sees is a parameter page. There are a number of options to choose from:

• Term (can be multiple)
• Population selection (e.g. active applicants, active but non-applied recruits, enrolled applicants, etc)
• Student level (can be multiple)
• Recruiter (signed-in counselors will be auto-selected (can be multiple)
• High School (can be multiple)

Selecting from term or student level repopulates the possible recruiter list with only applicable options. Selecting “Undergraduate” applicants will necessarily filter out (or should filter out) graduate admissions counselors so they’re no longer an option.

Perhaps the toughest engineering challenge here was high schools. We currently have ≈10’000 high schools in our database, and will likely have a lot more soon. Loading all those into a multiple select box would make the page huge, and likely overload some underpowered browsers. My solution? Autocomplete. Using a simple JSP fragment and the Autocomplete plugin for jQuery, I was able to make a simple autosearch/complete behavior; selecting an item drops it into a list below the input box.

The odd thing about the plugin was that it didn’t end up being very flexible about the format of returned data. I had figured it would ask you to specify a data type and do your own parsing. It seems, though, that it only wanted one format: pipe-delimited data, with newlines between records. After wrestling with it for a while, I finally got it to work, but I really would have rather just returned XML and done some simple parsing.

The Table View

Once the parameters are chosen, the user gets a very complex table (the specifications were given to us by the Admissions department).

• Name
• Term (if >1 chosen)
• High School (if >1 chosen or none specified)
• Intended major (code display; full description on hover)
• Application decision (e.g. accepted, denied, etc) (code display; full description on hover)
• Student type (e.g. new freshman, transfer, etc)
• Athlete indicator
• Registered indicator
• Application status
  • Green: complete, no pending items
  • Yellow: complete, but pending items which don’t affect admission
  • Red: incomplete: pending items affect admission
  • None (has no application; is only a recruit)
• Financial Aid
  • Green: all items complete, and aid is packaged
  • Yellow: all items complete, but aid is not yet packaged
  • Red: outstanding items; aid cannot be packaged
  • None (has no financial aid)
• Date of application
• Composite admissions score
• Date of last comment (usually a contact with applicant)
• Visited campus indicator (is not currently used)

The recruiter can export this table as an Excel document for easy printing and carrying; otherwise, clicking on a recruit/applicant’s name will bring up a detail screen, which is divided into several sections.

The Detail View

Basic

I call it basic, but this is really the most detailed tab of this entire view.

• Application-related Items
  • Entry Term
  • Source
  • Major
  • Admissions Counselor
  • Application Status
• Biographical Items
  • Banner ID
  • PIN (for helping with portal access)
  • Last Portal login
  • Student Type
  • Advisor (email link)
  • Residence (dorm icon for on-campus, car icon for commuter)
  • College (Education, Arts & Science, etc)
  • Date of Birth
  • Phone Number(s) (shows primary; expands to show others)
  • Email Address(es) (shows primary; expands to show others)
  • Address
• Holds (is only shown when there are holds on the student’s account)
  • Hold Type
  • List of items which this hold prevents
• Education
  • High School (for undergrad and transfer)
    • Name of high school
    • Graduation Date
    • GPA
    • Class rank
    • ACT composite score
  • College (for graduate and transfer)
    • Name of college
    • Dates of attendance
    • GPA transferred
• Athletics (list of sports/activities)

Checklist

The checklist is a simple table displaying pending and completed items necessary for admission. The applicant sees the exact same table when they sign into the portal, so now the counselor can see what the applicant sees.

Mailings/Contacts/Comment

This is a tripartite screen. The first and most important section is “Comments,” which is a sort of chronicle of counselors contacts with the applicant or the applicant’s parents. This screen is especially nasty using the native Banner interface, and so the object was not only to make the viewing nice, but also allow for the deletion, editing, and creation of comments.

Contacts and mailings are merely for records of correspondence the applicant or recruit has received, aggregated from several places.

Financial Aid

This screen gives detail of all awarded financial aid, as well as both completed and outstanding documents. This, too, is almost exactly what the applicant will see when signed into his or her portal.

Bill

This screen, which details charges and payments for the student, is once again a replica of screens available to the applicant when logged in. These screens are mostly to provide parity for support with applicants who have questions about financial aid, bills, or schedules.

Schedule

Once an applicant is accepted, and registers for class, this schedule tab will be filled out. It is a slight modification of the student’s schedule, which is displayed to them upon portal sign-in. Advisor see a similar view, since this is a module we reuse in several different portions of the web app.

The Big Finish

There are always bugs. I realize, just before going live, that the abbr tag that I used so heavily in the tabular view isn’t natively supported by Internet Explorer 6.

Luckily, good old Dean Edwards notes that for some reason, prefixing the namespace to the <abbr> tag makes the damn thing suddenly work, and it’s still valid XHTML! Crisis averted.

As with most of our web application, we make heavy use of jQuery. Specifically for this application, we make use of the UI Tabs plugin, the UI Autocomplete plugin, and jQuery’s native AJAX functionality. We also use the Unobtrusive Tablesort Script from Frequency Decoder, which has much better performance than jQuery equivalents.

As I said, this is only a first try at a first stage, but we’re pretty happy with the progress, and the admissions folks seem to be as well, so we’re doing something right.

I personally think the friendly rivalry between the open-source Webkit engine (which powers Safari, among other things) and Mozilla (the Gecko engine, actually) is one of the best things to happen to browser development in years. The constant one-upsmanship can only lead to better browsers. Well, Internet Explorer will constantly be the limiting factor, but we can dream, can’t we?

The latest thing to hit browser source repos is javascript engine improvement based on something called “trace trees”: essentially, javascript gets translated into native bytecode. The Webkit engine made the announcement a few months ago, with code codenamed “Squirrelfish,” promising massive improvements. That article’s also got a pretty good writeup.

Open Source being what it is, it was only a matter of time before Mozilla announced their own version of a trace-tree-based javascript engine. John Resig has a good writeup, as done Brendan Eich.

So, disregarding for a moment all talk of trace trees and JIT, what the hell does this all mean? I am entirely in agreement with Jeff Atwood about the importance of javascript in the contemporary web. Whether you’re using rich sites like Netflix or GMail, or you’re working with Flash files, or you’re getting into the RIA arena with Flex or similar technologies, you’re essentially relying on javascript and javascript engines to get anything done. Good HTML specs get the browsing experience much of the way there, but a truly compelling web technology relies on client-side scripting. Even in the last 3 or 4 years, javascript has gone from superfluous UI tricks to the heart and soul of the user’s end of a web experience. It’s a bit unfortunate, really, since javascript (properly “ECMAScript”) is an old technology that’s single-threaded and doesn’t scale very well. That browser-makers have managed to squeeze this much performance out of it is a testament to geek creativity.

There’s been a lot of reason to switch away from Internet Explorer in the last few years. Microsoft made big steps with IE7 to improvement performance, rendering quality, and security, but Internet Explorer is still the bastard child of the browser world, dog-ass slow compared to its brethren. If the difference between user experience in the javascript-heavy web becomes so great that a Webkit browser or a Gecko browser or Opera provides an entirely different level of satisfaction, then maybe we’ll finally see a real shift in browser usage.

Mozilla, particularly, is posed to reap some real reward. These JIT trace tree improvements will start showing up in 3.1 (I think), and much more so with the new Tamarin engine schedule for Firefox 4. The only viable Webkit browser in Windows, meanwhile, is Safari, which looks and feels alien in Windows, as Apple has a strange insistence upon keep the OSX look, regardless of platform. I don’t know offhand the market slice that Safari for Windows occupies, but it must be infinitesimally small, even compared to Safari on Mac. Firefox, then, is the only truly compelling browser on the Windows platform to take advantage of this right now.

It’s not a particularly disastrous bug or anything, but I’ve altered the code to check string lengths instead of looking checking for null.

Get it here.

My hypothesis, before performing the tests, was that the 64-bit compilation would have little or no effect on the Javascript engine performance. It’s so difficult to optimize Javascript rendering, which is inherently single-threaded, and it seems likely to only benefit from a faster CPU clock than bigger memory registers. Afterward, I felt vindicated: Internet Explorer is likely the best test, and the difference was not statistically significant. In Firefox’s case, the 64-bit build was actually significantly worse, though this could easily be due to some other factor I have not taken into account; I have assumed that the source was compiled on the same date. See below for more details.

The Data Tables

The Raw Data

Internet Explorer x86 7.0.6001.18000
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  21972.4ms +/- 6.2%
--------------------------------------------

  3d:                    1233.0ms +/- 1.1%
    cube:                 346.6ms +/- 4.7%
    morph:                415.2ms +/- 2.7%
    raytrace:             471.2ms +/- 1.9%

  access:                1834.6ms +/- 2.5%
    binary-trees:         443.0ms +/- 3.9%
    fannkuch:             739.4ms +/- 1.5%
    nbody:                346.4ms +/- 7.3%
    nsieve:               305.8ms +/- 5.8%

  bitops:                1610.0ms +/- 3.7%
    3bit-bits-in-byte:    409.0ms +/- 2.0%
    bits-in-byte:         405.4ms +/- 4.8%
    bitwise-and:          446.2ms +/- 5.0%
    nsieve-bits:          349.4ms +/- 6.3%

  controlflow:            493.0ms +/- 2.2%
    recursive:            493.0ms +/- 2.2%

  crypto:                1051.4ms +/- 4.6%
    aes:                  374.2ms +/- 5.2%
    md5:                  330.8ms +/- 4.9%
    sha1:                 346.4ms +/- 6.2%

  date:                   873.6ms +/- 2.3%
    format-tofte:         433.6ms +/- 2.0%
    format-xparb:         440.0ms +/- 3.7%

  math:                  1186.0ms +/- 1.6%
    cordic:               465.0ms +/- 4.6%
    partial-sums:         327.6ms +/- 0.2%
    spectral-norm:        393.4ms +/- 4.1%

  regexp:                 387.0ms +/- 4.2%
    dna:                  387.0ms +/- 4.2%

  string:               13303.8ms +/- 10.4%
    base64:              7298.0ms +/- 6.8%
    fasta:                464.6ms +/- 3.5%
    tagcloud:            1391.4ms +/- 4.0%
    unpack-code:          461.8ms +/- 3.7%
    validate-input:      3688.0ms +/- 25.4%

Internet Explorer x64
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  19955.4ms +/- 1.2%
--------------------------------------------

  3d:                     938.6ms +/- 2.3%
    cube:                 262.0ms +/- 6.2%
    morph:                311.8ms +/- 6.3%
    raytrace:             364.8ms +/- 2.9%

  access:                1450.6ms +/- 2.8%
    binary-trees:         321.2ms +/- 3.3%
    fannkuch:             586.6ms +/- 3.7%
    nbody:                258.6ms +/- 6.6%
    nsieve:               284.2ms +/- 3.1%

  bitops:                1154.0ms +/- 1.7%
    3bit-bits-in-byte:    290.0ms +/- 3.7%
    bits-in-byte:         290.0ms +/- 7.6%
    bitwise-and:          284.0ms +/- 5.8%
    nsieve-bits:          290.0ms +/- 6.0%

  controlflow:            349.4ms +/- 3.0%
    recursive:            349.4ms +/- 3.0%

  crypto:                 786.2ms +/- 2.8%
    aes:                  296.4ms +/- 4.6%
    md5:                  243.2ms +/- 7.1%
    sha1:                 246.6ms +/- 10.3%

  date:                   664.6ms +/- 6.0%
    format-tofte:         315.0ms +/- 11.6%
    format-xparb:         349.6ms +/- 3.1%

  math:                   845.6ms +/- 2.5%
    cordic:               340.0ms +/- 2.5%
    partial-sums:         228.0ms +/- 4.5%
    spectral-norm:        277.6ms +/- 6.0%

  regexp:                 302.6ms +/- 3.5%
    dna:                  302.6ms +/- 3.5%

  string:               13463.8ms +/- 1.4%
    base64:              8527.2ms +/- 0.9%
    fasta:                334.2ms +/- 5.2%
    tagcloud:            1145.0ms +/- 2.6%
    unpack-code:          346.6ms +/- 6.2%
    validate-input:      3110.8ms +/- 2.4%

Firefox x86 Firefox 3.0b5pre (20080322 nightly)
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 3750.2ms +/- 1.4%
--------------------------------------------

  3d:                   432.8ms +/- 9.8%
    cube:               147.2ms +/- 17.4%
    morph:              137.8ms +/- 1.2%
    raytrace:           147.8ms +/- 22.7%

  access:               598.8ms +/- 2.1%
    binary-trees:        60.6ms +/- 5.5%
    fannkuch:           261.6ms +/- 1.7%
    nbody:              173.2ms +/- 6.0%
    nsieve:             103.4ms +/- 1.4%

  bitops:               493.6ms +/- 5.4%
    3bit-bits-in-byte:   85.6ms +/- 2.2%
    bits-in-byte:       123.0ms +/- 6.4%
    bitwise-and:        136.4ms +/- 11.9%
    nsieve-bits:        148.6ms +/- 9.2%

  controlflow:           57.0ms +/- 3.1%
    recursive:           57.0ms +/- 3.1%

  crypto:               271.4ms +/- 7.3%
    aes:                105.0ms +/- 19.4%
    md5:                 78.4ms +/- 3.8%
    sha1:                88.0ms +/- 2.0%

  date:                 331.4ms +/- 12.3%
    format-tofte:       202.2ms +/- 16.2%
    format-xparb:       129.2ms +/- 8.3%

  math:                 432.2ms +/- 3.9%
    cordic:             186.2ms +/- 7.6%
    partial-sums:       149.2ms +/- 7.0%
    spectral-norm:       96.8ms +/- 1.4%

  regexp:               255.6ms +/- 8.3%
    dna:                255.6ms +/- 8.3%

  string:               877.4ms +/- 4.7%
    base64:             119.2ms +/- 6.0%
    fasta:              205.2ms +/- 10.4%
    tagcloud:           152.2ms +/- 6.2%
    unpack-code:        272.8ms +/- 4.1%
    validate-input:     128.0ms +/- 10.3%

Firefox x64
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  7421.4ms +/- 1.2%
--------------------------------------------

  3d:                    807.8ms +/- 2.0%
    cube:                312.6ms +/- 3.5%
    morph:               230.8ms +/- 7.8%
    raytrace:            264.4ms +/- 6.5%

  access:               1135.0ms +/- 1.9%
    binary-trees:        126.6ms +/- 11.7%
    fannkuch:            540.6ms +/- 2.3%
    nbody:               282.8ms +/- 2.9%
    nsieve:              185.0ms +/- 10.4%

  bitops:               1040.8ms +/- 2.3%
    3bit-bits-in-byte:   213.6ms +/- 5.8%
    bits-in-byte:        271.0ms +/- 4.5%
    bitwise-and:         246.2ms +/- 6.8%
    nsieve-bits:         310.0ms +/- 6.1%

  controlflow:           140.8ms +/- 6.6%
    recursive:           140.8ms +/- 6.6%

  crypto:                533.8ms +/- 4.3%
    aes:                 195.0ms +/- 5.8%
    md5:                 175.2ms +/- 11.5%
    sha1:                163.6ms +/- 3.5%

  date:                  664.6ms +/- 4.5%
    format-tofte:        406.4ms +/- 4.6%
    format-xparb:        258.2ms +/- 6.3%

  math:                  818.8ms +/- 3.8%
    cordic:              367.4ms +/- 3.2%
    partial-sums:        257.2ms +/- 10.5%
    spectral-norm:       194.2ms +/- 4.9%

  regexp:                652.8ms +/- 2.7%
    dna:                 652.8ms +/- 2.7%

  string:               1627.0ms +/- 3.1%
    base64:              220.6ms +/- 4.7%
    fasta:               388.8ms +/- 4.4%
    tagcloud:            294.8ms +/- 5.2%
    unpack-code:         489.4ms +/- 2.9%
    validate-input:      233.4ms +/- 11.1%

Safari 3.1 has been released, bringing with it all the latest and great Webkit code. Even though the UI still sucks (at least on Windows; ever hear of native GUIs, Apple?)

I decided to benchmark the Javascript performance of the new Safari against its more immediate predecessor, 3.04. This testing was done on a Windows XP SP2 installation; a HP workstation with a Pentium 4 and 2GB of RAM.

As you can see in the table below, the JS engine has improved considerably since the last build, cutting the total time by more than half.

Here’s the raw data, if you so desire it.

Safari 3.04

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 13525.2ms +/- 0.6%
--------------------------------------------

  3d:                   1834.4ms +/- 4.8%
    cube:                478.0ms +/- 5.5%
    morph:               818.6ms +/- 8.8%
    raytrace:            537.8ms +/- 6.1%

  access:               2355.8ms +/- 2.1%
    binary-trees:        212.6ms +/- 17.9%
    fannkuch:            977.8ms +/- 1.1%
    nbody:               581.4ms +/- 4.4%
    nsieve:              584.0ms +/- 6.0%

  bitops:               2322.2ms +/- 2.4%
    3bit-bits-in-byte:   515.8ms +/- 2.7%
    bits-in-byte:        537.4ms +/- 5.4%
    bitwise-and:         450.0ms +/- 7.1%
    nsieve-bits:         819.0ms +/- 3.1%

  controlflow:           315.2ms +/- 12.5%
    recursive:           315.2ms +/- 12.5%

  crypto:               1331.2ms +/- 2.2%
    aes:                 337.6ms +/- 8.8%
    md5:                 475.0ms +/- 6.3%
    sha1:                518.6ms +/- 3.2%

  date:                 1062.6ms +/- 5.1%
    format-tofte:        390.6ms +/- 7.0%
    format-xparb:        672.0ms +/- 5.4%

  math:                 1600.2ms +/- 3.3%
    cordic:              847.0ms +/- 3.0%
    partial-sums:        387.6ms +/- 4.2%
    spectral-norm:       365.6ms +/- 9.8%

  regexp:                531.2ms +/- 5.8%
    dna:                 531.2ms +/- 5.8%

  string:               2172.4ms +/- 3.1%
    base64:              453.2ms +/- 6.2%
    fasta:               628.2ms +/- 5.1%
    tagcloud:            340.8ms +/- 11.7%
    unpack-code:         312.6ms +/- 10.7%
    validate-input:      437.6ms +/- 5.4%

Safari 3.1
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  5865.4ms +/- 1.8%
--------------------------------------------

  3d:                    703.0ms +/- 11.3%
    cube:                218.6ms +/- 15.4%
    morph:               197.0ms +/- 22.7%
    raytrace:            287.4ms +/- 10.1%

  access:                943.8ms +/- 7.0%
    binary-trees:        106.4ms +/- 19.8%
    fannkuch:            446.8ms +/- 10.0%
    nbody:               256.4ms +/- 4.2%
    nsieve:              134.2ms +/- 12.8%

  bitops:                659.2ms +/- 4.4%
    3bit-bits-in-byte:   128.0ms +/- 6.5%
    bits-in-byte:        156.2ms +/- 15.3%
    bitwise-and:         212.4ms +/- 13.8%
    nsieve-bits:         162.6ms +/- 16.1%

  controlflow:           146.8ms +/- 17.9%
    recursive:           146.8ms +/- 17.9%

  crypto:                459.6ms +/- 11.7%
    aes:                 175.2ms +/- 21.4%
    md5:                 128.4ms +/- 16.3%
    sha1:                156.0ms +/- 15.1%

  date:                  678.2ms +/- 4.4%
    format-tofte:        262.6ms +/- 12.1%
    format-xparb:        415.6ms +/- 7.1%

  math:                  724.8ms +/- 7.0%
    cordic:              271.8ms +/- 10.7%
    partial-sums:        287.4ms +/- 9.0%
    spectral-norm:       165.6ms +/- 17.7%

  regexp:                334.6ms +/- 7.7%
    dna:                 334.6ms +/- 7.7%

  string:               1215.4ms +/- 4.5%
    base64:              190.4ms +/- 13.3%
    fasta:               290.6ms +/- 8.9%
    tagcloud:            203.2ms +/- 13.4%
    unpack-code:         234.2ms +/- 10.2%
    validate-input:      297.0ms +/- 9.1%

The world of Javascript is an interesting one right now; it seems like most major browsers are on the eve of a major new release, many with new (& improved JS engines). With WebKit’s porting to Windows in Safari (and eventually Konqueror, I imagine), yet another player has thrown his hat into the arena. Javascript is, as Jeff rightly says, the lingua franca of the web: everything is javascript-[based|dependent] today, and rich interfaces are now the norm, rather than a pleasant surprise.

As a web applications developer, I’ve banged by head against javascript and various and sundry browser implementations at work, and worried about performances, both now and in the future. Standardizing on a common library (cf. jQuery) helps, although the performance or functionality of jQuery plugins don’t always match those of home-grown counterparts. For instance, Brian McAllister’s Unobtrusive Table Sort Script far outpaces the popular TableSorter script for jQuery. I ended up implementing the latter at work, simply because of the sheer size of tables we render, and the relative slow speed of many of ours users’ browsers.

Due to time constraints, I hadn’t gotten around to performing my own benchmark until today. I don’t have any fancy (or controversial) graphs like Jeff, but here’s the data anyway, followed by the raw result text. The first table is high-level summaries listing only the sum times for groups of test. The second table lists all the tests.

Somewhat to my surprise, the much-touted improvements to Firefox 3′s javascript engine weren’t consistent across the board. In some cases, it performed worse than 2.0.0.11. The clear winner was Opera’s upcoming 9.5 release (codenamed ‘Kestrel’), followed closely by Apple’s port of the WebKit engine. With respect to the latter, it’s clear that the WebKit/KHTML engine is a good one, though I look forward to an inevitable Konqueror port, since Safari on Windows is just about the ugliest interface I’ve ever seen.

The Results

SunSpider 0.9 Benchmarks
Performed on 15 January 2007
Ben Gunnink | http://heliologue.com/

- Intel Q6600 Quad-Core
- Windows XP SP2 32-bit
- 4GB RAM

All browsers were tested with extensions and plugins disabled.

Firefox 2.0.0.11

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 14032.0ms +/- 2.4%
--------------------------------------------

  3d:                   1909.0ms +/- 4.1%
    cube:                531.4ms +/- 7.6%
    morph:              1078.0ms +/- 3.6%
    raytrace:            299.6ms +/- 10.8%

  access:               1275.0ms +/- 2.3%
    binary-trees:        140.6ms +/- 9.7%
    fannkuch:            422.0ms +/- 0.0%
    nbody:               484.6ms +/- 2.8%
    nsieve:              227.8ms +/- 4.6%

  bitops:               3340.6ms +/- 0.9%
    3bit-bits-in-byte:   253.2ms +/- 3.5%
    bits-in-byte:        256.4ms +/- 4.2%
    bitwise-and:        2459.4ms +/- 0.7%
    nsieve-bits:         371.6ms +/- 4.4%

  controlflow:            94.0ms +/- 0.0%
    recursive:            94.0ms +/- 0.0%

  crypto:                694.4ms +/- 5.2%
    aes:                 215.6ms +/- 7.7%
    md5:                 244.2ms +/- 7.0%
    sha1:                234.6ms +/- 6.0%

  date:                 2049.8ms +/- 0.4%
    format-tofte:        693.8ms +/- 3.1%
    format-xparb:       1356.0ms +/- 1.2%

  math:                 1281.8ms +/- 10.7%
    cordic:              665.8ms +/- 17.3%
    partial-sums:        375.2ms +/- 3.6%
    spectral-norm:       240.8ms +/- 9.2%

  regexp:                784.2ms +/- 5.4%
    dna:                 784.2ms +/- 5.4%

  string:               2603.2ms +/- 7.1%
    base64:              565.8ms +/- 3.8%
    fasta:               415.6ms +/- 4.3%
    tagcloud:            512.4ms +/- 34.7%
    unpack-code:         718.8ms +/- 7.9%
    validate-input:      390.6ms +/- 8.7%

Firefox 3.0.0 beta 2

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 11195.2ms +/- 5.9%
--------------------------------------------

  3d:                   1821.2ms +/- 5.4%
    cube:                543.6ms +/- 12.5%
    morph:               921.8ms +/- 2.2%
    raytrace:            355.8ms +/- 11.9%

  access:               1632.4ms +/- 8.6%
    binary-trees:        160.6ms +/- 34.5%
    fannkuch:            629.2ms +/- 8.5%
    nbody:               568.4ms +/- 6.2%
    nsieve:              274.2ms +/- 13.1%

  bitops:               1759.0ms +/- 6.6%
    3bit-bits-in-byte:   280.8ms +/- 12.8%
    bits-in-byte:        286.0ms +/- 8.8%
    bitwise-and:         808.0ms +/- 5.1%
    nsieve-bits:         384.2ms +/- 9.8%

  controlflow:            93.4ms +/- 27.3%
    recursive:            93.4ms +/- 27.3%

  crypto:                615.6ms +/- 3.2%
    aes:                 276.0ms +/- 6.3%
    md5:                 166.6ms +/- 6.2%
    sha1:                173.0ms +/- 5.5%

  date:                  628.2ms +/- 4.4%
    format-tofte:        409.4ms +/- 3.7%
    format-xparb:        218.8ms +/- 8.1%

  math:                 1121.8ms +/- 3.8%
    cordic:              527.6ms +/- 3.8%
    partial-sums:        383.8ms +/- 4.0%
    spectral-norm:       210.4ms +/- 6.4%

  regexp:                947.0ms +/- 57.3%
    dna:                 947.0ms +/- 57.3%

  string:               2576.6ms +/- 14.3%
    base64:              466.4ms +/- 5.7%
    fasta:               443.2ms +/- 10.0%
    tagcloud:            396.8ms +/- 10.0%
    unpack-code:         942.0ms +/- 35.9%
    validate-input:      328.2ms +/- 8.9%

Internet Explorer 7.0.5730.13

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  26676.8ms +/- 0.8%
--------------------------------------------

  3d:                    1212.8ms +/- 2.4%
    cube:                 334.6ms +/- 5.3%
    morph:                412.4ms +/- 2.6%
    raytrace:             465.8ms +/- 1.8%

  access:                1731.6ms +/- 1.0%
    binary-trees:         409.4ms +/- 2.1%
    fannkuch:             687.6ms +/- 0.1%
    nbody:                343.8ms +/- 0.2%
    nsieve:               290.8ms +/- 3.6%

  bitops:                1552.8ms +/- 1.7%
    3bit-bits-in-byte:    368.8ms +/- 2.9%
    bits-in-byte:         387.2ms +/- 2.2%
    bitwise-and:          450.2ms +/- 1.9%
    nsieve-bits:          346.6ms +/- 2.7%

  controlflow:            447.0ms +/- 2.4%
    recursive:            447.0ms +/- 2.4%

  crypto:                 934.4ms +/- 0.9%
    aes:                  343.6ms +/- 0.2%
    md5:                  297.0ms +/- 0.0%
    sha1:                 293.8ms +/- 3.0%

  date:                   796.6ms +/- 2.9%
    format-tofte:         390.4ms +/- 3.5%
    format-xparb:         406.2ms +/- 3.4%

  math:                  1075.6ms +/- 0.9%
    cordic:               453.6ms +/- 0.2%
    partial-sums:         281.2ms +/- 0.2%
    spectral-norm:        340.8ms +/- 2.6%

  regexp:                 350.0ms +/- 5.0%
    dna:                  350.0ms +/- 5.0%

  string:               18576.0ms +/- 0.9%
    base64:              9212.6ms +/- 0.4%
    fasta:                438.0ms +/- 0.0%
    tagcloud:            1740.6ms +/- 5.7%
    unpack-code:          453.2ms +/- 0.1%
    validate-input:      6731.6ms +/- 1.2%

Safari 3.04 beta

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  8583.4ms +/- 1.7%
--------------------------------------------

  3d:                   1184.4ms +/- 4.6%
    cube:                353.0ms +/- 3.1%
    morph:               490.6ms +/- 5.2%
    raytrace:            340.8ms +/- 6.4%

  access:               1668.2ms +/- 2.5%
    binary-trees:        143.4ms +/- 6.1%
    fannkuch:            703.2ms +/- 0.1%
    nbody:               331.2ms +/- 2.5%
    nsieve:              490.4ms +/- 7.7%

  bitops:               1465.0ms +/- 2.0%
    3bit-bits-in-byte:   302.8ms +/- 5.8%
    bits-in-byte:        387.2ms +/- 2.2%
    bitwise-and:         303.0ms +/- 3.6%
    nsieve-bits:         472.0ms +/- 1.9%

  controlflow:           212.4ms +/- 5.0%
    recursive:           212.4ms +/- 5.0%

  crypto:                815.8ms +/- 3.1%
    aes:                 218.6ms +/- 10.9%
    md5:                 297.0ms +/- 0.0%
    sha1:                300.2ms +/- 3.0%

  date:                  621.8ms +/- 3.5%
    format-tofte:        259.4ms +/- 4.1%
    format-xparb:        362.4ms +/- 4.6%

  math:                 1012.4ms +/- 1.6%
    cordic:              559.4ms +/- 1.5%
    partial-sums:        228.0ms +/- 5.0%
    spectral-norm:       225.0ms +/- 5.0%

  regexp:                337.6ms +/- 3.2%
    dna:                 337.6ms +/- 3.2%

  string:               1265.8ms +/- 2.2%
    base64:              300.0ms +/- 2.8%
    fasta:               297.0ms +/- 4.7%
    tagcloud:            237.6ms +/- 6.8%
    unpack-code:         193.8ms +/- 5.4%
    validate-input:      237.4ms +/- 3.7%

Opera 9.5 beta 1 (build 9613)

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  6501.0ms +/- 1.2%
--------------------------------------------

  3d:                    572.0ms +/- 2.9%
    cube:                162.8ms +/- 6.4%
    morph:               231.2ms +/- 3.7%
    raytrace:            178.0ms +/- 5.7%

  access:                775.4ms +/- 2.8%
    binary-trees:         50.0ms +/- 16.7%
    fannkuch:            365.8ms +/- 2.9%
    nbody:               197.0ms +/- 5.5%
    nsieve:              162.6ms +/- 6.6%

  bitops:                803.2ms +/- 5.6%
    3bit-bits-in-byte:    65.6ms +/- 13.2%
    bits-in-byte:         97.0ms +/- 8.6%
    bitwise-and:         425.0ms +/- 6.0%
    nsieve-bits:         215.6ms +/- 4.1%

  controlflow:            65.6ms +/- 14.2%
    recursive:            65.6ms +/- 14.2%

  crypto:                319.0ms +/- 7.0%
    aes:                 153.0ms +/- 5.9%
    md5:                  81.4ms +/- 10.8%
    sha1:                 84.6ms +/- 12.6%

  date:                  734.2ms +/- 1.9%
    format-tofte:        272.0ms +/- 4.0%
    format-xparb:        462.2ms +/- 3.7%

  math:                  456.0ms +/- 3.4%
    cordic:              197.0ms +/- 5.5%
    partial-sums:        171.8ms +/- 0.3%
    spectral-norm:        87.2ms +/- 12.0%

  regexp:                747.0ms +/- 2.2%
    dna:                 747.0ms +/- 2.2%

  string:               2028.6ms +/- 2.9%
    base64:              140.8ms +/- 10.0%
    fasta:               390.6ms +/- 6.1%
    tagcloud:            365.8ms +/- 8.0%
    unpack-code:         965.6ms +/- 1.7%
    validate-input:      165.8ms +/- 6.4%

Yet, I find myself at home, with a White Russian and the urge to opine.

The Background

In the summer of 2006, my workplace (The University of St. Francis, my alma mater) went live with a portal. For the previous year and half, when I was a student worker, we’d been working desperately to implement Oracle Portal. At a conference that summer, my boss, Tim, heard about uPortal, an open-source J2EE portal. On the ride back from Ohio, we more or less decided to try it on a lark. It’s basic ease of setup let us switch to uPortal and go live in 6 weeks. That’s right, a production-ready portal in 6 weeks.

Much of the work in that time was tying CAS into our LDAP implementation (Novell’s eDirectory), customizing the view (props to Virginia Tech for their excellent Tab-Column customization), and writing some basic portlets to allow quick views into student data: schedule, personal info, billing, &c. We’re a Banner school, so we could basically just reach into our Oracle database and pull the data we needed.

The Cool Bits

Since that time, we’ve poured a tremendous amount of energy into the portal, as it’s become our go-to spot for finding information and getting things done. Actually, we’ve spent very little time on uPortal at all, as it already contains much of the quick-view functionality we want. Much of what we do is a custom extension to the portal that transparently shares session data via CAS.

We have completed our portal rollout using uPortal (running on apache/tomcat), and are integrated with Sungard Banner 7.x for much of the information we pull and display, and we are using Novell E-Directory for our directory.

We used uPortal which proved to be a much more promising and easier to use platform than Oracle portal. Within 6 weeks we had our first production portal deployment. Over the last year we have built and put the following into production:

• Student Schedule and Grades Display (pulled realtime from Banner)
• WebCT Integration/SSO
• Announcements (Targeted coming by end of summer ’07)
• SSO to Novell WebMail, Netstorage, and Banner Self Serve
• Bookstore Integration with Barnes and Noble (Shopping cart of books)
• Financial Aid Portlet/Accept Loans – Display and update banner data
• Tuition Bill Portlet – Pulled in realtime from Banner AR
• Payment of Tuition Bill/Post Directly to Banner AR
• My Profile Portlet (information pulled realtime from Banner)
• GPA/Credit Hours Portlet (Pulled realtime from banner)
• Banner Security Question/Reset Password Functionality
• Expired Password Functionality
• Faculty Schedule/Class Rosters/Email Class, Export to Excel
• Banner Survey Integration
• HR Leave Balances
• Budget Reporting/Financial Activity/View Documents, checks cut, etc
• Banner Requisition Approval
• Web Based University Income/P&L Statement
• Banner Finance Journal Voucher Upload
• PIDM Usage Utility to help identify and resolve duplicate pidms
• EZProxy/Library Databases Integration
• Advancement Constituent Profiles
• Advancement Fundraising Activity Reports
• Advancement Constituent Contacts Data Entry/Reminders
• Financial Aid targeted messages
• GUAMESG
• Residence Life View your Room/Roomates
• Bulletin Boards (phpBB)
• VT Calendar
• Various Web based Reports
• E-Directory Integration/Account Creation
• Early alert and midterm warning submission, that allows the student, advisor, registrar, athletic coaches, and other support staff know when a student is having academic difficulties.
• An online advising center. Advisors can now see all of their advisees, look at who’s registered, view issues with the students account such as registration or medical holds, etc. The goal is so that advisors can also help the students get their issues resolved.
• Our initial stab at targeted announcements is done. We can now target based on the student type, level, or college as currently stored in the Banner ERP, as well as target to only employees or faculty members. The framework is in place to target off of any data element stored in Banner. Now we just need to expand our GUI allowing users to target messages.
• Accounts Receivable Reporting Suite – Our finance office now uses the portal to do various AR reporting tasks, drilling into student details, etc.
• Enrollment/Registration Status Reports – Various members of the university can now easily look at the overall student registration status through the portal.
• A faculty attendance tracking module for faculty to electronically submit the attendance of students in their classes at the beginning of term and at the mid-term point. This helps the registrar and financial aid determine who is actually attending, and replaces an old paper based process.
• On online Student Check-In procedure. Students can now confirm their class schedules, financial aid, and pay their bill through an easy to use “wizard” interface. The system will notify when they need to perform the electronic check in process before the start of the term, and then walks them through the process. This helps to collect payments sooner and determine which students are actually going to show up to class on day 1.
• Our portal now has a targeted messaging facility which looks at business rules and notifies the students of issues or action items related to their student records. For example, if a student has holds on their account the system will tell them, show them the hold, tell them what it prevents them from doing, and who to contact to resolve the hold. For students with incomplete medical records they are notified, and shown which parts of their medical records are incomplete (and for our nursing program, which shots, etc they need to have on file to be able to attend clinicals).
• A co-curricular transcript which pulls from Banner all the clubs, organizations, and sports a student has been a member of during their time at the university, and shows them in a nicely formatted page that they can print.
• A real-time registration status dashboard for administrators, deans, and faculty members. This dashboard now shows the head counts, course registration counts, credit hours, and billing hours generated for registered students, and the number of potential students who are left to register. It breaks the summary counts down in several ways: by college, major, advisor, or level (graduate, undergrad, etc). The users can drill into this report and extract lists of students who still need to get registered, whom to call to see if they need advising help or assistance registering, etc.

As the UI architect for the portal extension, I decided this past summer to standardise on jQuery, and certainly haven’t regretted it. The only bad thing about javascript is that it becomes easy to rely on it for things which should really be controlled server-side. Important validation checks, for instance. Since our ERP system has certain business logic which it enforces on the database level, we usually do two checks for important data: one (javascript) for the user’s sake, and one (servlet) for ours.

It got to the point where we were loading 10 different jQuery javascripts and 2 stylesheets in our header. Most of the javascripts were either packed or uncompressed (if packing broke them), and totaled about 200Kb. Not only was this too much, but the eval() caused a delay for each script. Recently, after one of our rollouts to production, when I got more leeway to play, I completely upgraded our script layout. I’m not going to provide an apples-to-apples comparison table here, since the prior configuration was a hodgepodge, but after minifying and turning on server-side compression for javascripts and stylesheets, I managed to reduce the load from 200Kb in 12 requests to about 50Kb in 5 requests. According to Julien Lecomte, running mod_deflate on a minified (but no obfuscated) javascript yields the lowest file size; regardless of how often that’s true, I like the idea of avoid latency from the eval(). A lot of our users are still on IE6, and they take some pretty big performance hits.

Goodness knows there’s more I could do, but given the nature of our portal (single-image CSS layouts, anyone?), it wouldn’t be a productive use of our time); I have enough crap to do with counting pixels.

jQuery rocks my socks

I might take a moment here to say just how much I love jQuery. For those of you who don’t know, jQuery is a javascript framework which abstracts a lot of functions into a much more easily-written manner. In the past, I’ve sort of been a Copy & Paste javascript programmer, since it’s been easier to use some free script than to write one’s own code. jQuery and it’s vast array (har!) of plugins makes it easy to implement or write new code. For instance, if we want to implement a support for CSS hover effects in IE, all we do is this:

$("input:text,input:password,textarea").focus(function() {
     $(this).addClass("focused");
});
 
$("input:text,input:password,textarea").blur(function() {
     $(this).removeClass("focused");
});

Easy as pie.

Granted, there are a lot of frameworks to choose from. Originally, there was only Prototype; now there’s also jQuery, Dojo, YUI, Mootools, Rico, and any one of a number of others.

The one I wanted to talk about in this post in particular is ExtJS, which was originally an extension of the YUI framework, but which eventually split off into its own project. It recently went 2.0, and boasts some rather impressive demos. I marvel at the Vista-like UI, which, admittedly, is very slick.

But the more I look at ExtJS, and half-heartedly consider its possible deployment within our portal, the less enthused I become. ExtJS’s grid, for instance, doesn’t even function on existing HTML table markup: you mass it an array of data as a javascript variable, and it creates markup on the fly… a lot of markup, in order to create it’s slick Office 2007 interface. While this is good insofar as it manages to completely abstract data from presentation, I’m not sure how much I like the idea, since it (1) relegates users to the script default without heavy customization, and (2) doesn’t allow for any kind of fallback mechanism if the javascript should fail or the user has it disabled. Our table-sorting function, in a case like that, doesn’t at all prevent the table markup and data itself from being rendered.

Work can be fun sometimes.

Just for grins, I’ve worked that snippet of code up into a genuine jQuery plugin. Go ahead and visit the page for more information. Or, download it directly.

MIT license.