Yesterday I listened to Scott Hanselman and Jeff Atwood discussing Website Optimization on Hanselminutes and Scott asked Jeff why external JavaScript files should be compressed for speed and performance of web sites and web applications.  One thing that Jeff didn’t answer with that I think is worth noting is that the YUI compressor that Jeff uses – and which I use – happens to have the Java-based Rhino JavaScript engine in it.  The YUI compressor basically reads in your JavaScript file, parses it with a JavaScript engine and then outputs optimized code that will allow (almost?) all JavaScript engines in different browsers to parse and execute your JavaScript code faster than it would have had you not run the code through the YUI compressor.  Here are a few tidbits explained:

• The YUI compressor doesn’t require you to pre-validate your code with tools like JSlint, which are nice, but not very friendly for beginner or pressed-for-time developers.  The JSlint site puts it well: JSLint will hurt your feelings.  I can deal with some hurt feelings myself, but managing browser quirks like IE’s inconsistent handling of ‘==’ verses ‘===’ means JSLint isn’t as handy as it could be for large files with lots of comparison operations.  I like well written code.  No.  I love well written code.  Not all code shoppes have time for syntax evaluation – if it works they’ll ship it – and YUI Compressor works great for this situation.  You can use the ‘-v’ parameter when executing the compressor at the command prompt to have it output any hints or suggestions for better syntax or potential errors.
• The compressor optimizes functions and classes by managing variable instantiation and reducing the number of places in the code where this sort of memory allocation has to happen so that the beginning of the function contains all variable instantiations and your code can then execute without extra overhead for inline instantiations (especially if someone made the bonehead move of instantiating a variable in a loop!).
• The compressor creates files that have no comments in them so JavaScript parsers  can parse a file that has been parsed and then output by a parser in parser optimized form.  The output code has a whole lot less fluff and generally looks like what a parser would hope a file would look like.  To make a comparison that would be like me taking my thoughts, putting them into a brain just like yours, having that brain output the words perfectly so that you could read them and understand them without any questions and the fewest number of possible words.  Its a JavaScript communications breakthrough.
• The YUI Compressor can also be integrated with a build script so that your build engine (such as Ant or Nant) could automate the creation of the compressed or optimized files.

I have personally found the YUI Compressor to be invaluable and it has helped improve the loading time of the web applications that I work on substantially.  Being able to tell users (and the sales channel) that the slower loading web application has been improved to load 27% less data (while adding features) almost two years ago was a major win.  Watching their faces as I demonstrated how much faster the code was was icing on the cake.

Does everyone need to use the YUI compressor for every project?  Maybe not.  But I believe that it is probably the best tool available at this time to help professional web application developers to squeeze out that extra bit of performance without hand-tweaking code that could otherwise be thousands of lines of code to evaluate.  I have more performance optimizations I will find, I’m sure, but using YUI Compressor is a no-brainer and I hope you’ll find it gives you peace of mind and mind blowing performance improvements when it comes to file download sizes and speeds.

I’m a huge fan of learning new things (and I like to think that you are, too):

My buddy Dave O’Hara sent me this link: 7 Rules of Unobtusive JavaScript. A good overview of why you should be coding unobtrusively (which I do in as many cases as possible) and also explains some good things about namespacing and object access.

I’m trying to learn about TDD and JavaScript which has been a bit harder than I expected: we need more of this in the JavaScript community!  Here’s a bit over at the Ajaxian on doing TDD with JsMock.

It wasn’t until the recent flurry of the guardfather of web standards, Jeffrey Zeldman, and his posts about HTML 5 (see: In Defense of Web Developers, HTML 5 Nav Ambiguity, HTML 5 Is A Mess, and so forth) that I began looking into HTML 5.  I’m busy being pragmatic with my code today and making tough choices about browser support and figuring out how I can make HTML 4.01 work consistently in those browsers that I do support.  But with the promise of change coming I need to be on the hunt for details rather than waiting for the browsers to fully implement the spec.  If we wait for browsers to fully implement specs it could very well be after I’m out of the web development industry before they’re implemented.  I wish that last line were a funny joke, but sadly 100% implementation is not likely in the next few years because the spec isn’t complete.  The reason that the spec isn’t complete is because people on both sides of a bunch of arguments have been making assumptions.  Lets take a look at those assumptions, shall we?

