Hybrid sweet spot: Native navigation, web content
signalvnoise.com
signalvnoise.com
Our app is also different in that we precache all the HTML in the background so we can always load it from disk rather than the network, which helps avoid any loading delays.
Here are some of the negatives I've encountered. (My experience is solely with Android but I believe the basics are also true on iPhone.)
- There's a long tail of details that are hard to get right. E.g., handling multiple device DPIs, or getting navigation right (Android has a confusing mess of back vs up and tasks vs activities). This is all solvable (after all, that's why you've gone hybrid), but it ends up pushing more of your code native than you'd originally expect.
- There's a delay on all click events on a webview. This is probably worthy of a longer blog post but to summarize, there are at least two causes of this.
One is that by default click events happen 300ms after the touch event (I think due to it waiting for a double-tap?). You can work around this by handling touch events specially (and there are JS libraries that claim to do it) but in practice it doesn't work in all cases (e.g. some form controls can't be worked around) and we ran into bugs on obscure devices (e.g. our users report they can't focus a form control on certain Samsung devices; we even got one of those devices but couldn't reproduce the problem). Alternatively, the newer Chrome-based webview turns off this delay if your content's meta tags indicate it's not zoomable, but you can't really rely on this because the Chrome-based webview isn't widely deployed.
The other source of lag is that the "active" DOM state is also delayed, but by some other number and unrelated subsystem. This means when you tap a button it'll light up a bit after you tap it. In my brief survey I think other mobile apps work around this by not having a prelight state.
Sorry to be full of bad news. (Like I wrote above, I still think this architecture is the right tradeoff for my application's purposes.)
No. There are X languages and X API's to reason about when doing native development, X being the device OS's you want to target. If you're only targeting iOS and nothing else, then I would agree with you. This is a point that's also glossed over by native app proponents.
That's becoming outdated. We've got a native iOS app and we're doing the Android port with Apportable, which provides native iOS APIs and features on Android. The dev version (which we're using) implements its own Core Animation subsystem on top of OpenGL ES 2.
It's not perfect, but it's a hell of a lot better than maintaing two separate codebases and it's far easier to fix whatever platform issues there are than the equivalent "long tail of details" you encounter working with web views.
Much of it could also run via NaCl as a Chrome Packaged App, including the UI stuff. That's a much bigger change though, since you'd be supporting mouse events, not touch. But it's still doable.
The hard part about this is tracking down the long tail of failures, particularly when they affect devices you don't have access to like the Samsung phones I mentioned above. It means we cannot make any changes to the code we already have without risking breaking some users who currently work (and rely on our app; as separate from the users for whom the app has never worked).
After scrapping both those attempts I suggested we go with a hybrid app. We would lean heavily on javascript (angular.js in our case) and rely on native for access to native APIs and for UI elements that required better performance like the Facebook style drawer, slide up animations, the top and bottom nav bars, etc. It was the right mix between developer efficiency and app performance and allowed us to target not only Android and iOS with 90% of the same codebase, but also a native desktop app as well using Chrome packaged apps. We had written the main web app in JavascriptMVC but when I left the project we were just starting to port over the angular app to the main site, so eventually the same angular app would be powering the website, desktop app, iOS app, and Android app.
It only took one developer (myself) to manage the native code on Android and iOS and the logic was very similar in both places so it ended up being pretty simple to maintain. And as DHH mentions, setting up communication between your native code and your web code is easier than you'd think, although I am interested in hearing more about how they did it.
At any rate, DHH is totally right about the fact that most apps would be suited just fine by hybrid mobile apps as most apps are data heavy like Basecamp. Don't tell that to native developers though because you will catch an earful about poor user experiences and maintenance hell, which in my experience is a bunch of FUD. The proof is in the numbers, and the Basecamp apps are well received (as were ours). The FUD around mobile apps and user experience reminds me of this post that showed up on HN last week: https://medium.com/design-founders/f59c964513ef, which examines the failure of the assumption that meticulous, cutting edge design will guarantee success. In my experience, if you can get close to native but you solve the user's actual problems (which is very rarely related to a lack of unique swipe gestures and translucent backgrounds) you are usually good to go. Why continue to deal with the pain and cost of having dedicated teams working on the exact same app for Android, iOS, Windows Phone, the Web, native desktop apps and god knows what else?
I tried the basecamp app on android and I'm to say that the UX is good is a stretch (for consuming the data is fine, but for inputing data is not).
Not in my experience. Without fail the only people I've ever heard complain about UX of hybrid apps are other developers who know which signs to look for. Most people won't notice or won't care to notice so long as the app does what it's supposed to do.
After all, I've been hearing developers complain about Craiglist's poor UX for years and it hasn't seemed to affect them.
> Most people won't notice or won't
One of the major problem with HTML5 is not HTML5/JS but how you we are trying to use those. We want to use all the libraries and frameworks. Backbone, AngularJS, bootstrap are good but using those on mobile will slow down your app. Also there is this mentality that you can only have good interaction if you build 100% client side rendering.
Everyone thinks that rendering on client will be faster as we are only sending JSON and html templates are cached. They should do compare and see if JSON that they are sending is really lighter then rendered HTML. Most of the time I found that after gzip, HTML is smaller compare to JSON.
Browser wise, Android is lagging behind when it comes to transitions. Its getting better but still not good as Safari or IE on WP8. Also Samsung is always uses wrong version of android browser. Even on galaxy S4, they screwed up big time (Browser on S3 was better than S4).
I build hacker news mobile client using HTML5, and I do have 4.5 star ratings on the both app stores.
https://play.google.com/store/apps/details?id=com.premii.hn
https://itunes.apple.com/us/app/hacker-news-yc/id713733435
or Try it on your browser
http://dn.premii.com/ - Designer News For mobile. Lot of animations and works on Android, Safari on iOS and IE10+ on WP8.
Was super simple and straight forward. Simple 7 page site with a breadcrumb nav and PDF/Video integration. Highly suggest cordova/phonegapp and Ionic if you're doing something simple in a WebView.
I personally think you can do 100% of the nav in the web. The problem is there legitimately weren't native-style navigation tools in web until recently.
Unfortunately, the standard linear history doesn't work for apps that run in a native container. You'll often be managing three or more concurrent navigation stacks (for a 3 tabbed app, for example), and the concept of a browser back button just doesn't make sense in an app like that.
So we've built a lot of that with Ionic. Perhaps at the expense of the mobile web browser app experience.
I did have a couple issues finding answers. Since you've commented, I'll post a couple here but I'll try to add them to the forum.
* Setting webviewbounce, UIWebViewBounce to false in the config.xml doesn't get respected by the framework. You have to manually add the attribute has-bouncing="false" to the ion-content tags to stop the bouncing.
* The helper ionic.Platform.fullScreen(); to hide the status bar initially flickers on first load of a fresh build. I'm currently trying to figure out how to hide the status bar on initial build. http://stackoverflow.com/questions/23553220/how-to-completel...
* I was a little confused using ui-view vs. ion-view. (I think)
Thanks for taking the time to comment!
WebView bouncing is a vague term and I'm not exactly sure which you are referring to. If you're talking about the entire frame, it's now "DisallowOverscroll" in the Cordova config. If you use the ionic utility you'll get the correct config for a new project.
To hide the status bar, use the status bar plugin (org.apache.cordova.statusbar) and call StatusBar.hide(): https://github.com/jonathannaguin/org.apache.cordova.statusb...
The ui-view vs ion-view discussion: use ion-view. We basically have a custom ui-router implementation with multi-stack routing.
Hope that helps, and I'll look into our docs to make this all more clear.
I did use the DisallowOverscroll in my config, I still had to manually add has-bouncing=true to every ion-content tag.
These are the values I tried:
<preference name="fullscreen" value="true" />
<preference name="webviewbounce" value="false" />
<preference name="UIWebViewBounce" value="false" />
<preference name="DisallowOverscroll" value="true" />
Thanks again though for answering!
The gap for this sweet spot is going to close very rapidly over the next year or so due to work being done by us at famo.us and engineers working on react/om.
DHH, like others love to point out Facebook's decision to pull out of HTML5, but that is going to become a tired meme. One of the FB engineering managers, Dave Fetterman, who was instrumental in making the call to go with HTML5 and then reversed course towards native, is now the VP of engineering here at Famo.us. That's a testament to what's possible soon, since typically someone doesn't go back an revisit what many people popularly consider to be be a mistake unless there is real value there on the horizon. The fact that Fetterman is back working on this problem and that Pete Hunt and team at Facebook is actively working on react is testament to the performance that's now achievable without having to be a javascript neckbeard.
If you were a web developer that left the web years ago for native land, or you have always been in native land and were waiting for the web to catch up, now is the time to start exploring what's possible. There will always be a use case for native technologies, but the web is going to gut a lot of the current use cases for native over the next 1-3 years. When that happens, there is going to be a glut of iOS and Android devs and a dearth of javascript developers who really know how to build great web apps.
(disclaimer: I work for famo.us)
Another reason for its current state, is that the tech media and the community have been quite eager to take care of our positioning and messaging, so we haven't had to focus engineering effort on these areas too much in order to see adoption and growth. Improvements are coming. Look out for changes to the site over the next 1-2 months.
> but the web is going to gut a lot of the current use cases
> for native over the next 1-3 years
Everything is in a half-baked state because people start on a project, realize that other parts aren't good enough, so because they have work to get done, the move on to the tech that works for the job at hand. Things are finally getting to the point where web app tech has achieved "fitness for use" (the most accurate definition of quality I can think of), which means that library authors are no longer in a position where they have to maintain and grow a library in isolation while they wait for other libraries to catch up.
On top of all that, what has also caught up is the money. There is now real solid VC money backing up companies that either create webapp tech or are betting on webapp tech as part of their strategy. With money, you have people who no longer need to depend on the goodwill of others to push things forward.
Lastly, there's been a cambrian explosion in the general sophistication and knowledge level in the JavaScript community. NodeJS created a viable JavaScript environment free of all the bullshit that comes with myriad user agents. They made it possible for engineers coming from many other language communities (C/C++, Java, Python, Ruby, Perl, etc.) to really dig into the language and bring diversity of ideas and experience into the JavaScript community. That diversity is now jumping the network gap and becoming more common on the browser side of things.
Does web app tech meet the conditions of "fitness for use" for all use cases of native? Certainly not. There are several areas where, as you correctly pointed out, it's falling behind. But this likely won't be the case in about 2017, when the only remaining difference between native and web is going to be a performance gap of at most 2x for certain uses. There are not a ton of use cases where a 2x performance difference makes the difference between something being fit for use or not, especially when you consider other benefits native can't achieve like distribution via hyperlink and incremental loading of non-content parts with use.
One of the most important questions an engineer needs to ask is "Does it matter for my career whether I'm on the right side of technology when a fundamental shift happens?". For career engineers working in areas where native is likely to have an edge for years to come, it probably doesn't matter. But what happens if you're an engineer with an entrepreneurial bent like many on HN? Starting in 2008 and going into 2011, if you didn't have legit talent on your team for building iOS and Android apps, that was a problem for your business. Starting in 2015 and going through to 2017, the same will happen with web app tech. If you want to be in the right place at the right time, this is the year to actually start learning, so that you're well positioned for the next three years and opportunities shift.
Fundamental changes happen. It's valuable to be able to time things to account for those changes.
RhoMobile is a platform that deliver on building a native application using web technology. A lot of the idea are borrowed from Ruby on Rails in the Framework (MVC framework done in Ruby with a simple ORM on top of SQLite).
* Updating the app without user intervention?
covered[1]
* Common set of API available in JS and Ruby?
yes [2]
* Offline capability, local data and a synchronization server based on a NoSQL DB?
of course. How can you leave without a NoSQL DB? :-) [3]
You can take a look on Launchpad, MSI developer website [5]
[1] http://docs.rhomobile.com/en/4.1.0/guide/app_upgrade
[2] http://docs.rhomobile.com/en/4.1.0/guide/apisummary
[3] http://docs.rhomobile.com/en/4.1.0/rhoconnect/introduction
[4] http://www.prnewswire.com/news-releases/rhomobile-rhodes-sma...
[5] https://developer.motorolasolutions.com/community/rhomobile-...
On my landscape iPad Air, the hamburger menu on the first link flapped state during scrolling and selection. I genuinely had no idea, when I tapped Docs, whether I'd got that or Demo. Scrolling the next page moved the content up, but also the header, while leaving the left side navigation in place.
We're aware of this, but FWIW, we haven't really spent much time on the mobile site at all given other priorities and because there really isn't much if any content on there that provides utility in a mobile use context. Most of our work at the moment is focused on Famous University (desktop only). We'll fix the mobile experience as soon as we wrap up the more pressing parts.
If you want a real world example to try out and judge us one, install the chrome app Beepe.me. Plugg.me is another app, but I don't think it's been released yet.
But there are an Ocean of cheap / slow and older phones out there, which i dont think they will have quite the same experience if it was in Web compared to Native.
The Gap will shrink, as technology moves forward. But for the best experience around, may be its best to stick to native for now.
There's a world of difference between rolling your own WebView wrapper and "going all native".
http://luminescente.com/2014/03/how-to-build-your-own-phoneg...
I'm also writing a book on the subject, there's a link to it at the bottom.
Any feedback appreciated.
Definitely looking forward to seeing a more fleshed-out version. Thanks!
To swipe forward/back you have to drag from the exact edge which on the simulator takes some practice.