1. HTML5 is NOT better than native, but it rarely matters
Despite what I said above about HTML5 mobile applications performing just as well as native mobile applications, high end native applications still have the potential to be better. The pareto principle, or the “80/20” rule, applies really well here. With HTML5 you can create an app that feels and performs about 80% as well as a well designed native app. If you want, or the clients wants, that last 20% – the beautifully smooth and magical experience – it’s probably going to cost 80% more.
HTML5 does a great job across most platforms which drastically reduces cost by only having to develop a single version of the application, but to get a perfect app, an investment into developing native applications for each supported platform will be required.
I’ve turned down clients who seemed to want a Facebook level experience within their application, and told them that if they want that level of polish then HTML5 is not the answer. Often though these are the same people that don’t realise the level of investment required to create an application like that. HTML5 can do some amazing things and Fastbook by Sencha is a great example of this, but the engineering required to get that level of quality would be out of reach for most developers.
Some people have the impression that because there’s a general consensus that native is better in terms of performance, that a HTML5 mobile app will be sub standard or poor performing; “if you want a real app then you should go native”. The fact is though that in the majority of cases you wouldn’t even be able to tell the difference, only when it comes to these high end apps where companies spend tens of thousands of dollars or more creating the perfect experience. A well designed HTML5 mobile application can outperform an average native application, and a lot more apps are using web tech these days than you probably realise (Netflix being one of the bigger “out and proud” HTML5 users).
When dealing with clients though, by far the most common thing I’ve noticed is: they do not care if it’s HTML5 or native. In fact, despite explanation, they rarely ever understand the difference. Deliver what they want and they will be happy no matter what you make it with.
2. It is possible to create iOS applications without a Mac
It is an extremely common misconception that you need a Mac to develop iOS applications, even if you’re using HTML5. This is not true.
You couldn’t be blamed for thinking it though, most tools will tell you that you need the iOS SDK only available on Macs to build for iOS.
By using the PhoneGap Build cloud service to build the application (this avoids the requirement of having the SDK as the application is built on their end, not yours) and using OpenSSL to create a personal information file necessary for signing your application (which otherwise would require a Mac to create) you can easily create iOS applications on a Windows machine as well.
3. You need to use a HTML5 framework, and you need to choose a good one
As a caveat to the first point, if you’re not using a decent HTML5 mobile framework then your app will be nowhere near as good as native. You should never attempt to build a mobile application without using a UI framework like Sencha Touch or Ionic, except in very specific circumstances.
Even still though, some frameworks are just not as good as others and may not perform that well. There’s so many available today, and of course some are good and some are bad. I can tell you that from my experience Sencha Touch and Ionic are both well performing frameworks and you won’t go wrong with them. There’s still plenty of frameworks that I have never even been able to take a look at though.
The amount of frameworks available is a double edged sword. It’s great that there’s options out there as it increases competition between the frameworks as they strive to be better than their competitors. At the same time though, it’s possible that a framework you have chosen to use may stop being actively developed, it could be overtaken by a competitor, something completely new could come out that blows it out of the water and so on.
As a technologist you’re probably used to keeping up with all the latest developments and constantly learning new skills. Native developers don’t have to worry about these things though (well, to a lesser extent at least), as the language the device uses never changes.
4. HTML5 can do EVERYTHING native can do
Technically speaking, HTML5 by itself can only do what the browser can do. When compared to everything a native application can do that isn’t a lot (a browser is very sandboxed).
With PhoneGap though, that doesn’t really matter. The browser can talk to PhoneGap and PhoneGap can talk to the device, so the browser has access to everything that a native application does. The process may be a little more convoluted, but it’s certainly possible – and since there’s PhoneGap plugins available for just about everything you’ll ever need to do it’s pretty easy to implement native functionality.
If you want to learn more about PhoneGap and PhoneGap Build you can download my PhoneGap Build Quickstart Guide for free.
5. There are elitist native developers and defensive HTML5 developers
Some native mobile application developers portray an attitude that “real developers” code native mobile apps. Some HTML5 mobile app developers get defensive of their chosen tech and also go on the attack. This creates an extremely toxic environment that’s completely unnecessary.
I think a lot of the animosity boils down to the fact that developers on either side of the argument are scared that the time they have invested into their tech is going to become redundant. There’s benefits to using both in different circumstances, so to outright dismiss either option is not reasonable.
As developers, we often pride ourselves on our knowledge. It is easy to associate your self worth and identity with the skills you possess. Criticism of your chosen tech can often feel like a personal attack.
If you’re getting into mobile application development – or anything really – always keep learning and approach everything with humility. Research the pros and cons of different options and don’t believe everything everyone says, as they often have vested interests.
6. The DOM is the biggest determining factor for performance
The biggest limiter of performance for HTML5 mobile applications are DOM operations. The DOM, for those uninitiated, is the Document Object Model – it is essentially a tree of nodes that represents the structure of a web page.
As the DOM becomes more complex (more elements, more nesting) the tree structure of the DOM becomes more complex and takes longer to navigate and modify.
The frameworks you use will often have smart ways of reducing impact of manipulating the DOM (e.g most good frameworks recycle DOM elements in a scrolling list when they go off screen), but it’s still something you need to pay attention to. Whenever you’re building HTML5 mobile applications always keep this in mind and look up strategies for keeping the DOM as simple as possible.
7. Debugging is sometimes awesome, sometimes difficult
The benefit of using web technology to build mobile applications is that you can test it right in your browser – no emulators or devices needed. You can debug in an environment that you’re probably already familiar with, something like Chrome Dev Tools.
Most of the time though, you will also be using something like PhoneGap. PhoneGap can not be tested through the browser since it accesses the native API’s of the device (obviously not available through your browser).
To test any PhoneGap functionality you will need to test on a device, and then things become a little more difficult. You can use something like GapDebug to provide you with debugging tools similar to the browser whilst your app is installed on a device. This makes it easy enough to test, but the annoying part is having to create a new build with PhoneGap and install it on your device to test any changes.
NOTE: When testing with GapDebug, if your app isn’t working and there are no errors in the console, try this:
- Open up the debugger for your app
- Wait for it to load
- Go to the ‘Resources’ section and click the refresh icon
This will ensure the debugger is active when your app is starting up, so you won’t miss any errors that occur right at the start. It’s very common for HTML5 mobile applications to get stuck at the start up screen when installed on a device (but not when run through the browser) – this is usually because some error is occurring on the device that you can’t see (usually related to a PhoneGap plugin).
There’s certainly a lot to know when it comes to building web or hybrid mobile applications. A lot of this is technical stuff like “how do I pull in data from a server?“, but as I’ve outlined above, there’s also a lot of conceptual differences between native and web.
The conceptual stuff can be quite hard to figure out initially, and it took me a while to understand what was going on behind the scenes or why things were done a certain way. Hopefully this can give you a bit of a head start if you’re going through the same things.