toddparker
commented
13 years ago @ora726 - No offense, we appreciate the feedback. We do take performance seriously, and we understand on some older devices, page performance may not be as good as we'd like right now if you have a complex page like yours may be. Performance falls into a few broad categories that we're already tracking closely on the project:
- Startup/Initialization time
- Page loading
- Page enhancement time
- Page transition performance
- Touch responsiveness
- Scrolling smoothness
- Memory use
Of these, we've made good progress on memory use through our DOM cache feature and have been doing a lot of optimizations to speed up page enhancement time this week by hunting around for places to reduce function calls (more details to follow on the blog post for 1.0).
Other issues, like touch responsiveness and scrolling smoothness are very complex issues to solve. The quirkiness of how touch and mouse events are dispatched by various platforms is very hard to normalize, with Android being a particularly buggy. We've tried to re-approach these events a few times but we've convcluded that any changes to the event system will be too disruptive to attempt for 1.0 so these will be a priority for 1.1.
Transition smoothness is being addressed in two ways. First, we've introduced the touchOverflowEnabled feature to take advantage of iOS5's support of overflow: properties for smooth transitions and fixed headers. We're working with browser makers to focus on supporting overflow: and we should see movement on that soon. This feature is off be default as we work through refining this since iOS5 was just released but we see this is the future. For older and less capable devices, we're starting to think about creating new transition types that look better within the constraints of our supported browsers and these will be part of a larger transition re-factor for 1.1.
Lastly, there are some things that we just can't detect at the moment, including hardware horsepower and connection speed, that would help us better target functionality. Right now, there are some older devices that pass our support tests and qualify for the enhanced experience, but may be somewhat pokey at running JS or rendering CSS. Ideally, we'd be able to detect that these devices are struggling and downgrade them to the C grade experience, but there really isn't a good way to measure performance this way and we're not willing to wade into dealing with user agent detection because that is unsustainable.
In general, if you keep pages pretty lightweight performance will be acceptable on most devices (old Android 1.5 devices are a clear exception). In the case of your PhoneGap app, you do have a much bigger DOM because your whole app is stuffed into a single page so I can understand that could cause issues if things are complex. It seems that there would be ways to pull content in as needed to reduce memory use, but I can't speak to specifics here.
I'm going to close this issue because it's sort of a catch all that is covered elsewhere, but I assure you that this is a priority for us to continue refining as we move into the next release.
Cheers, Todd
Hi all, Not sure if this is the place for a general Performance debate, so please let me know if I should post this somewhere else. I have developed my app with jquery mobile and have done most of the testing on my desktop with occasional tests on an iphone 3GS. I did develop on JQM on the premisses that the performance hits I was having where due to the fact that JQM was in Alpha, then Beta, then RC now. While worried by the performances on the Iphone 3GS I got really alarmed 2 weeks ago when for the first time I had an opportunity to run the app on an Android stock device, in this case a Wildfire, which is not the fanciest and fasted device around, but a good representation of the mid performance devices on sale today. The performances where terrible, events would take so much time to fire up that they where missed entirely and the application was simply made useless. I have no pretense of having written the best and most efficient application and am sure that better programmers could do better than I did, and I understand that you are trying the impossible by covering the widest choice of devices, and I think that the project is doing well, but the performance subject seem to be left for later and I think this strategy could deal a blow to the project and undermine it's credibility.
Please understand that I am really not trying to criticize the efforts being done, they are great and this project came out of nowhere at an incredible speed, but the limitations of the systems used today must be acknowledged and the expectations of programmers that have committed to this project and have many months of work in the balance must be tempered. I was surprised to see the number of people looking for performance improvements in JQM on sites such as phonegap, Dreamwaver, stackoverflow, I spent considerable time reading trough all this posts and making tests to no avail, the application responsiveness is at best usable on an Iphone 3GS and get to unusable on any inferior hardware even when simply navigating JQM pages without any additional javascript code running in the background.
I think that it is very important for the project to address this concerns now as the consequences of not doing so would be a lack of credibility that could cripple this great project future.
Possible things I would suggest are :
I read recently that 70% of people in Egypt surf the web trough a mobile device and not a desktop, I can't tell you how this info came by or how accurate it is, but I know that the biggest part of the world is not running the latest HTC or Motorola dual core devices and that it might be a few years before the majority of devices will be able to run JQM in a snappy manner. Where I am going is that maybe, just maybe the project is hitting real technical limitations and that it might be time to consider alternative technologies to improve the performance levels : Several ideas come to mind, for example generating from JQM multiple javascript scripts specific to certain devices capabilities (GWT solution), This would not go against the objective of jQuery and jQuery mobile to support the broadest number of devices, but will on the contrary be a way to maybe include even more devices in the mix and simplify problems that today seem incredibly complex to address.
I fully understand that it might be very difficult for the people that have contributed to this project to look back and "swallow" the fact that their best efforts are not paying dividends to the level they where hoping, but this is just the beginning of JQM, the fondamental idea is great, the code that has already been developed is impressive and the level of compatibility achieved is well above users expectations, it is time now to really define the limits of the devices used today and look at ways around this limitations, even if this mean big changes, because nobody today can realistically release a slow web site or application and hope to retain it's customers.