I've repeatedly seen HTML5+JS claimed as some kind of panacea for easy, cross-platform application development, but don't really see how it is possible, particularly on mobile devices.
Both the Android and iOS SDKs are pretty specifically optimized for performance on their respective devices, and I don't see the need for those types of optimizations going away anytime soon. As an example, take a UITableView (iOS) or ListView (Android), backed by a SQLite data store that has returned 2000 rows to display.
It's not actually feasible (for performance & memory reasons) to simply render all 2000 rows and allow the user to scroll through them. Instead, both the UITableView & ListView recognize that on a phone, there's only really enough room to display 5-6 rows anyway. So they instantiate those 5-6 rows and populate them with the first few rows from the result set. Then, as the user scrolls down, additional rows can be loaded in, and the previously used rows (that have now been scrolled off-screen) get recycled to represent new rows at the bottom of the table view. Additionally, the data for each row can be loaded on-demand as the user scrolls the row into view, and then be freed once that row has scrolled off screen.
It's a nice and tidy optimization that is absolutely necessary on both platforms (failure to implement the recycling mechanism can basically kill your scrolling performance). That is just one example, there are many more optimizations developers make to keep their apps smooth and responsive on iOS/Android, and a lot of those optimizations involve relatively low-level interaction with the underlying GUI toolkit.
I don't think these types of optimizations are feasible when writing HTML+JS apps, they're simply abstracted too far away from the underlying GUI toolkit. (Some might even say that layer of abstraction is the entire point of using HTML+JS in the first place.) Regardless, I think it severely limits the scope of the types of apps you can create using HTML+JS.
And I haven't even mentioned games, or apps that do any sort of audio/image/video processing. (Even on the web these are often relegated to Flash.)
This scrolling trickery is absolutely doable in html/js. A friend of mine wrote an infinite-scroll table that will handily display tables of tens of thousands of rows. It carefully only requests the right data from the server (with lots of cacheing and prefetching, of course) and only ever instantiates 2*n (n being the number of rows visible) dom elements and just pops them in and out of view.
I think what you are saying that is correct is: UI developers as a general rule do not go to this level of detail, either on web or on native.
But on native, the frameworks have already done these kinds of optimizations for us. I think that's just a matter of the SDKs having more manpower and motivation for making it easy to build apps on their platform.
I actually have a semi-related project right now, so I'm going to go write a Backbone collection smart-scroll plugin that deals with the smart data loading and clever element rejiggering. Thanks for the suggestion.
So as one data point in this comparison, I have a pretty good version of a scrolling grid plugin that swaps in and out existing row dom elements as needed and loads that data dynamically from a backend. It's not totally done and not ready to open-source, but it's generic enough that another day or so of work will make it so.
HN records that my original comment was posted 21 hours ago, and I assure you I spent a good deal of time sleeping and eating inbetween, so this is definitely doable in html/js.
Now, as to the bigger point, that most developers don't know that they should do this to get performance, or that we shouldn't have to write it ourselves, those still stand.
Good point, html5 has some catching up to do here but I think it's possible, at least on JIT'd js environments, to achieve the same performance. Can.js has one of the best performing UI code right now and can do the lazy loading, live binding patterns you're talking about http://canjs.us/
It's absolutely doable in HTML+Js - I've written a TableView in GWT that utilizes the exact same principle and was actually inspired by Cocoa's TableView API. It could render thousands of rows (or however many) utilizing only a few actual divs.
Why do you think this isn't doable in HTML+JS? Seems rather trivial to me. IndexedDB will cover the pagination of large data sets, and removing DOM elements that are out of view is commonly done already.
Both the Android and iOS SDKs are pretty specifically optimized for performance on their respective devices, and I don't see the need for those types of optimizations going away anytime soon. As an example, take a UITableView (iOS) or ListView (Android), backed by a SQLite data store that has returned 2000 rows to display.
It's not actually feasible (for performance & memory reasons) to simply render all 2000 rows and allow the user to scroll through them. Instead, both the UITableView & ListView recognize that on a phone, there's only really enough room to display 5-6 rows anyway. So they instantiate those 5-6 rows and populate them with the first few rows from the result set. Then, as the user scrolls down, additional rows can be loaded in, and the previously used rows (that have now been scrolled off-screen) get recycled to represent new rows at the bottom of the table view. Additionally, the data for each row can be loaded on-demand as the user scrolls the row into view, and then be freed once that row has scrolled off screen.
It's a nice and tidy optimization that is absolutely necessary on both platforms (failure to implement the recycling mechanism can basically kill your scrolling performance). That is just one example, there are many more optimizations developers make to keep their apps smooth and responsive on iOS/Android, and a lot of those optimizations involve relatively low-level interaction with the underlying GUI toolkit.
I don't think these types of optimizations are feasible when writing HTML+JS apps, they're simply abstracted too far away from the underlying GUI toolkit. (Some might even say that layer of abstraction is the entire point of using HTML+JS in the first place.) Regardless, I think it severely limits the scope of the types of apps you can create using HTML+JS.
And I haven't even mentioned games, or apps that do any sort of audio/image/video processing. (Even on the web these are often relegated to Flash.)