The problem is absolutely not about initial download, but rather about runtime performance. Parsing and executing 500k of JavaScript on mobile is crazy slow, and it blocks the whole app while this is happening. You can mitigate this by loading the JS on demand, but you still need to pay the cost at some point. For the time being, the best approach is to only include what JavaScript you absolutely need.

I just want to echo want apike is saying. There are several comments here incorrectly stating that this much javascript doesn't matter. It seems pretty obvious that those commenters have no experience developing mobile web apps. Loading jquery is a huge hit, taking anywhere from .5s to 1.5s to initialize, depending on the device and what else is eating up resources at load time.

It's a footprint issue, not latency. A 94k jQuery file comes at a price and 99% of that codebase never gets hit for an application like this.

That's not a big footprint for an app, especially compared with image assets, app code and CSS bundled alongside.

It also means being able to add more functionality at will without having to rebundle, or worse, work on basic functionality helpers. Just seems like wasted time for such a small improvement. These devices were built to have application code on them.

Seems mostly academic, no? Do you think fewer people will download a 1.4MB app versus a 1.2MB app?

Zepto is 24k. Does that extra 70k really make that big of a difference? A single retina resolution png is going to be bigger than that. I think there are other reasons to consider a library that's tailored for mobile webkit but size doesn't seem like a dealbreaker.

The ontouchstart issue can be avoided by using the ontouchmove/end to check of the user is scrolling. Infact zepto.js has a custom event called "tap" which does exactly that.

jQuery Mobile already handles taps and swipes for you: http://jquerymobile.com/test/docs/api/events.html