Another one bites the dust. The app my team and I have been developing is an HTML5/Native hybrid app, much like LinkedIn's was, and their decision to move away from their HTML5 strategy is a bit baffling to me given how well things have worked out for us.
Our app has a few native ui elements like the top bar, the bottom tabs bar, a quick add control that slides in and out, and Facebook style drawers that expose two other webviews. The rest, however, is done in pure HTML/JS/CSS. Angular.js, in fact.
It runs well on old android devices with 2.2 installed, and runs really well on newer Androids and iOS devices. We take full advantage of the benefits HTML5 provides. Most of the user's important data is cached in localStorage so the app loads very quickly. We use websockets to update the app in realtime without the need to rely on long-polling or native push notifications (which we do still have). We have one stylesheet with zero platform specific hacks thanks to the fact that Android and iOS devices use webkit browsers. And laying out our app's interface in CSS/HTML is much more efficient than doing it twice either programmatically or using nib/xml layouts.
We even use http://www.tidesdk.org for desktop native apps and of course that version runs fantastically. We didn't start out using Angular.js on our main web app, but we are slowly starting to transition our mobile app codebase over to our main web app codebase. At some point we will have the largely the same code running across all major offerings of our product.
Every time one of these splashy articles about a well known company moving away from HTML5 comes out I smile knowing that the FUD it will inevitably create will allow those of us who are benefiting immensely from using HTML5 for mobile to continue to enjoy our productivity advantage.
For those who are curious, our product is http://kona.com and the mobile apps are both available in the store. I'd be interested to hear any feedback about how well the apps perform (my email address is in my profile).
Yeah, I'm reading it as: "We were too lazy to help develop the tools we were missing." - The community overall could have benefited from it.
There's nothing wrong with that, of course. I love native app development. I'm just sad to see stout believers in a great technology suddenly roll over and play dead.
The top and bottom bars are completely native. So when you tap on a tab, your interacting with a native interface laid out in a nib and a message is passed to the javascript app inside the main web view telling it which tab has been selected. The sliding drawers (popularized by Path and Facebook) area also completely native, but they house two other webviews that also are simply running javascript apps in them. Finally, we have a slide out "quick add" menu that we determined needed to be native both because the performance when it was implemented in HTML5/CSS3 on older Android devices wasn't acceptable and also because it needed to overlap other native elements.
The main reason we need to have some native UI components is because fixed elements are not well supported on older iOS and Android devices. That means that in the webview sandwiched inbetween our top and bottom bars we cannot have any fixed ui elements. This ensures that the scrolling stays smooth on all devices because it's really just utilizing the native webview scroller. Newer versions of iOS and Android do support native-style momentum scrolling within a DIV, but the performance isn't quite there on all but the most powerful devices (for reference, Sencha Touch's http://fb.html5isready.com uses these native scrolling divs, and quite impressively too).
There are also other features that need to be native under the hood like push notifications support, camera/photo-library support, and contacts support, etc. Thankfully Phonegap makes most of that available to us and for anything that isn't available as a Phonegap plugin we simply wrote ourselves.
The way I see it, this "hybrid" approach is a necessary stopgap for us HTML5 mobile developers while we wait for more devices to reach the capability of the fastest phones available right now (iPhone 5, Galaxy S3, etc). Eventually we should be able to do almost everything in pure HTML5 like Sencha Touch's demo linked above and ditch the native UI elements completely. There will, however, always need to be some sort of bridge between HTML5 apps on Android and iOS devices and the native APIs that are not made available to those devices' mobile web browsers (contacts, camera, files, push notifications, in-app purchases, etc).
I hope that explains it in better detail. Hit me up if you have more questions, my email is in my profile.
Do you have an idea for why both Facebook and Linked in, the two poster children of HTML5 apps, moved away from them? It can't be that they have a grudge against HTML or something...
Yes, actually, I know exactly why Facebook's moved away from it: the beginnings of their HTML5 mobile strategy actually pre-dated the original iPhone, and as such they were using a strategy that didn't really make sense in the post iPhone world. Namely, the app was pulling down the mobile version of their website from the server on every request, which as you might imagine meant things were generally pretty sluggish. So it was really no different than just hitting the mobile version of Facebook with mobile Safari. Contrast this to using a javascript app that runs off the phone's file system and just makes requests to the server for JSON data, caching that data in localStorage along the way (which is what we do). That strategy is really no different than what fully-native apps do except that you're presenting and managing the data in a webView rather than a UITableView. It's much more performant with the benefit of using HTML/CSS for (cross-platform) layouts.
LinkedIn's move away from HTML5 I can't explain as well, although they do mention issues with memory management and a lack of good development tools out there. We haven't run into any issues like that but every use case is different. I do know that LinkedIn, instead of using Phonegap, wrote their own native bridge using websockets and a mini web server that would run natively that they themselves admitted wasn't the best approach. I think there's a lot of pressure, especially in large companies, to move to fully native apps these days because of all the negative press about HTML5, so instead of doubling down engineering efforts to solve problems that arise teams are much more likely to take the nuclear option and just rewrite everything in native code (twice!).
So no, it's not that they have a "grudge against HTML or something", it's that they ran into limitations due to specific circumstances unique to their products and strategies and took the safe path of going fully native to guarantee optimal performance at the cost of productivity (IMHO). If there was no native app option, they would figure out clever solutions to their problems from which the entire web community would benefit.
Thanks. How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness.
My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either. Native is more predictable. Your experience is valuable in that it proves the existence of a solution. Would you say your team is extraordinary in its capacity to wrangle with HTML, or is something like this available to your average YC startup, or to most startups out there?
> How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness.
We've had no issues with it so far and I heard the same criticisms you did. If you make sure not to store too much stuff in localStorage (there is a limit for UIWebViews) you should be fine.
> My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either
I get that, but it does overestimate the capabilities and resources of FB and LinkedIn. In the end, they are just developers like any other developers solving the same problems everyone else is, and simply throwing more money at the problem doesn't usually fix things. Keep in mind that there's a lot more pressure on FB and LinkedIn to deliver perfection so they are going to be less likely to "stick it out".
> Native is more predictable.
I agree, and there are lots of other benefits to native as well. They must be weighed against the detriments: having to write the same app multiple times for multiple platforms, having to play by Apple's rules, not being able to update apps for customers immediately (that's a huge problem IMO), working with painful layout tools, etc. As always, it's important to weight the pros and cons before choosing a strategy.
> Would you say your team is extraordinary in its capacity to wrangle with HTML, or is something like this available to your average YC startup, or to most startups out there?
I assure you we are not extraordinary. Anybody with a very basic level of native programming experience and who is competent with HTML5/CSS3 and the latest javascript frameworks (backbone, ember, angular, knockout, etc) can replicate what we did. I think the reason it seems extraordinary is because you only ever see articles about big, trendy companies ditching HTML5. "Small unknown team builds great HTML5 mobile app" just doesn't have the same punch. I also believe there is a bit of religious war going on between web developers and native developers so there's always a frenzy whenever there's a drop or two of blood in the water. Ignore all that crap and just choose the solution that suits both your app's requirements and your skills best.
Our app has a few native ui elements like the top bar, the bottom tabs bar, a quick add control that slides in and out, and Facebook style drawers that expose two other webviews. The rest, however, is done in pure HTML/JS/CSS. Angular.js, in fact.
It runs well on old android devices with 2.2 installed, and runs really well on newer Androids and iOS devices. We take full advantage of the benefits HTML5 provides. Most of the user's important data is cached in localStorage so the app loads very quickly. We use websockets to update the app in realtime without the need to rely on long-polling or native push notifications (which we do still have). We have one stylesheet with zero platform specific hacks thanks to the fact that Android and iOS devices use webkit browsers. And laying out our app's interface in CSS/HTML is much more efficient than doing it twice either programmatically or using nib/xml layouts.
We even use http://www.tidesdk.org for desktop native apps and of course that version runs fantastically. We didn't start out using Angular.js on our main web app, but we are slowly starting to transition our mobile app codebase over to our main web app codebase. At some point we will have the largely the same code running across all major offerings of our product.
Every time one of these splashy articles about a well known company moving away from HTML5 comes out I smile knowing that the FUD it will inevitably create will allow those of us who are benefiting immensely from using HTML5 for mobile to continue to enjoy our productivity advantage.
For those who are curious, our product is http://kona.com and the mobile apps are both available in the store. I'd be interested to hear any feedback about how well the apps perform (my email address is in my profile).