Assumption 1: The Needs of the Web Are or Are Not Going To Be The Same in ‘N’ Years

I love this assumption either direction you take it. Its awesome if it stays the same because then we can clean up our markup so that WordPress 4.0 (or your blogging platform of choice) can have 16 elements repeated over and over.  We won’t have table nesting issues, we won’t have DIV-itis, we’ll have semantically pure documents.  Or not.  Because as long as we’re using the Sliding Door technique or any number of other hacks to get markup to map to CSS (note: the spec will change for this technology, too) we’ll be polluting the DOM.  Also, if the web will change: how will it change?  Assuming that we can create “The Perfect” markup language in HTML 5 is naive at best and possibly stupid at worst.  What did we need in HTML, JavaScript and CSS before the iPhone, Table PCs and the user interface in “Minority Report”?  Assuming that the human interface to data on the web and elsewhere will remain stagnant is flawed horribly.  If we ever get HTML 5 out the door, we’ll get HTML 6 out the door some decades after that (or HTML will die and we’ll move to some other markup format).  What if we’re closer to Matrix-like data input than we think and you stop taking in the web through what you consider a browser?

Assumption 2: We Need More or Less Markup Elements

There are great arguments for newer or different markup elements.  There are great arguments for using the old ones and just styling them with CSS.  There are great arguments but many of them have, on some core level, more assumptions.  Arguments for newer elements are valid for present web contents if you are looking for semantic markup.  If you take the negative view (and assumption) that there will be no really powerful algorithm in your lifetime that can really, truly process semantic markup then this is a voided argument and you move on.  The assumption and expectation trumps the ideal nature of semantic markup.  You will make no headway here.  If you assume that semantic markup will lead to better programs to parse the data then what you’re really looking for is XML + some sort of namespace and doctype information that will help computers parse the data beyond what the browser is doing.  Microformats help in this area, but are not complete enough to make all documents data fully parsable.  Also, if you’re talking about web standards I should not that data synchronization standards are diverse and incomplete in most implementations as well.

We may need less markup if we can style the div and span elements however we want.  Or so you may think.  That sort of thinking is based on the assumption that all markup is basically the same with different styling.  An oversimplification for sure, but I’ve found that oversimplification makes life easier, and so myself and others are often caught doing it here, there, or in other places we don’t talk about in polite company.  Its the Internet, so we do it publicly, but on sites that anonymize our usage, of course.  Hacks make Internet Explorer bugs more bearable, Firefox bugs less annoying, Opera work like every other browser, and Safari and Chrome like Internet Explorer (or not).

The Rise of the Pragmatist

I like to fancy myself a pragmatist.  It doesn’t buy me anything, but I can pretend that I’m practical, which is nice when someone asks you to do something and you don’t have an unlimited amount of time or money.  I don’t have time to wait for all of HTML 5 to be implemented.  I don’t have time for the web to catch up with desktop software of the 80’s and 90’s that had option/select/text entry elements that allowed the user to input any type of text, but also choose from some pre-populated options.  I don’t have time for the web to allow my DIV-itis to look much prettier when presented in a hierarchical tree-like structure.  I need markup that works now.  HTML 5 will be a step in the right direction, but it will be slowly implemented in ways we don’t know yet and we’ll see what happens.  If the Canvas element replaces Adobe Flash and SVG replaces VML: I’ll cheer.  If I don’t ever get to use either of those elements or technologies because the implementers of those technologies never get off their collective backsides within the walls of various browser vendors then I’ll be practical about what I do.  I’m going to make several assumptions about the future – as the above statements reveal.  I believe that the web will change through JavaScript and CSS libraries and hacks.  I believe that HTML standards will come, and I think that just like HTML 3, HTML 4 will one day be old.  I’m going to assume that practical software development is all about satisfying the demands of your boss, your client, or yourself with what you can do now.

