User's don't care if you use native or HTML5 as long as you get them what they need.
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.
I'm very impressed by the performance on both your DN and HN clients. Usually everything web lags a lot using the stock browser on my Galaxy S3 but these are very smooth. What's your secret?
I work on an app that has made a similar tradeoff. I won't restate the positives because the post describes many of them (after all, we chose a similar architecture) but I'll add that fetching app logic+assets (in the form of JS/HTML) from a server also lets us iterate on the app more quickly and without requiring the user to approve an update. (Edit: oops, he actually did mention this in the post!) And we get to use all our HTML-based testing tools (like automated screenshotting) to catch regressions.
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.)
The reality is that tap events won't work correctly until you actively fix them, and almost all of them can be fixed (including ghost clicks). Fastclick.js does help here a bit, but it's not perfect. We did a ton of work on our end to have a comprehensive tap solution (though some of it is specific to Ionic projects), but could be useful for inspiration for your own project: https://github.com/driftyco/ionic/blob/master/js/utils/tap.j...
Thanks for the link. We also have an in-house solution like fastclick.
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).
I agree with the "long tail of details". The big wins are championed while seemingly infinite little gotchas are glossed over. Native development appears to be linear and straightforward because there is one language and one API - "one thing" to reason about. Contrast that to all the context switching involved in a hybrid app. Portions are written in Obj-C, portions are dynamically built using data, portions are written in JS, CSS, HTML, and Rails. What about additional tools like SASS, jQuery, JS MVC of choice, etc, etc? A lot of moving parts can be hard to juggle, and slow development as app complexity/entropy sets in.
> Native development appears to be linear and straightforward because there is one language and one API - "one thing" to reason about.
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.
> If you're only targeting iOS and nothing else, then I would agree with you.
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.
Cool, so that covers iOS and Android (with its own long tail I'm sure). You still have Web and Windows mobile to worry about assuming that platform continues to gain popularity.
Apportable could be ported to run on Windows Phone, there just hasn't been any interest (or so I'm told).
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.
Still takes longer for non trivial apps to get the it right on a large array of devices of X in Html than native. Especially using something like Xamarin I would gladly take up the challenge. Hybrid has it's place ofcourse; for more complex text markup embedded in apps.
Native feel is a false prophet. "Fitness for use" is what you should aim for. The web didn't have a native Windows 95 feel. ExtJS tried hard to achieve interfaces that aped the "native feel" of Windows. Only hardcore interface designers that actually know what "native feel" is care about native feel, and even then they will only care about it so long as the current fashion trend is achieving a native feel. Once non-native feeling apps achieve "fitness for use" en masses, the "native feel is canon" will no longer be part of the app zeitgeist.
Except that you can get a native feel, as Basecamp has clearly demonstrated, if you utilize native SDK's where needed. Did you even read the article or try out their apps?
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.
Don't get me wrong, I'm loving the experience so far and my "simple" comment refers to my skill level.
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)
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.
The issue with the status bar is even using that plugin (which I have working now thanks to the forums) there is a flicker on initial load of the app when it hides. Still can't figure out how to get rid of that.
Thank you for your work on Ionic! I have been using it the last few weeks and really like it. I think the navigation performs well. Honestly, outside of a few minor bugs that got fixed in the last release, the only real problem I have had with it has been learning Angular. But, that will come with work.
Motorola Solutions employee here (MSI bought RhoMobile three years ago).
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]
By the way, did I mention that RhoMobile won 2010 Fukuoka Ruby Award Grand Prize? [4]
You can take a look on Launchpad, MSI developer website [5]
The only true advantage the hybrid approach offers is improved interface performance, but that comes at the great cost of (1) increased complexity (multiple technologies, possibly multiple teams), (2) poor distribution and conversion (install require), (3) dealing with draconian app store approval bureaucracy, and (4) speed of tech and design iteration much slower than the web.
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.
You guys need a little love on your page :) I've not heard of it before so I google it and get to what appears to be the home page, and am presented with a login box with zero info about what it is, or why I would want to register or log in in the first place. Plus 3 of the links in the header aren't linked to anything. Not the best first impression!
Yeah, it does need some love. We're aware and plan on really fixing it up over the next month or so. For the most part almost all engineers on the team are working on some fundamental part of our medium to long-term vision and we're mainly trying to bring all those parts together in a coherent way first.
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
Yeah, I keep hearing this for the last three years or so.
Web tech won't gut anything, except itself.
It is not caching up it is falling behind, fast. Not a single problem what existed four years ago is solved, it seems that all the work is to get PoC implementation of some feature and then leave it in the half-baked state and move on.
Fastclick.js, tap.js, need to say more?
FWIW, I've been doing the web app tech schtick since about 2010 and since about 2011, I've been pretty consistent on the 2014-2017 time frame.
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.
I'm not. To the degree famo.us is wonderful, its about page gives a misleadingly bad impression on my default mobile browser.
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.
I totally understand how our mobile site gives a poor impression.
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.
Great article from 37signals. I built my app for Fitbit, Fitwatchr (https://itunes.apple.com/us/app/fitwatchr/id684005201?mt=8&u...), using web tech only. I leveraged PhoneGap for native access (OAuth via an InApp browser and Google Analytics) via plugins, PhoneGap Build for native iOS, Android and Windows Phone 8 builds, and KendoUI Mobile to achieve native looking UI for all (handled mostly automatically!). They are correct - in 2010 the technology, tools, or performance may not have been quite there yet, but in 2014 things are much more viable.
I think there is this luxury where the targeted users, or audience of Baasecamp may actually have the higher end Phones. So the 5/5c or definitely 5S will be fast enough.
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.
He goes through all of the pros and cons of this approach, but doesn't mention which framework they used for the html portion (unless they rolled their own in which case might as well go all native). There are so many different frameworks it seems (Phonega, Cordova, Trigger etc), does anyone out there have a rundown of all the different ones and the quality of each?
We're not using a framework. The app itself is a standard Cocoa/Objective-C app, just using a mix of web views and native views for rendering the content of individual screens.
I'm glad to see an organization as prominent as 37 Signals coming out in favor of the hybrid mobile development approach. Everything DHH mentions in this post is spot on as far as my experiences developing hybrid apps goes. I was on a project that was resource constrained but needed good mobile presence as well called kona.com that's in the same problem space as Basecamp. We tried both the full native and full HTML5 routes but neither option worked for us. We didn't have enough developers for our native apps to keep up with the web app and the HTML5 app (powered by Sencha) simply didn't perform well enough on phones back in 2012.
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?
The user experience problem is a real one. But it doesn't mean it makes business sense for a small company to hire 2 iOS developers and 2 Android developers for native apps when the user base doesn't make heavy use of their mobile app (hybrid or not). I honestly don't care if I'm doing native development, backend, frontend, etc. But throughout the last 4 years I've used, analysed and worked in many different mobile apps, and the hybrid ones stick out, from speed issues to expected user patterns that aren't respected.
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).
Hybrid apps allow you to ignore user patterns and speed, but that doesn't mean it's guaranteed. Case in point: Instagram uses webviews extensively, and most people are none the wiser.
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.
Oh they will, they will. But you will never hear them say "man, this app sucks, cause it is hybrid, I wish they did it all native"—because they don't know the difference in the technologies. But they do know the difference in experience.
Has anyone used AppGyver, which seems to be a framework that incorporates this combo of native navigation with WebViews and Cordova? I've been working solely on the HTML components of an app, nav included, but would love to hear anyone's experience.
Pretty cool, thanks!
Here is some feedback:
* Overall it's great.
* The instructions on where to input the code starts out very precise, but as the piece goes on it gets sloppier. For example, "Open WebViewController.m and after the viewDidLoad method, after the comment, add this new method" is not entirely accurate, because you're adding the new method AFTER the existing method, not after the comment inside the existing method (fortunately the screenshot is there to show what you mean). And the very last code sample (for the loading indicator) doesn't actually have a code sample, just the screenshot.
* I was not able to get forward/backwards swiping to work -- but perhaps this is just a limitation of the simulator?
Definitely looking forward to seeing a more fleshed-out version. Thanks!
Thanks! Points taken. I will review the text to make it more accurate and clear. Seems appropriate since I'm trying to do a "Clear Hybrid Apps" ebook. :)
To swipe forward/back you have to drag from the exact edge which on the simulator takes some practice.
I use AppGyver. I think its great of iOS apps but still weak on Android ones. To be fair to them, they seem to be making improvements on that side of things. But since a big argument for going non-native is immediate cross-platform support, the lack of fully functional android support could be a deal breaker.
I'm curious how they get away with having basically 100% of their app as web-based. We used native controls for login screen and another screen to play it safe. Are we playing too safe?
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://hn.premii.com/