There is a ton of tricks LinkedIn employed to optimize their webapp. Check out their blog for a ton of ideas: http://engineering.linkedin.com/mobile/
What I think they failed at, is not releasing their code open source. Then the community would have helped them find the memory leaks and other edge cases.
true, infinite scrolling and footer do not work together, unless footer is position:fixed, which is often the case on mobile. Infinite scrolling is pretty much the norm on mobile and is increasingly popular on desktop, pinterest and twitter are examples.
I have found only a couple of libraries that attempt some of the techniques used by LinkedIn team. One is [infinity.js](http://airbnb.github.io/infinity/) by airbnb but it is specific to pinterest-style masonry layouts, and another is [swipeview.js](http://cubiq.org/swipeview) by Matteo Spinelli, the great guy who created iscroll.js. We are using swipeview in [Urbini](http://github.com/urbien/urbini) but it is not good enough, scrolling is terribly slow. It is possible that it is some problem in interaction between jquery mobile and swipeview, so we are investigating it, but anyway swipeview is not even close to what LinkedIn guys have created. I know Sencha guys have a similar technique, [Infinite List Component](www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story) but we do not want to use Sencha as it has terrible cross-browser support compared to JQM.
SwipeView is pretty good but not good enough for large scale front end application. Also, SwipeView (at the time when I looked at it) required all of the data upfront v/s letting the app pull it via a webservice. If you're looking for more info on how LinkedIn achieved the buttery performance, you might want to look into http://www.youtube.com/watch?v=ft9R72R7TlI
@trunalb, am I right that this was you on stage in the video's first part, and then answering questions? Is it possible to share the code that avoids highlighting list items during scrolling? We have this exact problem.
thx @trunalb, good find, will check out the video later (man, it is an hour long).
I pretty much understand all LinkedIn techniques. Just lack the time to implement them and support this code for various environments. Ideally this is what JQM team should have provided as a replacement for their barebones and very tricky to use listview widget. Good scrolling/swiping performance is impossible on mobile without managing a sliding window in DOM, like good old editors used to do with files that did not fit into memory.
omg, you did? I see that you used the sliding window with 3 parts. The closest pages are left as is. Then next set use the technique #1 unloading images. Then the next set of pages use technique #2 hiding pages, while the rest of the pages use technique #3 removing pages. Why not just use #3? Is there a speed advantage to still having around the pages with the fake image and the pages with visibility hidden?
Out of this resentment I and a couple friends set out to build an MVC system where newbies start with the models (backbone.js) by creating them on a smartphone using only their browser. And once you are done, the app goes live. See it at http://urbien.com and its open sourced client at http://github.com/urbien/urbini
Laying out the main concepts of your future app, and connecting them is not easy for noobs. Hack, even for developers sometimes it is a bit of a puzzle. You need to scratch your head a couple of times when you make the domain model for a new app. But at least this is all you need to do to get the app running with our system.
Afterwards you can start tinkering and tweaking, by changing themes, images, modifying the underlying templates (HTML) in-place, and connecting apps IFTTT-style, with a tiny plug script.
Would you like to review and may be even help us make the design friendly to geeks-who-can't-code?
As mentioned by other posters, Rails, Grails and Django all do the job to a certain extend, the hardest part being to gen the UI that is generic enough, yet flexible. Man, hard is not the right word, it is insanely difficult to achieve this goal.
That said, this is what our team set out to do. We just released on github the full client for a new type of CRUD app generator http://github.com/urbien/urbini focused on mobile web apps. Cloud backend is not open source, but is free to use.
Developer creates a Model in Web UI on the phone, tablet or a modern desktop browser, and the app prototype is done. Backbone.js models are generated and are sent to the browser when you point it to your app.
Model definitions, templates, views, css, images are saved to appcache and LocalStorage and the data for models are saved to IndexedDB/WebSQL and are automatically synced with the server in background via CRUD. Is that what you had in mind?
1. for debugging minified JS we tried to use source maps, but they were not supported (I have to say that Chrome claims to support it but it is working intermittently). So our fallback today is to serve non-minified to developers (based on a cookie) and minified to the rest of the world. The drawback is that users may report JS exceptions with the line numbers which are different from what developers would see.
2. for mobile I need FF to let my webaps compete with native apps. Mozilla is changing the game on mobile with webapis to devices https://wiki.mozilla.org/WebAPI, you guys are the saviors! We have been waiting for the ability to write device interfacing webapps since 2008! Our team is on the way with an MVC framework that utilizes device webapis, see http://github.com/urbien/urbini. But one critical thing is missing - Firefox needs to start as a service on device boot, and webapps should be able to register JS callbacks in this service. It does not need to include a rendering engine, but webapp should be able to spawn full browser. Without this we can't write proximity-based social apps, a bump-like app for business cards, network aware db sync engine, etc. To continue this line of thinking, it is not always devices that you need your webapp to communicate with. Sometimes it is Android intents. Like the intents defined by pebble watch service http://developer.getpebble.com/