2. In your opinion, what are the most important stumbling blocks to the use of hybrid development?
The one that commonly comes up is performance, and I would say the other big one is debugging, so performance has notoriously been a problem for hybrid development and I think that goes back to the bad or older phones that were out there, some older devices where hybrid development was just terrible, it really didn’t perform well.
In terms of how you can actually overcome that, you look at some of the libraries that are coming out today, things like Ionic and Kendo UI Mobile, there are some UI frameworks that are specifically designed for building these hybrid mobile UIs, they take into account things like using a fast click to get around the 300 millisecond click delay and building some really responsive UIs because if you go back a few years when you developed a hybrid mobile app you would use the exact same technologies that you would use to develop a web app, which works just fine, it’s still the web, so the same libraries will work, but having a library that is specifically catered to build a certain hybrid app can overcome some of the problems that have historically been associated with it.
The other stumbling block I would say is debugging, this is another pain point. I remember when I started hybrid of PhoneGap type stuff I would basically use the same debugging techniques I would use when I was developing for IE6, very archaic, old browser, alert or something like that. The story is far better, I think the single biggest advances in hybrid debugging have happened on iOS and Android because they’ve recently introduced remote debugging that’s basically built into the platform itself, so as of iOS6 you can go in and enable the web inspector on your IOS device and then you can go use Safari on your desktop machine and basically use the same dev tools that you would use to debug a web app from your Safari desktop machine, which is really powerful you can do things like browse the DOM, play with CSS, see the network stack, things that JavaScript really doesn’t have access to.
The same thing is true for Android as of 4.4, since it’s now Chromium based, you can use Chrome dev tools on Android to debug hybrid Android apps, which is also really powerful and gives access to all those dev tools, but the one unfortunate part is that if you debug say older devices, like Android devices, say pre-4.4, which is still the majority unfortunately or if you’re debugging say Windows Phone or Blackberry, the story still isn’t all that great and the whole advantage of hybrid is that you can reach these platforms, so there are some problems but it’s getting better over time.
3. Isn’t debugging in general a difficult and thorny problem when it comes to JavaScript development?
It’s something that’s gotten better over time. Like I said, if I think back to when I first started with the IE6 days, the debugging story there was pretty much nonexistent, but the web tooling has gotten substantially better, just look at what the Chrome dev tools offer, we have step by step debugging, we have pretty rich tools, Chrome dev tools can take minified JavaScript tools and un-obfuscate it for you and still preserve the line debugging, see variables, change them on the fly, you can even do that with mobile apps and these hybrid mobile apps now today too. It still has a little ways to catch up I would say, I did Java development before I got into the web world and I know there are whole suites of debugging tools dedicated to whole areas of that and I think those have some advantages especially when you look into things like tracing down memory leaks, for instance, I know that’s a common problem in hybrid apps because they stay open for a while. So there are things like that were the web still needs to catch up a little bit, but the story is far better than it used to be years ago, it’s getting better all the time.
4. You mentioned something called a fast click, can you tell me what that is?
Yes, this is an interesting story, it kind of goes back to the original iPhone and the original iPhone, the engineers that were designing it had a problem, that the web was not designed to work on a 320 pixels wide screen, it just wasn’t. So the engineers at Apple came up with this nice convention, you could double tap on the screen and zoom in on the content, so you’d go to New York Times, you’d see a story and say oh, the text is super tiny but then you could double click on the screen and get it to zoom in. And you’d have this whole algorithm that actually works quite well.
The only problem was in order to support that double tap gesture, any time you’d have to tap on the screen, it has to wait just that little bit of time to make sure you’re not doing a double tap and the time the browser picked was for whatever reason 300 milliseconds that they determined that’s how long you needed to wait. So you just click a button on the iPhone to this day it will wait 300 milliseconds before that click triggers in JavaScript and you get a react to that. And users can actually perceive that delay, 300 milliseconds is within the time frame that people can tell, studies have shown that somewhere around 100 milliseconds is the limit of human perception when they can actually tell. And it’s been one of the reasons that hybrid apps or even mobile apps have been considered slow historically, because every time you click or every time you touch something it’s subject to this artificial delay.
Now, there have been certain things done in this area, most recently version 32 of Chrome implemented a way that you can use the meta tag, the viewport tag and if you set that appropriately you basically get rid of the double tap to zoom and when the double tap to zoom goes away you also lose the click delay, so that speeds things up as well. Internet Explorer has some other ways around it, is through the use of their pointer events, they don’t support the meta tag usage unfortunately, but there are still some ways around it, Firefox recently announced they are going to support the meta tag usage and the meta tag viewport as well.
So the one big holdout here is Apple and they still haven’t announced any plans to get rid of this and so in order to that you need to do some sort of trickery in JavaScript because when you do tap on the screen you get a touch start event but managing that start touch event also the click events and reconciling that across platform is kind of crazy and that’s where a library can actually help you with that, it can kind of normalize it so can just listen to one touch event and know that under the hood it’s doing magic to make that response instantaneous and still work across platforms.
A lot of people don’t realize that when we think of Cordova apps or PhoneGap apps or hybrid apps, whatever you want to call them, we tend to think of certain things like the camera, the accelerometer, those trendy type things, but a lot of apps don’t necessarily need that stuff, but I think a lot of people don’t realize that these platforms expose a bridge, basically a bridge where you can execute native code in JavaScript which is actually how Cordova works underneath the hood, it basically goes down and says OK, you can deal with these native APIs.
So, any API that’s available on a native platform you can get at from a hybrid app, but of course the reason you picked to make a hybrid app is because you want to write web code and as soon as you start to go down that route and look into the bridge, it kind of defeated the purpose because you’re getting into the native code at that level and that’s what projects like Cordova try to aim to do, to normalize that for you and there is the Cordova plugin ecosystem so people that have written these plugins to access these native features and such that are available.
Cordova plugins, unfortunately, are kind of hard to write, the people behind Cordova, it’s a really amazing project because they basically take the work of knowing all these platforms out of, basically, it’s no longer your concern because they take care of it for you, but it makes third party plugins extremely difficult to write; I come from the jQuery project and one of the reasons for the jQuery project’s success is it has a vibrant plugin ecosystem, there’s tons of jQuery plugins, they are extremely easy to write, so you can a jQuery plugin in a few lines of code, you can see it, you can put it on the internet and anyone can use it.
If you are going to write a Cordova plugin, first of all you need to know these native platforms, so even if you wanted to support one platform you have to know how the bridge works, how the native API works, also you have to know how Cordova works, but then if you want to make a really good plugin, all of a sudden now you have to know not only how Cordova works, how that platform works, but also how other platforms, and how iOS and Android and Windows Phone works, etc.
As such, Cordova plugins are still there are some good ones out there but it’s hit or miss it at the moment and it will be interesting to see as an ecosystem if there is actually demand for these hybrid apps, if that ecosystem can take off a little bit and you can get some better, more premium plugins to make that device access easy, because right now that is a stumbling point and it can be tricky, especially for people who are just web developers and only really know the web APIs.
Barry's full question: You said the reason for doing hybrid development was because you want to use web development techniques. My understanding is the reason for doing hybrid development is because you want to develop for many platforms at once. Is my understanding incorrect; are there other reasons why someone would go to web development as opposed to native development if they wanted to target only one platform?
The reason is kind of both. It is because you want to write in web technologies, but you also want to reach multiple platforms. You can absolutely use hybrid for a single platform, if you just need an app to meet some purpose and you need some sort of device access or some sort of device API, you can absolutely use a hybrid approach to build for that single platform. But the real advantage and why I think most people use hybrid is to deal with the cross-platform nature because trying to reach all these platforms manually is kind of crazy.
I used to do Java development and I feel I have a pretty good grasp on the Java language and even when I try to write an Android app for me it’s like I’m not really capable of much more than Android 102 because my knowledge of the Java language is in a certain subset of that development when I get into the actual Java code, but there is so much more that goes into an Android app, you have to understand the ecosystem, the SDK, how that works, the configuration files, how you build apps, how you deploy apps, all those type things and taking a hybrid approach although you are not losing all of that, it certainly makes that process easier, so it can work for one platform but you are going to get a lot more bang out of your buck if you built across platforms.
Barry's first question: One criticism that I’ve heard of hybrid development is that since performance can be a problem, a developer has to develop not only with the functionality in mind, but also with many different workarounds for the various things that can go wrong performance wise. So a developer has to take on two roles not only think about the problem, but also think about how to optimize the problem at every step more so than with non-hybrid development. Is this a valid criticism?
It is. It’s kind of necessary to the platform that you think about what you are doing a little more than when you are doing it straight in native code, when you’re in native code you have some expectation that that code is going to perform half-way decently and in hybrid you have to be cognizant what you are doing so that you don’t introduce too many performance issues. But it kind of depends on what you are building too, because there is the whole spectrum of different apps where maybe you are building something internal for your company where performance isn’t really all that critical, you just need a little thing to manage widgets inside your projects, if you have a little click delay or things don’t work, it’s better to just have a functioning app than it is to worry about the performance.
But on the opposite end of the spectrum I mean if you are building something for the public app store, it’s vital to your business model and something that your public users are going to use and generates revenue for you, in that case, native makes more sense and you could go down the hybrid route but if you chose to do the hybrid route in that situation where performance is critical you are going to have to be very careful with what you do and know some of these performance best practices, you have to be more cognizant in event than if you are going native in that situation.
Yes. There is basically this bridge between the web world and native, so you can do any number of things with hybrid development. So to start the part that most people are familiar with is the Cordova/PhoneGap approach and under the hood what that’s doing is when you start up your app it brings up a web view, so all these platforms have some form of web view API, it’s called UIWebView on iOS and I think it’s just called a web view on Android, but Cordova is basically building that web view for you, it’s launching it up and takes your little chunk of web code, places it in that web view and that’s your application, so with that approach basically the web view is the entire app.
But there are different approaches as well, there are some apps that are taking really unique, hybrid approaches where the app’s somewhat native and somewhat hybrid, if you look at the iTunes app on iOS, for instance, the header and the footer are actually running as native code, so you get the native skin and such but the core of the app, the content is actually just a web view, it’s running with the web underneath, so it’s interesting to see apps do that. I think iOS does that, for the content they can get the benefits of the web, some of the layout the rendering and also the ability to dynamically update.
Apple can update iTunes without having to push out an app update and in their case an entire OS update perhaps. So, certain apps are kind of experimenting with that, I’ve also seen some apps reuse some of their website within the app, things like Google now kicks you out to the web to do your login, for instance, so they’ll send you to that, they’ll return some sort of OAuth token or however they actually implement that, takes you back into the app to log in, certain sites do it for help content as well, you need some help, it will just kick you off to some web view within the app, so there are different flavors of that.
The other spectrum of that, when I talk about hybrid, at least, I usually consider hybrid to be the web, mixing web code with native code, but there is also the cross compile option which is you write code in one language and you produce native code on one to many other platforms. So you can take Xamarin, for instance, and Xamarin lets you write in C# for instance within Visual Studio and you output, iOS and Android and Windows phone I think they support other platforms. Well, there is also Titanium does this, you write JavaScript and you deploy multiple apps, I think AppGyver does this or Titanium, I should say Titanium does this, so there are a couple of different approaches to doing this in different languages to reach these apps. Now in terms of which I would recommend and what I would do, it kind of depends. If you take the Xamarin example, for instance, if you know C# and you’re a fan of C# then it’s probably in your interest to at least check it out and see what it does. The one problem with the cross compile solutions is in my mind you are kind of tying yourself to these APIs that actually run to hit these multiple platforms which could be a good or a bad thing, but you are kind of investing in that platform's success.
That’s one of the things that I like about the web based approach is even though to are investing in a technology, you are investing in the web which is a set of open standards and you can feel reasonably assured that the web isn’t going anywhere, it may change, sure, but it’s not going anywhere. Some of these companies and some of these APIs might, but the cross-compile solutions do give you an elegant way of reaching these platforms and they also produce native code, so whereas the Cordova based approach is kicking up this web view which kind of takes over the app, that’s not happening with these cross-compile solutions, you’re getting native code, you are going to get better performance out of it as well, so there is something to be said about that, too.
Barry: Tell me about jQuery mobile.
jQuery mobile is a mobile development framework and it’s been out three or four years now, it was kind of started by the jQuery project when the mobile device craze really started to take off and the aim of the project when it started was basically to support everything, it really takes a progressive enhancement approach to application development, so it will fall back to work on pretty much any device, you might not get the ultimate experience on your old crappy Blackberry device, but your project should work. And that was an important goal of the project and over time it evolved into trying to be a little more robust, trying to use more performant transitions, to make more performant apps, build some UI components to help you build not only for mobile, but really for any device.
If I had the answer to that question I’d be hitting the stock market or something right now, but it’s interesting because especially for hybrid development and whether it’s going to take off, if you look at analyst reports and Gartner reports and the reports CIOs read and such, they are really convinced that hybrid is actually going to increase and take off and they especially think it’s the way that big companies are going to reach mobile, with the same idea being that hybrid code is never going to run as fast as native code, there is always going to be a gap, you can debate how big that gap is or how much it exists, but of course it’s going to be slower, but if you’re a big company that might not even matter, you might not care, the app might just be performing good enough.
So these analysts reports actually think that hybrid is going to take off, I’m a little more skeptical, I don’t necessarily see it take off but I think it’s going to continue to be a viable option for people especially people who want to take this cross-platform approach. I think with mobile just continuing to rise, we’ve all seen the charts that show mobile’s grow related to traditional desktop computing and that line isn’t going down, so I think what we are going to see is a continued fragmentation of approaches. If we look at how we can build, say, web apps today, you have all these different options, all these different technologies to do so, we are seeing right now a slew of companies heading into mobile, so I think will see a variety of different approaches, they could be different cross-compile solutions, they could be different ways of mixing hybrid code with native code, it could be more libraries that target native directly, web code, I think we’ll see a variety of options, so I think it’s going to be a little harder to tell, I don’t think we’ll see one approach winning, I just see a bunch of approach proliferating.
TJ, thank you so much for talking to us today.
Thank you.
Community comments