Hacker News Reader

Comment by pamelafox | Hacker News Reader

After measuring the loading performance of my PhoneGap app and seeing that jQuery took 800ms to load (even when cached), I spent the last few days porting from jQuery to Zepto, which boasts a similar API but loads in only 300ms. You can see the load times here: https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDd... (You can see how I did the measurements in this post: http://www.everyday.im/learning/phonegap-loading-performance...)

While porting 6 jQuery plugins over, I encountered various differences in the APIs and it was a bit of a headache to sort through them (especially the very subtle differences), but it was worth it.I'm writing a blog post currently on my porting experience, as I imagine others might take on the task and encounter similar issues.

For people comparing Zepto to this offering, keep in mind that Zepto also offers mobile-specific events, so if your reason for porting is mobile latency, Zepto's a good bet.

View on HN

Update: I've now written the post about porting from jQuery to Zepto which includes my workarounds for missing jQuery functionality. If you're thinking of porting from jQuery, it should give you a good idea of what sort of stuff you'll run into: http://www.everyday.im/learning/porting-jquery-to-zepto.html

Users stay on a website for more than 800ms.

Wouldn't it be more cost effective (rather than convert/port a whole site to a new js lib) to rewrite your page init JavaScript so it does not require a js lib at all (0ms)? Jquery would be async loaded by the time the user executes actions/buttons; if it had not loaded yet you wait, or show a loading icon, etc.

This porting/optimization adds no value to your users 6 months from now who are running a quad core nexus-razr-droid's browser that loads jquery in 300ms.

Good point. For my particular app/use case, the user quickly opens the app, uses the camera, then closes the app and moves on -- which is why I'm optimizing load time. But even for that case, that technique is a great suggestion, and probably what I should have tried first. I'll try it next. :)

Moore's law is applied differently to mobile phones, as processing power is less important than battery life. And even if phones will get a lot more powerful, that's secondary to poor bandwidth, a problem that I bet we'll still have 4 years from now.

I use jQuery because it makes Javascript usage sane. Without it I would hate my job.

Have a play with CofffeeScript - perhaps it'll give you enough syntactic sugar that client-side frameworks become unnecessary.

CoffeeScript only takes care of syntax problems. It doesn't handle DOM traversing or other API related issues.

I thought is was worth mentioning, that the Google Closure Libary has quite an interesting approach to this. They use the Closure compiler to handle it. First of all only the pieces of code that are actually used are compiled into the final javascript file. You can also set compile flags in case you only want to target specific browsers, like mobile webkit, which will reduce code size even further.

Use LabJS [1] or a similar library to load both CSS and JS in async, not blocking the loading of other assets.

Edit: Sorry, I misread that you're talking about parsing time. LabJS helps only with the loading time. Does it really take so long to parse? That's not negligible.

[1] http://labjs.com/

> so if your reason for porting is mobile latency, Zepto's a good bet.

Unless you want to be compatible with WP7's IE9/IE10 or mobile Opera browsers of course, since Zepto is webkit only (for a phonegap app it probably does not matter).

I've had a very similar experience recently porting from JQuery to Zepto. The difference in load time is dramatic, even loading the js locally from the device file system.

Reply on news.ycombinator.com