iPhone 3.0 definitely has something, (whether it’s SquirrelFish or Nitro), but it’s 3x-10x faster than iPhone 2.2.

Update: Dear Apple, if this is against the NDA shoot me an email waynepan at me dot com

I had a little fun with this tool running it on Google.com and Yahoo.com. (Just ignore any png compatibility issues and caching while you read the following… )

Google.com has 1 image and SmushIt reports it can be compressed 507 bytes (5.92% savings!) by converting it to a png. Assuming a very conservative 200 million requests a month on google.com alone that’s a savings of … if my math is correct … 100 gigs of bandwidth!

Yahoo.com could save even more, 8310 bytes (12.04% savings). Using the same numbers above that’s 1,547 gigs of bandwidth in the US alone!

Yesterday WebKit’s latest salvo is SquirrelFish Extreme. After chuckling a bit at the name, I decided to run it through the same benchmarks as I ran Chrome through.

WebKit-r36647

• Dromaeo – 7067.20ms (this is what used to be v2.dromaeo.com
• SunSpider – 1562.0ms
• V8 Benchmark – 720

If you take a look at the previous results you’ll notice that the new SquirrelFish Extreme (SFX) preforms significantly better than Chrome or FF in their own benchmark, SunSpider. It comes within 363 points in the V8 Benchmark tests. Also it holds relatively steady in the dom head tests for Dromaeo.

All and all, SFX isn’t hardly ready for prime time and it appears that the WebKit team is making significant progress.

Setup:

• Chrome [Build 1583 - 0.2.149.27]
• FireFox 3.1 Nightly [1.9.1b1pre/200809020331]
  - w/ javascript.options.jit.* set to true except in the SunSpider tests, where jit.content was set to false because it crashes.
• WebKit Nightly [r36012]
• Internet Explorer 8 [IE8 v8.0.6001.18241]
  - I doubt numbers are accurate, asked me once for Chrome tests if I wanted to stop the unresponsive script, about 50x for Dromaeo
• Windows XP SP3, AMD Athlon 64 X2 3800+, 2GB RAM
• Restart each browser after every test
• SunSpider, V8 BenchMark, Dromaeo

Click continue for results and charts…

• Chrome – 610.6ms
• WebKit – 1948.00ms
• FireFox – 1688.20ms
• IE8 – 9827.60ms

Bigger the Better

• Chrome – 1083
• WebKit – 191
• FireFox – 106
• IE8 – 42

• Chrome – 2846.8ms
• WebKit – 4105.0ms
• FireFox – 11427.2ms
• IE8 – 11427.2ms

Needless to say, Chrome’s V8 blows away all the current builds of the next-generation of JavaScript VMs. Just to be clear, WebKit and FireFox engines haven’t even hit beta, but it looks like the performance bar has just been set to an astronomical height by the V8 Team.

Update: Brendan has has posted new TraceMonkey favorable benchmarks with the latest TraceMonkey build vs V8. A little friendly competition is awesome but since all these projects are open source the community is the real winner here.

Also I downloaded the latest trunk build of FireFox [1.9.1b1pre/20080903034741] and re-ran the tests:

• SunSpider – 2124.2ms
• Dromaeo – 1736.6ms
• Chrome Tests – 113

The latest build is definitely optimized for the SunSpider test, even beating V8. However, it still lags behind in Dromaeo and the Chrome Tests. (The V8 team optimized the engine specifically for the Chrome Test so it’s very biased.)

Update 2: Apparently Resig has been working on a v2 of Dromaeo that includes a lot more DOM manipulation tests.

• Chrome – 10800.8ms
• WebKit – 6456.6ms
• FireFox – 10119.8ms
• IE8 – DNF (Too many “slow script” interruptions)

Chrome and FireFox are evenly matched here. WebKit comes out on top…

Also, being the JavaScript ninja that he is, John Resig has a much better write up on the topic than I.

First, let’s get some basics out of the way.

• Comments and white-spaces are left in the code, increasing the payload size. I suggest using YUI Compressor before posting the code.
• Lines 1-3 – MooTools is included at the top of the script, PACKED. Thanks to PB Wiki’s Tests, we now know this is bad for client side performance. Stop doing this, see above!
• Lines 3-12 – They’ve included the FireBug Lite code to account for the 5 occurrences where they use console. Remove the 5 debug statements that don’t do squat and you can shave off ~350 bytes

Doing the above netted a 6940 bytes savings or a script 65% the size of the original (not to mention the client side cycles shaved off by removing the packed mootools). Click the link below to view it.

13048 Apr 21 00:17 sharethis_widget_better.js
19988 Apr 21 00:18 sharethis_widget_original.js

Digging into the code further I found a lot of various space saving things that could be done in the code (using radix in parseInt, avoiding at least one try catch block 83-89, etc). Also a few oddities like lines 329 – 332 (which looks like a bug), just asking for trouble by using _s in the global space, and wtf is going on with lines 460-464? Declaring _query to be [] then passing it to the ShareThis object, which from what I can tell doesn’t do anything, then setting the query property again to _query (which is really []) and then pointlessly setting a variable st to the newly created ShareThis.

I know I’m guilty of writing bad javascript also, but if you’re a company distributing a widget you should at least clean up the code a tad… ironically the ShareThis widget appears immediately after this line. =|

First up was SproutCore presented by Charles Jolley which is what I would imagine if Javascript and Ruby on Rails had a love child together. The basic premise is to allow you to develop desktop type apps with javascript and ruby. The best part of the app is the build system which merges all your javascript and css, even spriting your images.

After SproutCore, Douglas Crockford came to pimp his new book JavaScript: The Good Parts. Ajaxian joked that it would be a 2-pager at most but Crockford said it would easily the densest book about javascript (weighing in 120 pages). A quote from the book:

Most programming languages contain good and bad parts, but JavaScript has more than its share of the bad, having been developed and released in a hurry before it could be refined. This authoritative book scrapes away these bad features to reveal a subset of JavaScript that’s more reliable, readable, and maintainable than the language as a whole-a subset you can use to create truly extensible and efficient code.

I’ll definitely be picking this one up.

Somebody (I don’t recall who) mentioned flotr, a javascript charting library. It’s been around for a while but this is the first I’ve looked at it. There are definite benefits in doing charting in canvas versus flash but my worry is IE6 and 7 support. Even though IE 6/7 are supported through ExCanvas, I still don’t feel comfortable with the landscape.

Easily the best presso of the night was from the 280 North founders showing off not only their upcoming app 280 Slides but the framework that it is built on. Ross Boucher and crew asked the folks to keep the wraps on what was shown at the meetup so I won’t delve into it much more. All I can say is the app is far superior to any of the current online slideshow offerings out there right now. It basically looked and functioned (very speedily too!) like a normal desktop application. The framework which has been in development for over 2 years is unlike anything out right now. I’m not sold on it yet but they stated that their plan is to open source it so I’m looking forward to getting my hands on it when they do.

By far the funniest moment of the night was when Yehuda Katz was demoing ruby-spidermonkey. Right before he showed an example using ‘with’, he turns to Crockford and says “Sorry Doug”. The entire room started laughing which meant everybody in attendance was a bonafide javascript geek. Awesome.

When doing my new mousemove test I found a bug in IE5-7 that I was previously unaware of. When the user moves the mouse over the element, the mousemove event fires many times, as it should. However, when the user stops moving the mouse, IE5-7 continues firing the event every once in a while. This stops only when the mouse leaves the target element entirely.This is obviously a bug: when the mouse does not move the mousemove event should not fire.  

On top of that he’s stating that the bug has been copied by the Safari and Opera team. I think it has less to do with the browser implementations with more with operating system oddities.

For example, OS X Firefox 2 mousemove events are triggered when Firefox is brought back into focus (using cmd-tab, no mouse movement). However, on Windows XP sp2 Firefox does not display the same behavior! You can say this is a bug for Firefox’s mousemove event implementation or you can push that on the operating system for sending a mousemove event to firefox itself. Six in one hand, half dozen in the other.

Also interestingly, Safari 3 on OS X, the mousemove events are fired every time a key is depressed and then released! On Windows XPsp2 IE6, the mousemove events are triggered anytime the screen is redrawn. You can all sorts of fun yourself with PPK’s test page.

The bottom line is that if you happen to attach logic to the mousemove event just make sure it’s safe to call multiple times.

Now Acid3 is being developed and will focus on the dynamic portion of the web, ie javascript. Finally, an Acid test I can get behind! The other Acid tests merely pointed out inconstancies in very edge cases of css and html rendering; not very useful. Acid3 ensures that javascript code written adheres to the ECMAScript spec, which is much more important in my mind.

John Resig has a good summary of the draft along with renders of the test in different browsers. (Many more here.)

There was a good post on Ajaxian on the subject of unobtrusive javascript. It points to an outstanding article written by Christian Heilmann called The seven rules of Unobtrusive JavaScript. I understand unobtrusive javascript, what it means, and the reasons why it’s needed. However, there are a few times when it’s just not practical. For example, if your application heavily depends on javascript then having a hard rule to always use unobtrusive javascript doesn’t make much sense.

You can actually gain a few things doing the opposite like performance and even save developing time. (See the video posted on yuiblog.com – Joseph Smarr: “High-Performance JavaScript: Why Everything You’ve Been Taught is Wrong”)

Naturally, it’s best practice to use unobtrusive whenever possible, but when pragmatic enough I can see both sides of the coin.

For all you designers out there, Style Ignite has a very nice article about tracking the web 2.0 trend of horizontally divided pages. Out of those samples, I like Wishlistr.com the best.

Normally I read John Dvorak’s column with a grain of salt (I mean when you make a thousand outrageous predictions, you’re bound to strike gold once in a while), but he had an interesting thing to say about the GooglePhone that puts things into perspective.

People have had eons to program for the Windows smartphones and nothing has come of it. What’s so different now?

Puts the whole OHA/Android thing into perspective doesn’t it.

5 Reasons to Use jQuery UI

1. Stick with One Library
   The obvious reason for using jQuery UI is that you’re already using jQuery. Now you won’t have to bring in another library to satisfy your UI needs. You can take advantage of all the widgets and interaction tools that jQuery UI supports without having to maintain and learn another library. Not that mixing libraries is a bad thing, you can definitely use multiple libraries in one project and cherry picking the best components out of each.
2. Excellent Documentation
   I’ve always liked jQuery for the excellent documentation they provide. Not only is it up to date but it’s also cleanly organized. Each function/component has a full explanation and an example + source code. The most frustrating thing when using a library is not being able to find information. The whole point to use a library is to make development easier and good documentation definitely helps.

   Just compare the jQuery docs to Dojo docs (which is actually down as of this writing) to script.aculo.us docs to mootools to mochikit. (Don’t look at YUI or Ext JS, their docs are great!)

3. Magnifier
   
   Not a new effect, but definitely the easiest way to get this effect on your page. See the example here. In one line of javascript you have your very own OS X dock widget!
4. Selectables
   
   I haven’t used them all, but I’ve seen very few libraries that have a component that lets you select items like this in javascript. Check out the demo here. Draw a box around the list items to select them. Now more impressively hit control and select items while skipping others. Awesome.
5. Themes
   One part of AJAX is beautifying the web and with the upcoming themes competition for jQuery, there should be plenty of themes available. My one knock against most libraries is that there’s not enough variation in the way the widgets look so one Dojo or Ext JS site starts looks like every other. Redoing themes requires a lot of resources (and talents that AJAX developers usually do not have) so most developers end up picking one of the existing themes.

3 Reasons to Avoid jQuery UI

1. Doesn’t Support All Browsers Yet
   Granted this is a brand new project and they warn you ahead of time in their launch announcement, but so far I’ve tested Safari, IE6, IE7, and Konquerer. There are various bug in each and on different components. For example the gallery demo doesn’t render properly in Safari or Konquerer.

   The Shadow demo fails in IE6. There have been reported issues with the tablesorter in IE7. The point of using an AJAX library is to abstract the browser layer, but if certain components don’t work on certain browsers, there’s a problem.

2. Missing Widgets, Ranged Calendar Date Picker
   I know I’m being picky, but the calendar widget doesn’t do date ranges. You can get around this, but at first glance I don’t see an option where I can set a min/max date. Compared to the YUI calendar widget, the options are sparse here. If you’ve ever done any decent amount of web work, you’ll know that a good calendaring widget is essential.

   Update: Okay, I missed the plethora of options available in the Calendaring widget. Thanks to Marc Grabanski, calendaring widget developer, for pointing me to a more robust demo which shows that it’s configurable than I had first thought. It definitely does do date ranges.

   My original point was that jQuery is still missing a few UI widgets; common ones such as a tree widget and a menu widget and lesser used ones such as a WYSIWYG or autocomplete. I don’t doubt that these things will come as the library matures but they’re not in the current release.

3. Inconsistency in the API
   jQuery was done by a team of contributors, each doing their own components and it shows. For example, the accordion control is essentially the same thing functionally to the tab control. Yet the activate a tab programmatically the call is tabsClick() while the accordion control is activate(). The tab control also has many more hooks such as disable, remove, add, etc… the accordion control has none of this functionality.

The jQuery UI library definitely has some high points, but I think it was launched a bit too early. The depth of existing AJAX frameworks simply outshines it. However, as it matures, I’m positive the team will keep up the high quality that has made jQuery massively popular.