Hybrid apps: Do not copy. Do get inspired. Avoid reimplementing native UI | Hacker News Reader

Hybrid apps: Do not copy. Do get inspired. Avoid reimplementing native UI

makehybridapps.com

41 pointsmattmark32 comments

This "your UI shouldn’t mimick [sic] the native style of the platform" advice reminds me of what we used to hear when using Java and Swing a decade ago.

It resulted in a bad user experience then, and I think that still holds true today. Swing apps never felt right on any platform, even when using a native theme. It's probably no different for apps built using Cordova, too.

This advice sounds more like sour grapes disguised as best practices. I believe a similar excuse was trotted out with Swing ("Swing is it's own platform!"). Users didn't care, they hated the non-native, slow, accessibility-unfriendly Swing apps, which they perceived as bloated and low-quality largely due to the feel.

I can't help but chuckle at the fact that we're making literally the same mistakes we made eight years ago while claiming progress.

> Secondly, your UI shouldn’t mimick the native style of the platform.

hmm..?

> After all, it’s another case of copying the looks and the two reasons mentioned earlier apply here too. It still is time-consuming and distracts you from thinking about your user’s actions.

From a development perspective this may be true, but from a usability/UX perspective, this definitely isn't. It's not just about copying.

It's one thing if you think about your users' needs and decide that copying native style is helpful. It's different if you just mimic the native style without thinking about whether it's what your users need.

I found the performance of PhoneGap still lacking. Currently, I develop a very simple app with Impact.js, which is an HTML5 game engine and can be deployed with Ejecta. However, I don't do a game, more like a calendar app.

The downside is: You can't use any HTML/CSS elements for building the UI. Because Ejecta supports only the canvas element.

The plus side is: If you manage to make a basic UI like in a "game" with canvas only, you'll get near-native performance, since Ejecta implements an OpenGL-enhanced canvas element.

For better performance, take a look at Crosswalk[1]. It bundles your app in a Chromium browser, which should be way faster than Android's Webkit.

[1]: https://crosswalk-project.org/

Hybrid gaming might become a bigger thing when iOS8 is finally released, it should bring WebGL support. I'd like to see how e.g. pixi.js with WebGL renderer performs on mobile.

I've been able to use PhoneGap / Cordova in my iOS projects and achieve ~60FPS, but I've had to stay within some constraints (e.g. use GPU-accelerated CSS animations). As suggested, Crosswalk is an interesting alternative for Android.

The performance problems are not the fault of Cordova in the newest version which can be configured to use to the newest version of Chrome on android devices. Instead performance issues are the result of inefficiently manipulating DOM. Try famo.us with phonegap and you'll be able to overcome the performance issues you're seeing.

disclaimer: I work for famo.us, but trust me here. do a proof of concept of something with cordova and famo.us that in you prior experience was poor with just cordova alone.

For a simple hybrid app (HTML5/JS/CSS packaged with Cordova) is there a reason to use famo.us instead of ionic?

Try both.

I honestly haven't spent much time with Ionic and I have a conflict of interest, so take my position with a grain of salt, but AFAICT, thus far we (at famo.us) have spent more time building out the foundation (scene graph, perf optimizations, and physics engine integration) that allows a UI layer like Ratchet, Ionic or Material to be built on top. With that in mind, we haven't yet spent as much time on the UI layer, which is something we're doing now. Think: solid engine and architecture, but body work and trim in progress. Ionic (and Ratchet) on the other hand spent more time focusing on the UI layer, and is currently in the process of trying to modify the underpinnings to do the types of things famo.us is already capable of doing. Think: sexy looking car with an underpowered engine in the process of being upgraded.

