What Facebook says about HTML5 mobile apps

“We’ve tried in the past to just build web apps that we could wrap in thin native wrappers, but it doesn’t work. […] Anytime somebody tries to reimplement a native widget using HTML, CSS and JavaScript it always feels like shit.” – Tom Occhino while introducing Facebook’s new React Native

It’s exactly my experience since I started developing mobile apps four years ago. Therefore, I focused on Appcelerator Titanium which does for years what Facebook tries to do now.

Nevertheless, at the moment I’m developing a BlackBerry 10 app using HTML5, and I’m quite satisfied with the outcome – but only because it’s a relatively small app that only needs to store small amounts of data on the device, and where small UI glitches are acceptable.

But in the end, there are UI glitches. Like a bar at the top that should be fixed, but scrolls with the content for a small moment before it’s being placed at the top again. Or small, subtile differences in transition animations. On the other hand, I like that I can control the UI as much as I want – since it’s only HTML that can be modified at any time using JavaScript.

So it’s as always: there is no “one solution that rules them all”. HTML5 apps are fine in several cases. But if you want to develop huge, complex apps I’m sure an approach like Titanium is the better way. And if you want to synchronize with Notes, you need to do it in Titanium anyway, so that you can use DominoToGo.


6 thoughts on “What Facebook says about HTML5 mobile apps

  1. I have switched completely to develop native mobile apps only. Especially when developing huge and/or complex apps it becomes very painful to develop them with a frameworks like Titanium.

    Most of my customers want to support only one platform, that’s why “runs on multiple platforms” isn’t an argument for me.

    • Yes, for your situation native development seems to be the best fit. In my case, I have more restrictions:

      – customer’s developer want to understand and maintain the code, too (and the dev mostly knows XPages/JavaScript at most)
      – multiple target platforms, if not today, then they want to have the option for the future

      And personally, since JavaScript is used everywhere today, I see no point in investing time to learn Objective C or Swift when I can use that time to become a better JavaScript developer.

      I like Titanium especially for complex projects, since Appcelerator’s Alloy framework allows very nice code organization and architecture. Nevertheless, there are limits with Titanium – when it comes to games or that kind of graphical stuff.

      • Javascript is very platform specific: For example the SSJS engine of XPages has nothing in common with the Javascript engine provided with Node.JS.

        On the other hand, if you are familiar with Javascript, you will notice that it looks similar to Swift (The ECMA 6 version which is not supported in Titanium as far as I know).

        As soon as you want to “migrate” your existing applications to another platform, you will notice that this won’t be done by just compile it : There are different UI patterns, that’s why you have to re-design your apps to match the platform specific “rules how they work”. You will have a lot of effort to run your working application to another device that the benefit of developing it with a framework with Titanium get’s lost. That was my experience in the last years…

          • René, I know you’re deep into native development and you’re feeling very comfortable with it. Nevertheless, take the average Notes and XPage developer – how much time would he need to invest until he mastered Objective-C? In my opinion, this is wasted time in many (not all) cases. And there are developers that are willing to learn JavaScript because they know that it’s mandatory these days. But native development? They don’t have the time to learn that. And they don’t see the personal benefit, since their main job is not building apps.

            An to migration to another platform: I’m aware that different platforms have different UI patterns. And yes, you will need to write code to handle the differences. But what’s with the backend?
            For example, one can take my entire Titanium Domino synchronization framework just as it is for Android and iOS (and in the future, for Windows, too). So for the complete synchronization part you don’t need to change a single line of code.

            It’s the same for all other backend stuff. Database operations, event handling, internationalization and so on. In Titanium, you can use *exactly the same code* in exactly the same project for both platforms.

            In my experience, Titanium apps for iOS and Android share about 80% to 90% of the same code. Including support for platform specific UI patterns. That’s a lot of code and saves a lot of time.

            With native development, you cannot do that. You can adapt the logic, but you need to write new code. And furthermore, you need to implement each fix and each new feature in each code branch. I cannot see the advantage in that, sorry.

            But yes, all the comfort comes for a price. With a framework like Titanium you’re always bound to limits. Having said that, in several projects for several customers I did not bounce against these limits. And if, there is always the possibility to implement a module in native language and use that from Titanium.

  2. I am sorry, but your whole argumentation shows how you rate mobile development for companies: It is a “nice to have”, but not a mandatory discipline. Sure, the data must be viewable ( and maybe editable ) while on the road, but a mobile device is an add-on, not the primary working tool.

    But that’s why you are right: If you just want to show some data, and edit a few fields, then it makes no sense to involve some mobile specialists or learn how to do it right: Just ask the domino developers in your company, and they will create some nice apps which fullify your requirements. And these developers does not need to deep dive into mobile development topics; they can solve this “additional requirements” easily with Titanium and Domino ToGo.