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

I just got an invite from TripIt.com. Well, it was through TripIt.com, from my buddy Dave. When the invitation arrived it not only had a link, but it had a username (my email address) and password already in the email. Wow. The cost to click the link and join their social network was much smaller than sites where I know I’m going to be skating around forms for half an hour to get setup *cough* hotmail *cough*.

TripIt.com got it right. Now I just have to look for opportunities to use this same style, which I find QUITE inviting.

I was reading at Unclutterer and they linked to a Radio Shack Ad on YouTube. As the commercial played I was able to see what looked like Audacity. Sure enough, once I zoomed in and paused the player at the right time they’re using the open source software to show a large, high quality wave pattern on the laptop display.

Check out audacity, its good, free software and it runs under Windows, Linux & OS X – I have it installed under all three OSes.

I dabble in the world of philosophy at times and one of the philosophical movements that I don’t participate in, but find interesting is existentialism. Experience is all that there is doesn’t suit me, but in the world of software development experience is all that there is.

1. Does your software do what it says it can do?
2. Does your software do that in a way that is simple?
3. Does your software do it in a visually attractive way?
4. Does your software do it in a way that is memorable?

For some folks these questions aren’t critical, but they help. I personally love to use certain pieces of software because they deliver on the promised goods, they’re simple, they’re attractive and most of all I remember them when I’m talking with others about software they may want to purchase. It isn’t grassroot software advertising that makes software catch on, its software that is designed well that brings about grassroot advertising.