However, again, my Ionic experience is pretty limited and a tad dated, so I urge you to do your own experimentation with both to see which best meets your needs right now. Personally, were I an outside developer, I would be choosing between famo.us and ReactJS instead of between famo.us and Ionic, since I'm personally "magic" averse and don't like tight coupling between the UI layer and the underlying layers that make that UI layer possible. The chrome on top is far less important to me (unless the goal is a quick prototype that I'm certain will be throwaway) than a solid modular architectural foundation that I comfortably know I won't be fighting as my app becomes larger and more complex. That being said, my broad generalizations here are based on my Ionic impressions from a few months ago. Things may have changed.

To further elaborate on what criteria I would use to choose between famo.us vs ReactJS, it comes down to this:

(1) Do I just need a (a) basic interface performance guarantee with discrete changes betweens application state and (b) greater backwards browser compatibility? Is my "app" going to be more traditional web app on desktop (vs Android and iOS like)? => ReactJS

(2) Do I need to make an app with not only a performance guarantee, but continuous transitions between application state (animations like those on capptivate.co), and will that application be largely consumed by people with relatively new mobile devices (smart phones or tablets, android or iOS)? => famo.us

Lastly, from what I've heard from fellow developers, famo.us and reactjs play pretty nicely together and we're going to be working on integration and tutorials between both, so it's possible that whichever one you start with today, you can add the other to get the best of both worlds. We're also starting work on an EmberJS and famo.us integration, so if you want a lot of the data and routing niceties of emberjs, but the interface niceties of famo.us, there should be tutorials and demo apps coming out in a few months.

Another option, which is very new, but gives you a lot of the reactjs benefits, but in a more modular packages that feel better to NodeJS developers is rayno's mercury project. It's still pretty new and documentation is lacking (which you can contribute to), but it takes the react ideas and breaks them down into smaller rearrangeable pieces.

Or avoid unnecessary DOM updates and use only opacity and 3D transforms in your animations to get the same performance as famo.us

Basically. Although, any way you slice it you're going to want something (famo.us, some future alternative that uses the same same techniques or your own solution that uses the same techniques), because letting the logic that manages opacity and 3D transforms to be mixed in with your app logic code is poor encapsulation. Honestly, it would be great if the browser makers realized the value of a low level scene graph API to permit people to create solid app-like experiences while also preserving semantic HTML structure within the leaves of the scene graph.

So you choose to implement a very simple "calendar" app with a HTML5 Canvas Game Engine!?!?! Not only that you then layer the javascript on top of that with a 3rd party javascript interpreter (Ejecta)....

That doesn't sound simple at all! That sounds super complicated...

Why not use jquerymobile and some css?

Like every tool, you need to know the pros/cons and be able to apply them to your situation. Unless your goal is to make a super simple app that has 100% coverage across all mobile devices, Phonegap shouldn't be the tool you use.

The market share of phonegap in hybrid apps is depressing to me. It's not hard to learn the Apple/Google sponsored way of doing things and then progressively decide when to bring in html/css in a webview.

I even open sourced a starting point I've used on my apps that I'm hoping will get more people to avoid using phonegap and learn iOS / Android: http://imbed.github.io/

Refs: http://dojo4.com/blog/why-phonegap-sucks http://dojo4.com/blog/imbed-for-android

Please point me to a place where I can understand how to do Objective C in a "not hard to learn" sort of way.

There is way too much going on in XCode that a web developer wouldn't get or understand without having broad strokes glossing over the Interface, file structure, or behaviors included therein.

Over and over again I keep hearing people recommend the Big Nerd Ranch guide to Objective-C. I've briefly looked at it myself, but never got into iOS development so didn't pursue it seriously. With that in mind, I found it to be a very approachable resource, but that also comes with the caveat that any way you slice it, you're going to have to become familiar with computer science and programming language concepts and "ceremony" that you previously never had to worry about with JavaScript. The notation/syntax is heavily influenced by C and C++, and its those concepts that "bog" you down until you realize their role in the code you're writing. Basically, I'm not entirely certain there is a 100% "not hard to learn" sort of way, since every resource is going to have to expose to language features where you are asking yourself "why can't this be as simple as JavaScript, the untyped/dynamic interpreted language I know and love."

While I was partially playing Devil's Advocate, I'd would definitely agree up to the point where you said JS is simple. I personally think it's awful and we should all collectively feel ashamed that Javascript tends to be the first "code" anyone dips their toe into when starting out in our field.

I've never wanted for better guides, books, and tutorials online for any of the languages I've gotten into. Specifically Golang and Java have both been much more approachable for me in recent months because I feel like I don't need a degree in rocket surgery just to open the IDE.

Maybe that's my problem. I'd rather not have to learn an IDE at the same time I'm having to learn a language. Now that I think about it, I also hated VS (but not Eclipse or the Jetbrains products).

Thanks, Doc ;) I think I just figured out my big problem!

Yes, avoid reimplementing native UI.

But use native UI where possible.

