4 ms·

A few issues with this article. First, if jQuery is censored in the app bundle, it could be 500k and it wouldn't matter. 500k isn't big for an app. Second, ont

A few issues with this article. First, if jQuery is censored in the app bundle, it could be 500k and it wouldn't matter. 500k isn't big for an app. Second, ontouchstart is a tricky game. It's wonderfully fast, but breaks scrolling completely if you start scrolling from an ontouchstart-bound element. Basically, it's a shortcut around learning Objective-C. You get a lot of quick wins, but the end product isn't quite as good - except if you're doing something unusual, like one-page apps with no scrolling. I find it's good for prototyping.

sintaxi 14y ago
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.
- elliottkember 14y ago
  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.
- eli 14y ago
  Seems mostly academic, no? Do you think fewer people will download a 1.4MB app versus a 1.2MB app?
- deleted 14y ago
  [deleted]
  - deleted 14y ago
    [deleted]
- cageface 14y ago
  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.
ahrjay 14y ago
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.
eli 14y ago
jQuery Mobile already handles taps and swipes for you: http://jquerymobile.com/test/docs/api/events.html http://jquerymobile.com/test/docs/api/events.html
apike 14y ago
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.
- joemoon 14y ago
  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.

sintaxi 14y ago

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.

elliottkember 14y ago
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.
eli 14y ago
Seems mostly academic, no? Do you think fewer people will download a 1.4MB app versus a 1.2MB app?
deleted 14y ago
[deleted]
- deleted 14y ago
  [deleted]
cageface 14y ago
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.

ahrjay 14y ago

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.

eli 14y ago

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

apike 14y ago

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.

joemoon 14y ago
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.