Zepto vs jQuery for Mobile

jQuery is the most popular js library by a long shot, and likewise jQuery Mobile is shaping up to be a great layer on top of that for mobile.  Comparatively Zepto is much smaller, has a smaller API and is still at version 0.8.  So why would we use Zepto?  First off, zepto is smaller. It’s goal is to stay in the 5 to 10k range. Bandwidth is a much bigger issue on mobile.

One of the things that’s made jQuery so popular is it’s cross browser support, going back to ie6. This is also a big part of the codebase and something Zepto has chosen to pare down.  The same browsers aren’t needed for mobile.  Since mobile is predominately webkit anyway, you can just progressively enhance for that.  If you’re packaging up an app for ios or android this makes sense as well.

Another great thing about Zepto is that it shares syntax with jQuery. The same methods work for both. This leads to a fast learning curve, but more than that.  You can start a project in Zepto.  If the device requirements change to support windows mobile or you need to use some of the jQuery only methods you can just swap out Zepto for jQuery and your code should essentially work, with only a few exceptions. In conclusion, you should give Zepto a try, but be ready to switch.

Issue with $(document).ready() on jquery mobile

One of the first things a developer learns with jQuery is the use of the document.ready function.  It’s a good place to initialize your scripts well before all of the images are loaded in the onload event. A  jQuery mobile site on the other hand works differently.  It’s a single page application, meaning that each of the screenviews aren’t individual “pages” in the traditional sense, but multiple screenviews loaded into the DOM at once.  It’s what allows jQuery mobile it’s fancy and responsive transitions.  It’s a nice feature, but where do we initialize our scripts? Well, we put them in the pageinit event like this.

$( '#myPage' ).live( 'pageinit',function(event){
alert( 'This page was just enhanced by jQuery Mobile!' );
});

The #myPage selector is for a specific page. If you want your pageinit globally use the ‘div[data-role=”page”]’ selector. To bind make sure you use the .live instead of the .bind method. This will insure all future pages that haven’t been created yet get the bind as well.  Prior to the beta 2 version we used the pagecreate event instead of pageinit. A change was made in that version to bind jQuery mobile’s widgets with the pagecreate event. Pageinit comes after the widgets have been initialized so it will typically be the one you want. If you’d rather call a script before the widgets you should use the pagebeforecreate event. The pagecreate should rarely be used.  The only reason I could think of using it, is if you’re trying to create your own widgets for the framework.

Simplifying vs Complicating Performance Optimization

Simplifying your code for performance can and should be done throughout development. Complicating your code for performance should only be done after profiling has been done and bottlenecks have been identified.

During the entire development process it’s good to constantly refactor.  Reducing all extra steps and other cruft in a programs logic can not only improve performance but it makes your code more readable and decreases file size.  Reducing it to it’s poetic essence isn’t what the Knuth was talking about when he said “Premature optimization is the root of all evil.”

Once the code is working and perfomance analysis is done (I use dynatrace), certain bottlenecks appear.  Optimizing these issues sometimes requires complicating your code in order for it to perform better.  Here are some examples from a nice post by Doug Avery.  Replacing jQuery with native javascript can take out extra executions in a heavily trafficked loop but at the cost of increasing your code and making it less readable.  That’s why it’s critical that you only do this complicating type of optimization after performance analysis has been done and bottlenecks identified.

Using Landing Pages to Improve Performance

The landing page, that simple inviting page that beckons the user to explore.  It gives a taste of what’s to come and it builds up to what’s behind the curtain.  The calming simplicity tells the user to brace yourself for the site you’re about to view.  Their are several UX reasons for having one, but they also offer an opportunity to greatly improve your site’s performance. Here are two ways:

preloading files

measuring speed for future consideration