Barry's full question: I’M Barry Burd, professor of Computer Science and Mathematics at Drew University in Madison, New Jersey. I’m at QCon New York interviewing Dave Arel, he is director at JavaScript Engineering at Belly. He gave a talk this afternoon “Mobile Web - So hot right now”, so I’m here to ask him about Mobile Web. Dave my first question is how can HTML5 apps possibly match the speed and functionality of native Mobile Apps?
Sure, so for most cases now if you are just building a normal application you can get near native speeds, when it comes down to it inherently I don’t think JavaScript it’s going to quite match native any time soon when you look at the nuanced benchmarks that doesn’t mean you can't create very performant Mobile Applications using JavaScript, HTML5. It just takes some finagling really.
2. And how much finagling does it take?
Right now the state of Mobile Devices and their implementations of the browser especially when you get into hybrid apps, you know the UIWebView isn’t as good as Safari for example, but there is a lot of black boxes, a lot of undocumented things, a lot of just trial and error to get the right performance out of it, but once you start understanding some of the ways that browsers are implemented, utilizing things like the GPU which processing power is so important on Mobile Devices because there is so much less of it, and so optimizing the use of that can lead to great speeds but the problem is that these browsers are not really, they don’t give you those features without being a bit hacky.
3. What kind of hackiness do you have to deal with?
One of the big thing is compositing, so essentially breaking up your app into layers, so that when you change or re-render or animate stuff, the GPU can handle and redraw that on the screen instead of going through a very extraneous process which is recalculating, repainting and then redrawing those rendering components, and that utilizes the GPU, runs much faster, but the browser doesn’t really have a setting for that, it's not like you can just say in your CSS or in your JavaScript “Just hardware accelerate it!”. Most of the time you are adding a CSS property that might trigger compositing which will enhance the speed but kind of using not necessarily the way it's intended; an example is translate3d , you use translate3d to actually create a 3D transition but instead you could use it just to enable compositing using translate3d(0,0,0) , so it's not actually doing anything, it's just creating a composite layer.
You are definitely limited if you are talking just a Mobile Web App that lives in a, you know, Safari or Chrome and you are navigating in the traditional way, no you can’t access some of same things that native can, you could create a Hybrid App so that the hybrid portion of that can give the JavaScript access to some of these API’s, but that requires you writing some native language code just to do that.
So we did, I will note although that we did create an Android version of it and it’s actually being actively used currently by a hand full of merchants, we decided we didn’t want to go down on that route, we would rather stick with iOS, it was better, we figured that in the long term it was better for us but it wasn’t a reason why we chose HTML5. The reason why we chose HTML5 was because we own thousands of devices that are deployed to merchants all around the country, we are in a lot of the major markets and we just open up a market in Canada. So updating that software, the native software isn’t easy and we sometimes were updating software daily, weekly, sometimes monthly, often, and updating that if it was native it would cost us loads of time and money and if we were to scale, if we are to scale to the size that we want to be, native just wouldn’t work for us, so we had to come up with another solution. What we came up with was a Hybrid App that will actually install different versions of the JavaScript app on the fly whenever we want to push it there.
Barry: Ok, so let me see if I can rephrase what you were saying and understand more clearly, you are developing for iOS, so you don’t have fragmentation issues and you need to scale for basically one platform, different releases, different generations of that platform and you still feel that developing native iOS code wouldn’t be the way to go.
We would have to rely on, let me preface with the fact that we locked these iPads down, so the merchants themselves couldn’t even if they wanted to update any of the software. We do that so that we ensure that our application is running at all times, and some clerk at at a 7-11 isn’t checking their email or playing a video game. So you can’t physically update it, manually the merchants couldn’t update it, but even if they could they probably wouldn’t as often as we would need them to, so we either have to call them and walk them through the process which is quite difficult or send people out to actually manually update them and we have over 7000 merchants, so doing that costs us a lot of time and a lot of money, and how often we want to update these applications it just would not make sense.
So with the HTML5 app we were able to create what we called bool loader system, so it checks, it constantly checks to see what version it should be on, so if we decide that that iPad or our entire network or segmented network, or just one client, one iPad needs to be on a newer JavaScript version, the native portion will actually download all the assets for that particular version, install it on file system and then refresh the web view. Does that make sense?
Barry: Yes. Let’s talk about cost of development, because there are many critics of JavaScript and these critics, to some extend justifiably or unjustifiably, say that JavaScript isn’t the right tool for serious developers and that a real language like Objective-C or Java or whatever platform you are developing for is better in terms of maintenance, better in terms of the integrity of the development and so on and so forth. Do you want to comment on that?
Yes sure, I look at JavaScript as a legitimate Programming Language, you can do some incredible things and we are seeing people do some incredible things and I think because of the massive amount of desire we'll see even more incredible things as time goes on, but JavaScript gets a bad name for its history for some of its quirkiness, I mean there is not really like any other language and there is some downfalls for sure. I mean if you look at the language in a whole and you look at the good parts of JavaScript it’s a slim section of it really and there is a lot of quirkiness that a lot of traditional programmers are not used to, so it’s the kind of beauty of the web though, web developers have always sort of dealt with things like this, and they deal with browsers, they deal with all kinds of quirks, so we sort of, I guess, accepted that.
So if you are going to develop a Mobile App and you’ve never done it before?
Barry: Well I’m just taking the brute force approach. What is the typical mistake that developers make that gives apps that aren't as performant as they should be.
So I see a lot of web developers think that they can tackle a Mobile Web app by means of the processes that they're used to, the tools that are used to, sort of the same paradigms that they are used to, but the fact is we’ve become so comfortable with the processing power and the tools that we have available to us on the desktop, and so once you move that over to the Mobile Web there is a lot of things that happen that you would never expected, because you’ve just haven’t had to deal with it before, maybe due to just the quirks of that environment or the low processing power.
For example when it comes to rendering performance, the rendering performance is incredibly slow, unless you make use of what I was mentioning before, the compositing and make use of the GPU, but also memory, I mean it’s rare for most web developers to ever consider memory because of the massive amount of memory that we usually have on the desktop, which is you know, can easily, quickly slow down any mobile app. So you kind of have to stop thinking about being a web development in the same way, I tell people to start thinking like Mobile Engineers. Mobile Engineers will think about memory, they’ll think about the GPU, they’ll think about those things and it’s a little more hacky for us to do it but as long as you are looking at those things and experimenting with it and with those things in mind, you’ll start to develop some techniques for dealing with some of those things.
It really depends I think on what you are creating. For us almost the entire UI at least is JavaScript, is HTML5 from the WebView, except you know maybe the scanner which we couldn’t access through the WebView, so we had to create a plug in to allow JavaScript to control the native camera and position it and tell it when to activate, when to deactivate. But you know there is a lot of things going on in the background that we couldn’t have done in JavaScript and we didn’t want to do it in JavaScript because we wanted something that was very stable, very quick, maybe it can happen on a separate thread things that wouldn’t interfere with the user interface.
But there are instances where it might make sense to create a list view in native because it just works so much better and you don’t really want to spend the time to figure out how to deal with the memory issues of loading contents so quickly. I think both Facebook and LinkedIn when they build theirs, I think they used some of the UI, I believe was native not a WebView, but for us we just decided we want as much control over the application as we can, so let’s do as much as we can in the JavaScript side of it, particularly with things that the member interacts with it, the people that are using the system. It's really hard to say, I mean I don’t think there is ever a case where it’s like, there is a hard number that you should stick to, I think it just depends on the app.
So back when we originally developed it a lot of the JavaScript frameworks, it’s not quite like it is now, there is a lot of them for one, but there is only a couple of that really stood out and Backbone was a clear winner for me at that time as sort of a framework for building it, but Backbone is very slim so it doesn’t do a whole lot for you, it’s sort of the main structure and we had to build our own custom framework on top of that, it’s a very slim framework on top, but it’s incredible the organization that gave us, a lot of the automation that gave us and some performance enhancements that it gave us, not performance enhancements but allowing us to make good performance choices because of the way it was built, and for example one of those things was the utilization of document fragments, so inserting things in the DOM constantly is very expensive, it causes reflows.
The DOM is not exactly the most efficient and performant document, so we wanted to avoid that as much as possible, so we broke everything out in small components, every little view is its own component, with its own controller and when we needed that to be inserted into the DOM it would be any of its child components, anything that was surrounding it, its children, its parents were all compiled into one document fragment, and then I can do things like pre-cache references to elements that I needed or setup event listeners prior to it actually accessing the DOM, all in memory, and so that was very, very fast and then injecting that at once causing only one reflow. So things like that I just focused on building a framework that works well for the performance in Mobile.
We looked at a bunch of things like JQuery Mobile, I can’t even remember some of the names, I mean Angular hadn’t even come out or at least it hadn’t been announced really. Ember was around, but Ember I think was trying to do more than what we wanted at the time, and Backbone just seemed to fit, and so we also use Zepto so that we didn’t necessarily have to create our own library for DOM manipulation or we didn’t have to do it natively which we could and there is probably the best decision but we do that when there is a performance hit, for the most part, Zepto worked really well for us.
9. What made you reject JQuery Mobile?
JQuery Mobile was trying to be the solution for all devices and all we wanted was to support iOS, and they would make decisions that would affect iOS, that would make the performance, there is a performance impact just so that they could support Blackberry or older Android devices or whatever they are supporting. So there is a lot of legacy code there and they are making decisions based on that and we wanted to be very, get the most performance that we could out of iOS.
Barry: Dave thank you so much for your insights today!
Thank you!
Community comments