But say our client changes his mind on the camera. The show can go on without it. After the app picks up and is starting to spread there starts to be more and more content being created. There is a ton of rich text and media to be consumed. But, all of a sudden, the complaints start to roll in. Words like “sluggish,” “stuttering,” and “slow” start appearing. That’s no good. The developer looks into it and finds that the stuttering and slowness happens when a user scrolls a list. Well there isn’t any way to control how the phone performs a scroll, so they just have to deal with it. But pretty soon those reviews are going to make an impact on how users perceive that app.
Why is performance worse when displaying HTML? Because as stated before, native always gets priority. The device has to download the HTML, parse it, render it, display it, then manage it. That’s a lot of work. With native code all the phone has to do is render because it knows everything else about the content and layout already since it is already loaded into the app. Now there are tricks to improving HTML rendering and responsiveness, but they will only go so far.
The story of Facebook’s redesign is a great example of starting with an HTML5 app and eventually shifting to native code due to pressure from users. There has been a lot of debate on Facebook’s switch from tech bloggers, but users have poured out their support of the changing claiming that the app finally feels better.
So in the end, why is native code better? Because it is native to that device. That is how it is supposed to be run and that is what will always receive priority before HTML. For the sake of your users and your sanity, start with native and end with native. Don’t give it a second thought because your users should always come first, and your users want native.Tweet