Blurring the Lines Between Native and Hybrid

October 11, 2015 0 Comments by

Native and Hybrid

There are a lot of unknowns plaguing the industry of native mobile application development. Native applications are written in Objective-C, Swift, and Java. Hybrid applications are written in HTML5 and JavaScript. Some people think that hybrid mobile applications can't compete with native. Some organizations refuse to consider hybrid either because they have an existing sub-par implementation or potentially due to lack of knowledge. Hybrid apps won't be able to perform as well as native, but since the majority of applications don't push our devices to the limits, this may not make a difference.

Technically, it’s simple. The web cannot emulate native perfectly, and it never will. Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable.
Web vs. native: let’s concede defeat

If you're going to start green field in building a mobile application of your existing web application in iOS and Android, you owe it to yourself to understand the implications and the limitations. The best decision a couple years ago may not be the best decision today. Native applications implemented poorly can easily perform worse than hybrid applications implemented properly. In this case you would blame the craftsman and not the tools.

When Native is Better

We want all of our interactions to be silky smooth. In cases where you need to have a lot of stuff going on, a lot of moving pieces and processing, like in games, native is a surefire. That doesn't mean we can't do good games in HTML5. A couple are linked below.

Modern browsers try to refresh the content on screen in sync with a device's refresh rate. For most devices today, the screen will refresh 60 times a second, or 60Hz. If there is some motion on screen (such as scrolling, transitions, or animations) a browser should create 60 frames per second to match the refresh rate.
Jank Free

That's all we have to do, make sure to watch the frame rate. A couple years ago at the jQuery conference in Toronto, Addy Osmani did a talk titled Gone in 60fps. At that time this was only available in Canary. He scrolled through Pinterest and demonstrated how slow it was, the concept of jank. He then disabled CSS3 and the scrolling instantly improved. Since then the everyone's talking about 60fps.

If we want a snappy interface, and can't achieve this in the browser, then we need to go full-native.

When Hybrid is Better

The engineering team at Flipboard has proven that we can build snappy interfaces on the web. Their mobile web site has rich animation that moves at 60fps. If it can be done in the browser, you don't care about supporting old devices, and you want to maintain a single codebase, then you might be better off going hybrid.

Native applications need to be written for every single device and every new platform from scratch whereas an HTML5 App allows you to support mobiles, tablets and desktops with the same product.
HTML5 Mythbusting

Startups often operate in uncharted markets, how quickly do you need to move? How nimble do you need to be? Implementing a new feature and fixing bugs in three disparate code repositories will require more resources and take more time.

You won't often come across the technologies used to build an app. Not in the app store description. Because users don't care. They just want a great experience.

This is an important thing to notice because many haters will attack developers on the idea that hybrid applications do not perform or look as good as native applications. This is simply not true.
I've Gone Hybrid

It just so happens that some of the most popular apps are hybrid, like the App Store, Instagram, Uber, and Basecamp.

This highlights the most important, easy-to-forget element of these types of apps: hybrid is the gradient, and it can be done well or poorly.
You're Favourite App Isn't Native

If you decide to spend a year and hire 10 people to work on an Android app, and do the same for iOS, be cognizant of where we will be by the time the app is ready, and also the cost of maintaining, and deploying new features. Mobile dev shops will advocate full native all the way.

..perhaps because they spent so much time perfecting their UITableView chops that it seems a shame not to flex those muscles at every chance.
Hybrid Sweet Spot

Hybrid Apps with Native Rendering

The DOM is slow, we've conceded that. We want to move scripting out of the main thread with the power of hardware accelerated HTML5 canvas. We can also maintain a single source while using native renderers. Angular 2 will be using native renderers and React native already does this. Even native developers are going hybrid.

Fast-forward a couple of months, and I’m confident enough to say I may never write an iOS app in Objective-C or Swift again.
An iOS Developer on React Native

The Power of the Mobile Web

The number of users on Facebook's mobile web app surpasses users on iOS and Android combined.

This is particularly relevant given Zuckerberg's comment that there are more people using the Facebook mobile site than either of its iOS or Android native apps combined.
What Zuckerberg Really Meant to Say

You've heard the famous quote that HTML5 isn't ready, but you may not have heard that the decision to go full native was a political one.

Zuckerberg is correct that today's HTML5 tools aren't perfect, but in this case the problem may lie more with the craftsman than with the tools.
Facebook HTML5 vs Native

The Facebook app perfomed poorly — slow loading, choppy user experience in the News Feed, low framerate — the usual symptoms. It even saves you battery and space on your iOS device.

The team at Sencha came up with an HTML5 way to make Facebook perform exceptionally well.

HTML5 can’t really be the reason that Facebook’s mobile application was slow. We knew what the browser on modern smart phones was capable of and what kind of rich capabilities HTML5 offered.
The Making of Fastbook

We've covered three ways in which to craft hybrid experiences, depending on your needs. Using the DOM, using canvas, and using native renderers. All have yielded satisfactory results in a variety of use cases. You're probably using hybrid apps and you didn't even know it.

Create Snappy DOM Interfaces and Scrolling

Loading in bloated JavaScript libraries and forcing layout thrashing are a couple ways to make your mobile web app very choppy and slow. Be mindful of the optimizations that can be made.

But even without parallelization, there are optimizations that JavaScript developers can take to improve the responsiveness of their app. Mainly, keep in mind that any time your JS code is executing, your UI thread is unable to process messages or perform layout. One thing you can do to improve this situation is to break your work into chunks and yield in between.
Stop Saying Mobile Web Apps are Slow

Here are some easy ways you can start to improve the mobile web experience, with animations, gestures, and touchstart.

document.addEventListener("touchstart", function(){}, true)  
-webkit-tap-highlight-color: rgba(0,0,0,0);
-webkit-overflow-scrolling: touch;

More reading

Hybrid Apps


Tag cloud