Addressing the jQM concern, this is why we built Ionic (http://ionicframework.com/). It's still alpha and we have a ways to go, but the UI is more "native" centric and we have been improving animation performance over the last week, and on new iOS devices it's hard to tell the difference between simple native app and the hybrid one. Hopefully you'll find it a better solution for hybrid apps.
Iconic looks really nice, and I especially like the component documentation.
When it comes to the overwhelming number of mobile js frameworks its hard to get an idea of speed without running each of the demos individually and comparing. Do you have any rough stats compared to Sencha?
I tried Ionic on Friday last week. The example code didn't work 'out of the box', and there isn't any documentation explaining how to use it. I tried with PhoneGap, with Cordova and running it in a browser both with and without Ripple. I got pretty much nowhere. Contrast that to trying jQM 1.4 RC1 and having a working example running on my phone in about half an hour with Phonegap.
Open source projects live and die on their community, which springs from examples and documentation that people can learn from. I like the look of Ionic, especially if it was decoupled from Angular, but until it's possible to actually do something with it I (and I imagine many others) can't help out with it.
tl;dr Documentation is critical. Write some, don't just rely on your "doc generator".
Trust me, we know we need to work on docs and tutorials, and we are. Also note that we weren't actually ready to go live last Friday, so there's that, too (someone else submitted our test site).
The community has actually been more active than we expected, and the forum is seeing a lot of activity in the last week: http://forum.ionicframework.com/
The homepage look very nice but I had pretty much the same issues as you.
---
Frankly I built my own UI because I didn't like the opaque layer most mobile web framework are doing (exception being jQtouch but it's pretty old). It's not "that hard".
It's also bound to angular out of the box. While that's great for people using that framework, it's a big learning curve for anyone else.
Totally agree with the author here. Being primarily an Android developer I hate when I need to get access to a Mac to anything iOS related. Phonegap Build solves this problem. I work for avocarrot.com and I managed to do a Phonegap wrapper of our iOS SDK with the build service only using my linux machine.. Pretty awesome!
After you added your app on itunesconnect you can upload the binary. You need "application loader" for that. I haven't found another way, but would be very pleased if there is one.
I work at a big bank and we're developing a very complex application using only jQuery Mobile and Angular JS & fastclick.js. If properly executed, the app runs beautifully and very, very smoothly. Even as a webapp it performs exactly as native.
JQM is beautiful if you really know how to use and know what you're doing.
We're deploying on 20 devices with only one code base and it works flawlessly, it's amazing. We only use native to patch holes or do things we can't do easily with html/css/js.
Happy to hear that, I will update the article with your comment,
I also saw people with lot's of issues with long list & jquery mobile while looking but since it's a framework that basically can be use by anyone I guess I should have expected that some people would submit unoptimized apps with jQuery mobile.
I used the JQM + PhoneGap combination for an app for a small business and it was approved by both Play and iTunes. I used the basic JQM skin with a few minor color palette updates. The animations are really smooth on iOS and acceptable on Android.
I want to make an in depth tutorial from the ground up to app store about just a simple app using Phone Gap and JQM. Maybe accompanied by a web cast as well.
No, what you are doing is likely not that complex and just a series of forms and buttons, which jqm is fine for. If you are doing anything truly interface heavy and complex, the hard parts either having nothing to do with jqm or can't be done in jqm smoothly.
And your single codebase likely has a UI and ux that feels wrong on all platforms.
(I built two of the largest US banks mobile apps using Yui and jqm. )
unless you actually have a product to show, it's his word against yours. Devs always brag about how fast their html apps are, these "fast" apps are nowhere to be seen, or do very little things that require performance.
It's my word against his, I'm the developer, I know what I'm making. I have no problem in him not believing me. The problem is disbelief and then commenting on it, which is fruitless as I'm not in a position to preview my app to the public, nor is he in any position to comment on an application he hasn't seen or used.
Take my experience for what it's worth, if it's worth nothing then skip me.
Now, this is pie-in-the-sky thinking, but I'd love to see something like Xamarin, that uses JS (for logic) and HTML/subset of CSS (for presentation) that builds cross-platform using native widgets.
I think this will stay a dream for a very long while. If Xamarin would create controls based on the lowest common denominator of each platform (with regards to functionality), the capabilities of said controls would be very limited indeed, likely only useful for the most basic of apps.
Mmm, yeah that's a good point, I didn't think that quite through, and to be honest I've not used Xamarin myself. How does it handle the UI layer? Is it re-done for each platform, using C# but with the Android UI and iPhone UI classes?
It's up to you, but mostly, yeah, you write out as much into the shared code area (C#) as possible then, write up/wire up your UI layer using native layout tooling. How far you go to using stuff like iOS storyboards or just doing code-based implementations (C#) is up to you. You have the flexibility.
This yields a massive reduction in time and cost associated with managing multiple code bases while holding onto the native experience.
It's not quite as fluid as html+css, but you don't hear nearly the performance-horror stories.
Converts an HTML5 canvas-based app to use native graphics routines. I haven't used it but been following it for over a year since the approach seems promising.
BTW, a similar thing exists for the ImpactJS game engine (Ejecta), but it only converts to iOS: http://impactjs.com/ejecta
Actually I would love to hear if anyone has experience with either of these.
I really like the idea of these multi-platform bridges.
But in reality the ones that I have seen suffered from being terribly slow. The last app demo that I saw using phonegap had 3-5 second loading bars come up every time a button was pressed. This was on Android so I am not sure if the platform was to blame or not.
While phonegap is a bridge between a lot of functionalities, not all features has been created equals.
The app is only has good has the html5 app behind it. On android it's tricky, we just did a test run for our mobile app & we have weird issues with a lot is samsung phones while other phones perform perfectly.
We also decided to remove animations on android for all phones below android 4.2 because the browser was to slow to handle them perfectly.
Interesting, the slow demo was using a Samsung phone and had many animations. Next time I am going to do some comparisons on different manufacturers and with/with out animations.
The app wasnt one I was involved in so I didnt have chance to mess around with it.
I really don't like the fact that they tout using VS to create and publish apps right there on the homepage however you have to purchase the ultimate package at $119 a month in order to do this. you would think that every package would include this feature if its their main advertised feature.
don't be mystified. all of this comes from your lack of knowledge and experience of native development. if it works in a webview then making a 'native' app out of it is not going to be complicated - you make something with a webview and the html or whatever other source data in the package.
its not magic, its not even hard, you just happen to not know about how it works... if you are interested this is easy to fix with google and experimentation. :)
knowing about android sdk versions is something you would also know if you were an android developer. its everywhere from the first time you install an sdk or ndk - i agree that Google suck at developer tools and docs, absolutely 110%, and this is a good example of that - a lot of their tools I consider 'unshippable' they are so bug riddled and unusable - but thats a tangent.
i do wonder though why even use a native app like this? isn't a web app more friendly? you certainly won't get any of the performance benefits of native code without some real heavy lifting on the part of the framework/library/sdk. isn't a landing page asking you to download a native app just annoying? i know its popular but its just a UX fail however I look at it...
> i agree that Google suck at developer tools and docs, absolutely (...) a lot of their tools I consider 'unshippable' they are so bug riddled and unusable
This absolutely mystifies me. Especially after coming in from the iOS development stack, the android sdk's, simulator, et al, are shockingly bad. And it's been YEARS now.
Yeah, that's my biggest issue with these webapps, people who should not be doing this stuff is doing it, and have no idea what they're doing...
I'm an iOS dev and still knew how the android sdk version stuff works...
I built Fitwatchr for Fitbit (http://www.fitwatchr.com/apps.html) using PhoneGap Build and absolutely love it. I can develop locally in Chrome, switch between Android/iOS using the DevTools, then deploy using Build. Coupled with Kendo UI Mobile, which auto translates the UI of your app to fit the platform, it took days to get a basic prototype running instead of weeks. Highly recommended!
I have tried cocoonJS and phonegap side by side with my app and cocoonJS was much faster, however it was buggy so I went for phonegap. I didn't really notice a different speed between chrome and phonegap, but the lack of address bar at the top made the graphics much nicer with phonegap over viewing it in Chrome.
I can tell the browser used by Phonegap is not as good as Chrome. It doesn't popup the keyboard on text fields and things like that, which the Galaxy S2 don't do either.
I am hoping the bugs in Coocoon get fixed as that has the potential to be the best option.
It absolutely is in android 4.2. After that it depends on the android version.
My app have perfect smooth transitions in the chrome browser. yet in the phonegap webview animations are slower & I have rendering bugs I never saw in chrome.
Can't find direct sources right now, but it's fixed in android 4.4, you get chrome
55 comments
[ 3.0 ms ] story [ 138 ms ] threadWhen it comes to the overwhelming number of mobile js frameworks its hard to get an idea of speed without running each of the demos individually and comparing. Do you have any rough stats compared to Sencha?
Open source projects live and die on their community, which springs from examples and documentation that people can learn from. I like the look of Ionic, especially if it was decoupled from Angular, but until it's possible to actually do something with it I (and I imagine many others) can't help out with it.
tl;dr Documentation is critical. Write some, don't just rely on your "doc generator".
The community has actually been more active than we expected, and the forum is seeing a lot of activity in the last week: http://forum.ionicframework.com/
The homepage look very nice but I had pretty much the same issues as you. ---
Frankly I built my own UI because I didn't like the opaque layer most mobile web framework are doing (exception being jQtouch but it's pretty old). It's not "that hard".
It's also bound to angular out of the box. While that's great for people using that framework, it's a big learning curve for anyone else.
Phonegap build is nice if you don't use any prosperity /closed source plugins.
JQM is beautiful if you really know how to use and know what you're doing.
We're deploying on 20 devices with only one code base and it works flawlessly, it's amazing. We only use native to patch holes or do things we can't do easily with html/css/js.
I also saw people with lot's of issues with long list & jquery mobile while looking but since it's a framework that basically can be use by anyone I guess I should have expected that some people would submit unoptimized apps with jQuery mobile.
And your single codebase likely has a UI and ux that feels wrong on all platforms.
(I built two of the largest US banks mobile apps using Yui and jqm. )
Unless you've actually been in my environment and used my app that we've been developing straight for the past year, kindly fuck off.
Take my experience for what it's worth, if it's worth nothing then skip me.
Actually, its free for anything that can be hosted publicly and open-source on a Git repository
Hey, one can dream, can't they?
This yields a massive reduction in time and cost associated with managing multiple code bases while holding onto the native experience.
It's not quite as fluid as html+css, but you don't hear nearly the performance-horror stories.
Converts an HTML5 canvas-based app to use native graphics routines. I haven't used it but been following it for over a year since the approach seems promising.
BTW, a similar thing exists for the ImpactJS game engine (Ejecta), but it only converts to iOS: http://impactjs.com/ejecta
Actually I would love to hear if anyone has experience with either of these.
But in reality the ones that I have seen suffered from being terribly slow. The last app demo that I saw using phonegap had 3-5 second loading bars come up every time a button was pressed. This was on Android so I am not sure if the platform was to blame or not.
The app is only has good has the html5 app behind it. On android it's tricky, we just did a test run for our mobile app & we have weird issues with a lot is samsung phones while other phones perform perfectly.
We also decided to remove animations on android for all phones below android 4.2 because the browser was to slow to handle them perfectly.
The app wasnt one I was involved in so I didnt have chance to mess around with it.
its not magic, its not even hard, you just happen to not know about how it works... if you are interested this is easy to fix with google and experimentation. :)
knowing about android sdk versions is something you would also know if you were an android developer. its everywhere from the first time you install an sdk or ndk - i agree that Google suck at developer tools and docs, absolutely 110%, and this is a good example of that - a lot of their tools I consider 'unshippable' they are so bug riddled and unusable - but thats a tangent.
i do wonder though why even use a native app like this? isn't a web app more friendly? you certainly won't get any of the performance benefits of native code without some real heavy lifting on the part of the framework/library/sdk. isn't a landing page asking you to download a native app just annoying? i know its popular but its just a UX fail however I look at it...
This absolutely mystifies me. Especially after coming in from the iOS development stack, the android sdk's, simulator, et al, are shockingly bad. And it's been YEARS now.
Is that right? Is web browser used by WebView a different thing that a default Android browser?
I can tell the browser used by Phonegap is not as good as Chrome. It doesn't popup the keyboard on text fields and things like that, which the Galaxy S2 don't do either.
I am hoping the bugs in Coocoon get fixed as that has the potential to be the best option.
My app have perfect smooth transitions in the chrome browser. yet in the phonegap webview animations are slower & I have rendering bugs I never saw in chrome.
Can't find direct sources right now, but it's fixed in android 4.4, you get chrome
http://www.mobilexweb.com/blog/android-4-4-kitkat-browser-ch...