To me, the table on the website you mentioned has a somewhat-naïve representation of these differences. It seems to focus on pushing a native app as the best possible solution because of “browsing speed” and access to device functionality, but this may not always be what you actually want to achieve. They haven’t taken into consideration other factors which can contribute to your decision on how to implement your mobile solution.

Native, Hybrid and Web apps all come with their own advantages and disadvantages that need to be considered when choosing how you will develop your mobile application. No single choice will give you everything you want. Both functional and non-functional requirements really need to be taken into consideration and “browsing speed” and access to device functionality might not always be the primary focus.

I think “browsing speed” is an ambiguous term. I would define it as “how quickly a user can find what they want” – but that might not be how their table defines it. They might be thinking of pure render time or how fast the application “feels” to a user. In either case, your website/app design as well as implementation approach both contribute to this.

In regards to “could a native app be built to be used exactly as a website?”: A native application can be built essentially however you want it. You will use the device’s OS-specific language to develop the application (e.g. Java for Android or Objective-C for iOS) rather than a “server-side language” like PHP or ASP.NET. It wouldn’t make sense to build a native application to render HTML/Javascript though – if you wanted to take that approach a “Hybrid” application might be what you’re looking for.

To clear up your confusion (and hopefully make things clear) about the development approaches – I should define the differences between the implementations:

Native

• Uses OS-specific language/development approach and standard OS features and functions.

Hybrid Web

• Runs in browser component (e.g. Apache Cordova)
• Uses standard HTML/Javascript development approach
• Bridges to native layer through plugins (in Cordova these are Java plugins exposed via Javascript)

Mobile Web

• Runs in device browser
• Uses standard HTML/Javascript development approach
• Content delivered from Web server

As I mentioned before, each approach to mobile application development comes with advantages and disadvantages and choosing which way to go can be a tough choice. You need to consider the pro’s and con’s to each implementation type (this isn’t an exhaustive list):

Native

Pro’s

• Ultimately the best UI experience, you have full control over what happens and how it happens.
• You get the best performance from the device (providing your code is good)
• You have access to all of the features of the device
• You get OS vendor support
• There’s quite a large, vibrant ecosystem of developers for each device
• Allows deployment to an app store (discoverability)

Con’s

• Device and OS specific and sensitive. You need to develop for Android, iOS, etc – individually.
• Can be a steep learning curve if you’ve never developed a native application before.
• Skill set availability in developers may be an issue in your area
• Total Cost of Deployment (TCD) and Total Cost of Ownership (TCO) may be an issue

Hybrid Web

Pro’s

• HTML/Javascript widely used and understood, plenty of support and developers available
• Browser UI is relatively easy to generate (the platform you use provides these tools usually)
• Performance gain in comparison to mobile web
• Gives options not available to mobile web apps (e.g. access to device hardware – depending on framework used)
• Access to Push / APNs
• Plugins can generally be written for frameworks to do what you like
• Allows deployment to an app store (discoverability)

Con’s

• UI experience depends on the container’s rendering of your HTML and Javascript
• Performance can be an issue depending on the container and its support for what you’re trying to do
• An over-reliance on plugins could cause issues.
• You can potentially limit your device and OS support because of container architecture complexities, bugs and compatibilities.

Mobile Web

Pro’s

• Almost all smartphones have a browser
• No deployment issues
• HTML/Javascript is widely used and understood and there’s plenty of support and developers available
• Single development paradigm (e.g. no need to learn Java and Objective-C)

Con’s

• Network issues can impact user experience (page load, etc.)
• Variations across browsers
• UI experience can be disappointing (especially in bad browsers)
• Performance can suffer (limited access to hardware acceleration from the device)
• Device feature access is limited
• Discoverability can be an issue (cannot be deployed to an app store)

If you ask yourself these questions, it might also help you:

• What do you want your users to be able to do?
• What skills do you have access to?
• What devices do you want to support?
• How long do you have?

I hope this provides you with a little more clarity on the differences between the mobile development approaches, and also why more than just “speed” should impact your choice implementation.

What makes one faster than the other is by not doing the same thing in both. Each platform or development tool path allows different sets of optimizations. Sometimes these optimizations are closer to the hardware, or goes through less layers of software which can eat CPU cycles. If a developer takes advantage of available optimizations (often by native coding or using platform native libraries instead of portable ones), then the result can be faster. If not, then maybe not. Even if faster, the difference may or may not be perceivable to the user, or important to the app provider.