HTML5 vs Native Apps – the War Wages On…

html5
Learn more about which coding language reigns supreme when it comes to the web.

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

HTML5 Vs. Native
Phil Hurwitz
Software Developer

When developing an application, engineers in the commercial world need to consider the ever-growing market of mobile users. Tablets and smartphones are here to stay, and now struggling desktop giants like Dell and HP have to face what USA Today calls “… new mobile reality being led by Google, Apple, and Samsung.”

guy working on smartphone looking at intranetBut there is still much debate within the community about the most effective way to go about developing for mobile. The way I see it, developers have three choices:

  1. Develop a mobile-optimized website for an entirely browser-based experience
  2. Develop a native application for iOS, Android, and any other targeted mobile OS.
  3. Develop a hybrid application, that is, a mobile website wrapped in a native app “shell.”

There are arguments for any of these approaches, and as all engineers know, different tools are best for different situations. But in general, which strategy is best?

Personally, I think the choice should depend on what you’re trying to accomplish. If you have an app that needs a constant connection to the web, it’s probably better to just develop it in HTML for the code reuse and cross-platform compatibility mentioned above. Lots of banking apps use the hybrid model, embedding a website in a native “shell,” and I think it’s silly. Why waste the time and effort fixing bugs on all these platforms when users can just as easily bookmark your mobile site for the exact same functionality? On the other hand, if you can make your app more responsive by caching data on the device and then “phoning home” to the web when it’s necessary, native might be a more attractive option.

Also, I still believe that if you want to use device hardware, native apps do a much better job than HTML5. This certainly leads to a fragmented code base, but maybe someday there will be some sort of language that can be compiled into many native device languages.

I solicited opinions from fellow engineers here at ElevatePoint, and here’s what they had to say:

Nick Nieslanik, VP of Engineering:

I think that it all comes down to robustness.  If you want a robust, complex, best of breed iPhone app, you should create it as a native app for better responsiveness and richer functionality.

If you have a standard set of functionality that’s common across all phone platforms (viewing content, feeds, simple input) then I’d say that HTML 5 is the jam.  It’s quick and works in all browsers with a much lower cost.  I think that all MVPs should start with HTML as well for cost purposes.

Matt Anderson, CTO:

Due to the specialized skillset required to develop and maintain native apps, as well as the large and growing number of phone platforms and OSs, I think building native apps should be the last choice, and should only be done if the required capabilities cannot be accomplished using standard technologies.

The combination of HTML, JavaScript, PhoneGap, and Sencha Touch can provide a rich, interactive UI as well as integration with phone hardware (buttons, camera, microphone, compass, etc.), making the creation of reusable apps for multiplatforms in HTML and JavaScript a fairly straightforward process.

Of course, you still need to test the app on every supported platform, but you will need to do that with a native app as well, but without the benefit of code reuse and shared bug fixes.

It’s clear that there is a good deal of diversity even within our company, and there may not ever be a consensus on this matter. However, by examining the issue, it’s possible we can find some best practices and use cases!

What’s your opinion?

More To Explore

remote worker
Digital Workplace

How to Work Remotely

Working remotely is hard for some people. We have ideas to make it easier.

We can help

teams and teamwork