But you wouldn’t be a pragmatist if you didn’t also believe that you could practically bring about resolution and change for HTML 5, HTML 6 or HTML 7.  Practical change.  Good change.  The things you discover you needed from HTML 5 that its purveyors could not foresee.  Keep pushing for better web standards, but don’t keep fighting for better web standards.  The fighting causes delay, the fighting isn’t pragmatic, and the fighting doesn’t clean up the web, it worsens it.  Data wants to be free, do your part to continue to free it.  I’m going to start by reading through the proposed HTML 5 specs to see what I’ll be up against in Internet Explorer 9.5 – whenever that comes out.

In the world of browser performance you can find yourself looking for the little things to make big differences, or even a lot of little things to make a bigger difference together.  I’ve been researching one particular change that is coming down the pike: native JSON handling.  John Resig wrote about the need for native JSON support in the browser in 2007 and its finally come.  The difference it makes between Firefox 3.0 and 3.5 is major, the difference between Internet Explorer 7 and 8 is important, and the safety that native support brings for prevention of cross site scripting (XSS) is critical.

I’ve created two tests that you can try for yourself: the eval test and the JSON test.  The tests loop 20 times to give you a broader test range and reveal the average time.  There are notes in the test pages to clarify a few observations, but I’ll put them here just for the sake of a single source.  The test pulls in 1600 JSON objects and either evaluates them using the JavaScript eval function (eval(/*JSON String*/);), or it parses them with the native JSON parser (JSON.parse(/*JSON String*/)).  For consistency’s sake I used the data from John Resig’s test which I have copied onto my server to reduce the load on his server and not steal bandwidth.  My tests were run locally to reduce bandwidth latency influencing results, but you can see that over the Internet, even on a broadband connection, the performance only gets worse.

Firefox 3.5 has javascript tracing enabled and the typical test results will show a much slower first pass with subsequent results being much, much faster. It should never be assumed that the user will be getting the exact same data back like this test shows, so the slower performance should be expected.

Internet Explorer 8’s Eval test appears to be almost as fast as the JSON test and their eval code’s execution is pretty fast already. However, the JSON.parse() code appears to be much safer to use and is thus preferable.

The final results are based on the averages (which are much more consistent than comparing the ‘best’ numbers): eval is roughly 500 milliseconds (or 500%) slower in Firefox 3.5 the first time and nearly the same speed in Internet Explorer 8 with an average of 10 seconds slower in 20 passes.  So for either identical or much faster performance and greater safety against XSS it is a no-brainer to switch to including native JSON support as a preferred method of dealing with JSON data over eval.

I do want to note that I was impressed by Internet Explorer 8’s eval speed, it was much greater than I had expected, and generally disappointed with Firefox’s, but since it is an evil function to use, that’s not all bad.

I fully understand why Internet Explorer 7 uses clear type. Some people’s eyes work better with ClearType. It is simply an accessibility nightmare in my humble opinion. Actually, the problem is not in the ClearType – which works better on some displays than others – but it is in the Internet Explorer ‘Advanced Options’ dialog. If you’re a glutton for punishment take a glance at it [click on the screenshot below for a larger version].

As a designer please use consistent text to give users the simplicity of vocabulary.  If all of the options use enable or disable rather than both, this will help.  Worse is the ClearType option which says, “Use…”  that’s neither enable or disable and it makes the scanning of the text even more frustrating because its even more words your brain has to parse as you scan over the text.  If you design interfaces – please consider being consistent.  I have some software I need to update to take this into account, but please – all new software should be written with greatest usability in mind, and all older software should really be updated.

The Advanced Options Tab in Internet Explorer 7