I saw a post on Ajaxian about how iPhone 3.0 might now include SquirrelFish Extreme so I did a quick and dirty using this. Here’s are the results (raw spreadsheet here).
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 😉
Just came across the ajaxian post about smushit.com which was presented at The Ajax Experience by Stoyan Stefanov and Nicole Sullivan. It’s a nifty tool that optimizes images on any web page you pass it by using doing lossless compression or stripping out image meta tags.
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!
The recent javascript vm wars harken back to the video card wars of the early 2000’s where 3dfx, ATI, and NVIDIA where trading blows. Instead of we have Google, WebKit, and Mozilla trading blows by releasing a faster and faster vm at what seems like a weekly rate.
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
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.
After reading about the new JavaScript VM in Google Chrome (called V8) I was wondering how it would stack up against the new JS engines from Mozilla (TraceMonkey) and WebKit (SquirrelFish). I ran 3 tests across all the browsers, including IE8, and here are the results.
Setup:
Click continue for results and charts…
Continue…
I just installed the ShareThis button on this blog so I cracked open the javascript payload. You can view it here. In short, it’s horrific! It pains me to see this because this is a widget which means this code is running a million times a day!
First, let’s get some basics out of the way.
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. =|
I had the pleasure of attending the first Javascript SF meetup at the Hi5 offices a couple days ago. It was a rather large turn out with some great demos. The main themes of the night were Canvas and Javascript frameworks to develop desktop apps. A few thoughts on the talks:
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.
PPK, of quriksmode.org fame, has been busy updating his events compatibility table and has uncovered some interesting bugs in the mousemove event.
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.
The first Acid test was essentially to test browser compatibility for the box model. The Acid2 (try it out in the browser you’re on, Safari3 passes btw) test focused on HTML/CSS for static content.
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.)
Some things that have been spinning around in my head that don’t deserve a whole post…
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.
Yesterday, the jQuery team released their jQuery UI library which brings much needed UI components to an already stellar AJAX framework. Many developers love jQuery because of it’s simplicity and ability to get shit done quickly. It’s not an overly bloated library (read: Dojo 0.4) and it’s wick fast. So why would you want to use jQuery UI over say other frameworks like Ext JS or script.aculo.us? Well here’s my top 5 reasons to use this new framework, plus 3 reasons to avoid it.
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!)
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.
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.
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.
I saw this ‘secret, leaked’ tech demo (click to view demo) link on Digg today for a new social network called i’m in like with you. First of all, there’s no way that this link was leaked, more than likely this is a viral campaign. Second of all, domains names are even rarer than I thought, come on, iminlikewithyou.com? Why not letsgettoknoweachotherovertheinternet.com? These guys are from a YCombinator class earlier this year and have already secured their Series A. Still, I wasn’t expecting much.
I watched most of the demo and, surprisingly, the site is probably one of the best looking sites I’ve seen around. Dynamic content everywhere, visually appealing, strong bold colors, and very functional.
After sitting through 5 mins of Katamari Damacy music, I was curious whether or not the entire thing was in flash or only parts of it. I signed up with ‘invite’ code at the end, NYTM. (The invite code states first 100 people. LIES. I was still able to use it and I’m sure more than a 100 people have used the code already.)
It turns out that most of the site is not in flash, but a good portion of the site is using AJAX. I would have to say they’re using Ruby on Rails (and consequently prototype/scriptaculous). Very impressive.
As for the features of the site, they have a few unique ideas. The main one is that they’ve taken the Hot or Not model and expounded on it. When you first sign up, you aren’t allowed to contact anybody but you do get 700 points. Points are used to win games. Anybody can start a game, which is really just a question, and you bid on a game by giving short answer. The more people that bid, the more points are used. At the end of the game, the creator then picks a winner of the top 5 bidders, and then creator and winner can freely talk.
You can earn more points in various ways. One of the early examples I saw was answering simple yes or no questions. This is valuable data that can be used to better advertiser to the user, or even for simple demographical information.
The entire site is centered around these games and winning them to further expand your network. The games are designed to keep you on the site for a long long time (or at least have the page open). They’ve also included basic IM services, custom videos section, and instant notifications in the form of Growl-like notifications. On top of that, they’re turning the flirting game (no pun) on it’s head. The creator of the game, most likely women, will be the ones that decide on who they talk too. No more random messages from random people ala MySpace or Facebook.
Overall, a well designed social network even though this is the early stages. With the numerous social networking site popping up in the wake of Facebook and MySpace I wish these guys all the luck. It’ll be tough to break through, but at least they can say they have the best looking social site around. 🙂
I maybe way behind on this and I’m not sure how I haven’t encountered this little quirk in javascript until now but apparently the onmouseover (and subsequently onmouseout) event fires repeatedly at unexpected times. For example if you add an event to a <div> that encompasses child elements, every time you pass over a child element you the onmouseover and onmouseout event fire sequentially.
This makes your onmouseover event handler execute many many many more times than you’d expect. Click here for an example for this in action. To get around this little nuisance of javascript you have to check if the event happens within the parent element and filter these out.
I’m currently in love with the Ext JS framework (and have been since Jack first published it on this blog) so the following solution is based on that framework. But other frameworks have similar event handling functions.
var div = Ext.get('divId');
var over = function(e, el, divId) {
// within returns whether or not event
// appears in this parent element.
if(!e.within(Ext.get('divId'), true)) {
doStuff();
}
};
div.on('mouseover', over, this, 'divId');
The iPhone has been great for mobile, it’s given a full browser to the mobile world. Except for one thing, it’s Safari, which can be good and bad. It’s good for example if you’re developing an app for iPhone, you have one browser to test and develop against. It’s bad because it’s Safari, not known to be the best of browsers.
At AdMob, I’m responsible for developing the javascript ad code for our iPhone specific code. Recently we’ve been experiencing odd behavior on sites where the ad code would simply not run. We finally narrowed it down to the fact that sites were setting content type as application/xhtml+xml. When Safari is in this mode it doesn’t like you doing such things as document.createElement(‘div’) or eL.innerHTML = ‘<div>text<div>’ or even eL.innerHTML = ‘text’; all of which are normal dhtml techniques.
Instead it expects you to use document.createElementNS and document.createTextNode which are the proper way to add XHTML elements. So I ended up having to rewrite our entire iPhone javascript code and a simple nifty utility function. 🙂
var createElement = function(type, props, styles) {
var d = document.createElementNS('http://www.w3.org/1999/xhtml', 'html:' + type);
for(var i in props)
d[i] = props[i];
for(var i in styles)
d.style[i] = styles[i];
return d;
};
// usage
eL.appendChild(createElement('div', { id : 'divId' },
{ float : 'left', width : 100px' }));
My current gig is at AdMob and we recently re-did the home page and took out a small little widget that had a live scrolling ticker of actual ad requests. When we redesigned the home page there just wasn’t room for it anymore. A lot of people were sad to see it go. Except now we’ve brought it back in full force! We’ve even been mentioned on TechCrunch! (A little dream of mine for a while, not because I like Arrington or anything, but because it’s the 4th largest blog.) Here’s my original post on our company’s website.
AdMob AdMonitor
Technical stuff:
The page is a combination of Google Maps, YUI, Ext JS, Fusion Gadgets, and our own internal API. The prototype was thrown together in a couple hours and then design, marketing, and our CEO Omar got involved and it evolved into what you see today. The joys of working at a fast paced company, I love it! 🙂