Xero ditches HTML5 in favor of native iOS and Android apps
thenextweb.com
thenextweb.com
However, the freedom you gain in designing a common UI across all mobile devices you will now lose with having to build discreet applications for each platform.
iOS applications have a really high bar for slick UI and subtle animations. (If they are going to be featured and successful.)
Android applications also have a really high bar for system wide integration. Plus, UI that works on iOS will most likely need to be rethought on Android, though not always.
Then for Windows 8/WP8 devices you're in for a world of hurt. The UI and strict guidelines are so different from anything common in iOS & Android that to include them will require what could likely result in an entire different design team.
Personally id use Xamarins excellent C# tools to build the core of the app multiplatform and then utilize the native APIs to build platform specific UIs. I dont think this approach is alot more/less work than making your webApp work with all platforms and resolutions, but in the end you have a native experience on all of them.
But I have to acknowledge that he has made a very good work with Mono and although I prefer to use C++ on my hobby Android projects, Xamarin's tools are a great approach for many developers.
That aside, mostly i care about the best tool for the job and in this case thats my choice.
I think most front-end devs are so used to it now, that it doesn't seem bizarre to build tabs with a list element, float the items to the left, add a clearing div below the list, etc.
But instead of doing another complete 180 we decided to instead go with a hybrid approach like LinkedIn did - use native when performance is key, and HTML5 everywhere else. We just re-launched the app using all custom html5/js/css and native ui elements and animations where necessary and it was a complete success. Not only does the app perform really well on even very old Android phones, but it absolutely flies on newer devices. The best part, especially when compared to using Sencha, is that all of our code which was written in angular.js will be used on the web app and native desktop apps. We are very close to having the vast majority of our code being shared between every major platform our users may use.
I love when articles like these get popular because it scares people away from using HTML5 in any way and gives us a clear advantage. Keep fueling the FUD, we'll keep our productivity advantage :)
For instance, did you scrap all the work you put in with Sencha and start from scratch? And how did you go about combining native elements and html/js/css, and how did angular js tie into this?
For JS frameworks we decided between Backbone.js, Angular.js, and Can.js (because we had previously used JavascriptMVC on our web app). We fell in love with angular.js and went that route.
The main reason to use native UI components is to allow smooth scrolling on older Android devices which don't support fixed elements like top and bottom nav bars very well. Both on iOS and Android the top navigation bar and bottom tab bars are done in native code as well as the Facebook-style drawers that reveal other sections of the app. In all, we use three Phonegap enabled webViews and three major native UI components (top bar, bottom bar, and a custom "quick add" control). We pass messages back and forth from the native app to the javascript app via phonegap's native bridge, like when a user taps a native button or the javascript app changes tabs and needs to inform the native app.
We used grunt.js to help manage all our development and build workflows. It concatenates our files for us, creates separate builds for iOS and Android (and other platforms now, too), compiles and minifies our CSS, etc. It also runs our test suite which is another big advantage to using HTML5/JS instead of native. Most of our code has test coverage and it's very easy to automate using grunt.js and testacular.js.
If you're interested you can check out the app on the Play and iTunes App stores; it's called Kona Mobile (it's the mobile app for our main offering, http://kona.com).
The discussion is about apps written natively vs apps written in HTML (not web pages viewed in safari). The only method available to develop an iOS app with HTML is to use UIWebView, which is crippled compared to Safari.
Support for ordinary CSS properties like z-index, position:fixed and iframe is pathetic. Some of the things that I can recall now. UIWebView takes it to another level of pain altogether.
They can be pretty close because web apps are ultimately just duct tape over native code. Further I doubt Apple's lack of JIT for app-contained webviews has any material effect: JavaScript performance is grossly overconsidered, when most of the performance issues are DOM/layout problems (e.g. scrolling long lists).
LinkedIn to this day remain the perfect example of how to build a straight-up HTML5 mobile app that performs beautifully.
After making a big show about their web-based mobile app, LinkedIn started recanting and replacing major components of their app with native code, so they aren't the best example.
But ultimately a lot of the people who cheerlead these sorts of discussions don't realize how little it has to do with what they do, because these people are talking about optimizing those final few percentages.
Anecdote time, but I was involved with a team of 6 devs making some basic fund reporting tools when a breathless product manager started talking about how we should build iOS and Android apps because someone had told them about LinkedIn's pronouncement that their "power users" preferred their native rebuild. A tiny, grossly underequipped team that nonetheless managed to make a pretty kick-ass web app that actually worked great on pretty much any device people could have (including rich graphics)...yeah, fire up the iOS team to divert resources on a native app... It is nonsense.
If you have a software group large enough that you can start optimizing for those edge cases (e.g. scroll a massive list of contacts) where the web apps suffer, then of course you should do it. But for the vast majority of teams simply making a cross-platform web app gets you 98% of the way there.
People trying to force it to work otherwise is just the 21st century version of VT100 terminals.
Every time I have the possibility to choose between a native and a web application on my consulting projects, I take the native approach.
I get a rich experience, better integration with the operating system and overall user experience.
Sadly many MBA's try to cram desktop expectations into what is a document format.
And it became less true when scripting was introduced.
> I get a rich experience, better integration with the operating system and overall user experience.
I won't argue with this point but, as with anything, there is a cost-benefit calculation that everyone has to do for themselves.
Wow, people are still saying this garbage?
Ignoring that we've been evolving this thing for two decades now, HTML was designed for content layout. It turns out that one of the primary issues with applications is content layout (I was building "web apps" that were largely collections of ActiveX controls 15 years ago, as the simple layout rudiments of the platform absolutely blew away anything that was available in any other platform). Indeed, we've seen other "native" platforms borrow much more from HTML than the inverse.
Layout languages exist since the early GUI days, lack of knowledge of their existence is no excuse to use HTML as something it should not be used for.
Any RAD tool with layout managers is still miles ahead of what HTML offers, with the additional benefit of proper operating system integration.
Instead we have layers of broken abstractions trying to bend HTML into something it was never intended to be.
Writing portable clients in the browser is a mixture of CSS/HTML/JavaScript hacks to be able to achieve 100% L&F compliance across all required browsers and operating systems.
Give some examples, please. As someone who actually used pretty much every "RAD" tool (most of which dissolved and disappeared because they were anything but RAD), I call bullshit. Inventing competitors that didn't actually exist doesn't bolster your garbage, Luddite arguments.
Instead we have layers of broken abstractions trying to bend HTML into something it was never intended to be.
And processors were built to process punchcards. Your argument is absolutely nonsensical, and it only plays in venues full of angry, fearful-of-change contrarians.
They do nothing of the sort. This is total BS.
On the contrary they have had (and still have) the speediest and more feature complete web engine.
And for many years the Android built-in browser was a total joke compared to Mobile Safari.
Chrome for mobile (on Android) is better than the Android browser (Browser?), but nothing to write home about compared to Mobile Safari.
I totally agree that Android browsers are a joke even today.
And Mobile safari is not the most feature complete web engine, its one of the least, missing very basic things like indexeddb and spotty CSS support. Chrome / Firefox and Opera all have far more modern support but only for android.
> A HTML5 web app might take a little while longer to
> develop, but it'll work out cheaper than building an iOS
> application
I would say, that it was actually a great strategy. When they started, the HTML version was more than enough. They saved lots of time, effort and resources during these two years while building their product. Now their mobile user base is big enough to justify dedicated teams for all platforms - and that's great for them.
But it doesn't say anything about HTML5 as a viable platform for building apps. If you are a team of 3, where 0 have any mobile development experience, but years of web experience, it surely is the way to go. And often, it will even stay this years later.
Also, "accounting startup"? Xero is a publicly listed company.
if facebook ditches their mobile site, that will be the end of facebook on my phone for me.
But yes, when you're giving all kinds of permissions to strangers, chances are somebody is using your data maliciously.
1. Don't web apps need cookies enabled in your browser, so technically they can still track your browsing history and behavior, at least to some extent? How is that different from your privacy concerns with native apps?
2. How do you think about installing applications on your desktop/laptop computer then, since doing so grants them certain permissions, and not doing so prevents you from doing certain things?
3. More of a comment, than a question. I don't think Facebook will ever ditch their mobile site. Mobile sites are a replacement of the "desktop" site instead of the native app. It's just accessing Facebook via the browser but with a mobile-friendly UI.
The same issues exist with desktop applications of course, for example various spyware toolbars etc so you always have to make some judgement call.
The main difference seems to be that when you access a website on your desktop you are much less likely to get some popup nagging you to download a desktop app to consume the content vs a smartphone app.
I guess because most desktops are fast enough that you can get reasonable performance from just HTML5 or flash.
2. on my desktop, there's no guarantee that any specific info will be in the same place. for example i use thunderbird portable in an encrypted container for my email and contacts. on a phone, your contacts are pretty much in the same place and every app knows how to get to them, there's much less variance.
3. you may have a point, but without a good mobile site, they can coerce people to use the app by providing a shitty experience in the browser, cause an app can get to a lot more of your juicy data which they crave.
This is not about App-Store vs Web distribution, its about real Apps and their underlying tech.
Are you sure?
The browser also has security exploits, being coded in C/C++.
With JavaScript you can also do something similar to fork bombs.
And lets not forget the plugins as well or the JavaScript APIs to access your data.
[1] Honestly, that's an insult to the 1980's. Word Perfect 5.x was pretty damn functional, lack of GUI aside.
Even with frameworks as amazing as Sencha Touch, we’ve found the ability to iterate as fast as we would like has become harder as our application has become more complex. The choice to go with HTML5 was very much a choice based on us – how do we use the skills we already have to build a mobile application? Unfortunately as the application grew we needed to hire to fill out the team, and we were never able to hire fast enough to fill those roles. Ironically those skills were equally as critical for the 'desktop' version of Xero – we were cannibalizing our own team and slowing everything down.
With Xero, it seems more like a case of not being able to find great HTML5 developers and less an indictment of HTML5. This is good news for me.
The reality like this article suggests is it will take a long time to get something that works almost right but isn't right, even if somehow the performance doesn't matter going forward with much faster devices. It gets pretty hard to try and get a webapp to work with native parts of the OS and features that your users might want or expect.