Interesting article. I think that the slowness of webviews has much value than we can image. This guarantees to Apple, Google etc to have a total controll over apps distribution, in other words a Fast WebView is equal to minus money for them.

WKWebView in iOS 8 and OS X 10.10 [1] and Chromium-based WebView in Android 4.4 [2] don't have the performance issues that the old WebView APIs used to have.

[1] http://www.youtube.com/watch?v=ZC_rNie61IQ

[2] https://developer.android.com/guide/webapps/migrating.html

Not really, most editors will still want to be in the app store / play store even if they can release a pure web app. From a marketing point of view releasing "an app in appstore/play store" has a lot of value vs releasing "a mobile web app"

Also, iOS and Android since 4.4 have pretty good performances in the webviews.

the point is not the releasing to AppStore but the download from app store. You could release a webApp to appstore but not download it from the store.

Hybrid apps aren't production ready due to performance issues. May be weebkit was fixed in the latest build of Android 4.4, but that excludes the majority of users. The adoption of the newer builds in the android market is much slower than iOS.

Only 18% of users right now have 4.4, for comparison 14% are still using 2.3.

I would 100% disagree. The average "app" can most definitely be written in cordova / phonegap with jquerymobile / Intel App Framework or another MOBILE framework and run fine.

I've spent the last few months implementing a plain cordova app with Intel App Framework , google maps api v3, some css3 transitions, etc.

I've tested it on everything from Android 2.3.6 to 4.4, all work fine, no performance issues. Same on iOS.

Now if you are taking something you've written for a desktop (and are using desktop frameworks) or something that starts doing crazy DOM manipulation (or adds "shadow dom's", etc) then yes you might see a performance problem...

Additionally, if you are talking a physics enabled HTML5 game, that might be an issue. But a plain old app with some basic functionality will run fine. If it doesn't , YOUR doing it wrong.

I implemented a little bit of animation and a 'native-esque' SPAM button in my app Herenow. I used css3, and to be honest, it doesn't feel quite native because the webview isn't as fast as a native control would be. Looks are easy, feel is hard.

http://www.herenowapp.com/

Author of the blog post here. From my experience, achieving a native feel with a hybrid app on e.g. iOS isn't that hard. There are constraints, true. But it can be done.

My strategy is to use GPU-accelerated CSS transitions, test often on the real device and see how others are doing it, e.g. in UI frameworks (onsen ui, framework7, ratchet, etc).

Incidentally i spend the last 2 weeks going through various Android devices, and iOS devices, various javascript frameworks and various CSS frameworks.

I'm happy to see others having opinions on this subject.

Essentially i did the research for these combinations:

[Android devices]x[iOS devices]x[js frameworks]x[CSS frameworks]

It was hard and tiresome but the conclusion - same as yours - iOS works very well for cordova/phonegap. Android is a no-go!.

Among the frameworks I checked: backbone, ember, angular, ionic, topcoat and various other CSS frameworks.

All were slow on Android. Also discovered 4.4 introduces worse performance (acknowledged by google) which is solved with crosswalk. However crosswalk brings many bugs to the table itself.

Really disappointing - currently I'm opting out and going Native.

Allow me to suggest taking a look at QML/Qt Quick. I've only recently started working with it, but so far the UI performance is excellent and for someone experienced with HTML/CSS layouts and JavaScript it's quite easy to pick up. (Also, FWIW, it's more enjoyable than twiddling with CSS.)

Maybe I'm a moron, but the entire concept of "native look and feel" means nothing to me. I have used android for about 5 years and have played with plenty of iOS devices and I'm still not sure what parts are native. Apps all have seemingly different look and feel. We certainly never sweat nativeness on the web going for consistency across OSes instead. It seems like going to native look is not even a desirable thing.

I'm going to go ahead and assume that most developers don't have access to the millions of dollars in market research, analytics, focus groups, design theory, etc. etc. etc. that Google and Apple do.

Why would we abandon an aesthetic (that as of the L preview) that is two of the best and cleanest looking interfaces on the planet?

Implementing a pixel-perfect design in a webview-based Cordova app was a nightmare on Android 4.0—4.3. I'm glad 4.4+ has native Chromium webviews, but I wasn't advocating web-based packaged apps before and I can't see myself doing it again.

Just curious, has anyone tried to use React (or Om) for their html5 mobile app?

Reply on news.ycombinator.com