Wayne Pan

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.

• 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. =|

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.

I’ve been developing a small app using Google’s AppEngine. My first impression is that developing in the sandboxed python environment forces you to KISS. The SDK makes things dead simple in terms of templating, data access, and controlling which scripts map to which urls.

The side affect of abstracting the data access layer is that I no longer have to spend much time with database schema. That’s because AppEngine doesn’t run a traditional relational database and doesn’t allow you to run traditional SQL against the data store. I end up writing horribly un-optimized ‘queries’ because I’m not able to write highly optimized SQL queries. The SDK is obviously geared to take full advantage of the instant look up and high throughput that BigTable excels at.

For example, for these 2 objects:

class Attribute(db.Model):
  author = db.UserProperty()
  content = db.StringProperty(multiline=True)
  date = db.DateTimeProperty(auto_now_add=True)

class UserAttribute(db.Model):
  attribute_key = db.ReferenceProperty(Attribute)
  user = db.UserProperty()
  date = db.DateTimeProperty(auto_now_add=True)

I can access all the Attributes that belong to the User with the following code:

    query = db.Query(UserAttribute)
    user_attributes = query.filter('user =', \
      users.get_current_user())
    attributes = [ua.attribute_key for ua in user_attributes]

I’ll keep updating as I dig into the SDK.

Russell Beattie’s Mowser is shutting down and boy is he bitter.

… the general answer is that I don’t actually believe in the “Mobile Web” anymore, and therefore am less inclined to spend time and effort in a market I think is limited at best, and dying at worst.
…
In other words, I think anyone currently developing sites using XHTML-MP markup, no Javascript, geared towards cellular connections and two inch screens are simply wasting their time, and I’m tired of wasting my time.

According to AdMob metrics mobile web usage is far from dying. A trend you do see is that people who have internet enabled devices and all you can eat data plans are using the mobile web more and more. The main issue with current carriers is the confusing pricing for data plans. Do you know how much it would cost you browse the web?

I know for a fact that users with two inch screens regularly get online with their cell phones. There is a certain carrier, who we’ll call Carrier M, who bundles unlimited data with their plans but only offers very basic phones (no smartphones/iPhones). Customers of Carrier M make up a large amount of traffic on AdMob’s network disproportional to Carrier M’s market share.

I also believe that better browsers will eventually become the standard for mobile browsing. iPhone, Android, LiMo are all going to offer phones with WebKit. But at the same time there will still be mobile specific sites (see all the iPhone specific versions of webpages out there).

As for Russell’s rant, I just think he’s blowing off steam. I applaud anybody who takes the huge risk of trying to start their own company. I wish him the best of luck and hope he doesn’t give up on mobile.

Simply watch the video above.. This is the first iPhone app I’ve seen that takes advantage of it’s unique abilities. Imagine this game with OTA multiplayer built in! I’m a sucker for good puzzlers so I just might have to pick up the non-existent iPhone 3g.

Tonight Google releases Google App Engine and TechCrunch.com has the coverage.

The biggest news is that App Engine is free to use up to a certain amount, like all other Google developer services. (As I previously postulated.) Pricing after the free period has yet to be determined.

Applications cannot use more than 500 MB of total storage, 200 million megacycles/day CPU time, and 10 GB bandwidth (both ways) per day.  

The downside is that all the apps have to be written in Python. It’s a language that’s not as popular as PHP or as chic as Ruby but has been proven to scale and seems to be getting traction again as django matures.

I, for one, would love to be getting back into Python but Google App Engine won’t be a home run until they offer it in true services style. Any language and piecemeal. For example, as I read it, I can’t use BigTable and GFS for my self-hosted PHP application. Undoubtedly, this will eventually happen. I can also see Amazon firing back making portions of AWS free for small users.

Update: HighScalability.com has a good technical overview of GAE’s sandboxed python environment.

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.

Dave Winer offers a compelling reason on why Google would offer it’s Web Services (AWS competitor) for free. (That is if they actually release one like I predicted for this year.)

The basic premise is that if GWS were free, Google could reap the benefits of having a whole heap of developers tied into their platform. After which acquiring a company would be much less cheaper if they’re already tied into the Google cloud. I can see Google making a move like this for the normal user but they would eventually have to charge for larger customers. After all they already provide 6.5 gb of storage space for gmail users but providing unlimited GWS usage is a hit not even the mighty Google can take.

As most everybody knows by now the IE team will increase IE8’s concurrent connections to 6 (from 2). Now there are rumblings that the next FF3 beta will follow suit and increase the default to 6.The HTTP/1.1 standard recommends 2 which at the time made sense.

In the world of broadband, limiting connections per host to 2 makes little sense. Us fronteers have been forced to do subdomain hacks, css sprites, etc to deal with this. I’m psyched.

Steve Souders also has a good wrap up along trying to answer the question of will this break the internet?

The YUI 2nd Birthday was a dud except for the free shirts, free food, free beer, oh and something about YUI 3.0. The vision plan they have for 3.0 is faster, lighter, more secure, more modular.The front of the shirt is above but the back of the shirt has the quote “This is Yahoo!” and I agree.

Yahoo! has done wonders in terms of front-end engineering with YUI, Design Patterns, YSlow, Juku, and even hiring someone full time for firebug. They are bringing much needed attention web dev and the continued promotion of javascript as a first class language.

On a side note, when I read the “This is Yahoo!” slogan I imagined Jerry Yang kicking Balmer into an endless pit and yelling “THIS IS YAHOO!” 300 style.