I've done non-trivial projects in both HTML5 (with/without PhoneGap, with/without jQuery Mobile), Native (ObjC, WinMobile), and hybrid mix of HTML5/Native (views in HTML, model/controller in Native). I've heard all the pros and cons of both sides but most of them are either non-issues or wrong.
ARGUMENT: Native is ALWAYS faster than HTML5
MY EXPERIENCE: So what? Speed depends on what you're trying to do and how. Animating a loading icon for UITableView will not spin any faster than a loading.gif in HTML5 view. Similarly, being able to slide an entire UIView to the side at 120fps doesn't mean using CSS webkit-transform: translate3d(x,y,z) at 60fps looks any worse to the user. Speed matters when you're (a) crunching data and (b) updating graphics. If you're building HTML5 apps that need some serious data crunching, you can do that part in C and call from your code via a plugin. And unless you're making 2.5D-3D games, you don't HAVE to go native. And then you're most likely coding in C/Lua anyway. For most of the apps out there, raw processor speed isn't a necessity - responsive UI is.
ARGUMENT: HTML5 is ALWAYS easier/faster to code than Native
MY EXPERIENCE: Sometimes yes, sometimes no. It depends on your experience with all the available technologies. I can code views in HTML5 using CoffeeScript/Less/Bootstrap/Backbone relatively fast. I can code models/controllers in ObjC relatively fast. Views in ObjC get complicated and models/controllers in CoffeeScript/JS get complicated. If you have a UI-heavy app and you can code UI fast, go with HTML5. If you feel comfortable validating user data input in ObjC and have tons of forms, go with ObjC. There is no silver bullet.
MY EXPERIENCE: Poorly designed apps look bad/uncanny/boring. I have to admit that using jQuery Mobile and similar libraries without doing any customization/tweaking pushes your HTML5 app into the uncanny valley. And unless you skin the Native UI, your app will look no different than the phone's native contacts list. My preference is to (a) Not use libraries that make fake native-looking-UI when doing HTML5 (b) Adding graphics/skin to native UI to make it standout from boring address-book UITableView lists. Ugly/boring apps are a graphic design problem, not a side-effect of platform choice.
ARGUMENT: HTML5 is ALWAYS easy to port, Native is not
MY EXPERIENCE: Far from the truth. When porting, you're not just porting to a different software subsystem but also different hardware parameters. Even the best designed HTML5 apps can't suddenly go from Android phones to iPad or iPhones to Nexus 7. Moreover, if you code the core functionality of your Native apps in C, it makes it quite portable. If you make your HTML5 views fluid/responsive, it makes it quite portable. If you're relying on special hardware functionality (camera, GPS etc.), it's a case-by-case issue of what's portable and what's not. If you have a data logging CRUD app that accepts user input on HTML5 views, posts to a remote server, and displays results, you might get away with 1-hour port like the author of this article. But more often than not, you have more issues to consider. In-App purchase? Yeah, can't port that easily. Facebook-integration? Can't port that easily unless you're using portable libraries.
Software development is just as complex on mobile devices as it is on servers. Your choice of platform (HTML5 vs Native) really depends on your specific app's requirements. There is no way you can make WordLens in HTML5 (today) and there is nothing wrong with going HTML5 if it saves you time and resources in the short and long-term. People need to realize that there are no absolute GOODs or BADs in software development. Pick the best option after you weigh in the cost of design & architecture, development, legacy support, resources, training, deployment, and maintenance.
Thanks for the well thought out response to this thread. Often times conversation around this topic tail-spins into a flamewar between native and HTML5 proponents. It's a breath of fresh air to have a measured, detailed account of the pros and cons of using HTML5 to develop mobile applications.
My personal opinion based on my experience having written both native and html5 mobile apps is that the closest you can get to a "silver bullet" is a well thought out responsive HTML5 design packed in phonegap/cordova with native navigation elements. You get the benefit of snappy, native navigation while being able to go cross platform very easily with one code base.
Original author here. While I agree with you on all points, I have something to add:
1) speed - while not 100% fluid, with the latest phones this year and Android 4.1, rendering speed is easily kept within reasonable FPS (>40). On Android, even native apps aren't always fluid.
4) porting - This is true, however I think you underestimate both the power of HTML5 and the easiness of using PhoneGap or interfacing between native libraries and JavaScript on most platforms. Our prototype app isn't just a CRUD app - its a presentation maker with lots of GUI that needs to access to local files/images.
(Of course, in-app purchase and platform-specific libraries mean harder to port apps)
I have an Android device so can you point me to a single non-trivial HTML5 app in Google Play that is comparable in performance and functionality to a typical well implemented native app?
The problem with HTML5 as an app interface isn't getting something to appear on the screen on any of the browsers, it's getting the user experience to match the native platform.
A similar post in 1999 would have been titled:
"Why native development sucks and Java Swing rocks: Porting to Mac OS 9"
Well, I guess to be fair. Windows 8 styling is something that you could do in CSS (and is done in CSS for some apps), so HTML5 apps will look native (to Metro).
HTML5/CSS/JavaScript are finally moving in the right direction.
However, what we should be doing is making the browser nothing more than an x64 VM. That way, all of the underlying OS calls could be wrapped in an OS-independent way, and for those that are specific to a particular platform, a generic way to access host-specific features.
Because each generic OS call maps into a real OS call, every call can undergo a security check. We can use ACLs or web-based authentication, or distributed authentication, etc. Or perhaps none at all for something like "give me the current date".
Each "app" (and, they would be real apps!) would run inside a separate VM. Communications to other parts of the system - for example, to another running app - would be done via messages (or some other method that could also be authenticated).
Now, some of the beauty of this scheme is that existing apps could run without modification on this platform because the VM would trap all the "real" OS calls and authenticate them, validate them, etc. As in unix, I/O would get mapped to arbitrary streams; for example, if the existing app was console-based and did printf() and scanf(), those would be mapped to the user's keyboard and output of the VM on the screen.
I wrote a much longer version of this and sent it to Alan Kay, but I must not have his "real" email, as I've gotten no reply. (Or maybe I'm nuts...)
What is astonishing to me is that if one of the "big guys" (Google, Yahoo, Microsoft, ???) were to build this "Web-Enabled Application Platform" (WEAP sigh...) [perhaps using Xen] it would TAKE OVER the entire OS market. The only "program" a user would run (at least what was visible to her) would be WEAP.
Years ago, this would have been a crazy idea. But today's machines are so fast that I believe we're finally ready to accept the need for better security and authentication, and, at the same time, accept a bit of a slowdown of our apps to trade for robustness and safety. Not to mention the side benefit of getting rid of HTMLx CSS and probably JavaScript !
I've never seen this idea written up anywhere else, so I hereby put this into the Public Domain.
This concept needs much more detail before doing a reference implementation, and I definitely haven't considered every corner case. But, given the exceedingly poor state of "the web" these days, something like this will (clearly!) eventually happen.
Right. No real access to contacts, camera, files/database, accelerometer, GPS, etc. We tried in vain with application cache, offline storage, etc. but not seeing contacts/camera was a show-stopper. Even location isn't the same as native GPS because users get a warning on opening the HTML that usually scares them away.
'Native' in this context is a term that refers to a language that compiles to machine code. Neither .NET nor HTML5 are ever native. You might be thinking of 'First-class' or 'Supported' which does describe HTML5 under Windows 8.
Good to hear that it was easy to do. What this article describes is the vast majority of why Microsoft made HTML5/JS/CSS a development path in Windows 8.
chime|13 years ago
ARGUMENT: Native is ALWAYS faster than HTML5
MY EXPERIENCE: So what? Speed depends on what you're trying to do and how. Animating a loading icon for UITableView will not spin any faster than a loading.gif in HTML5 view. Similarly, being able to slide an entire UIView to the side at 120fps doesn't mean using CSS webkit-transform: translate3d(x,y,z) at 60fps looks any worse to the user. Speed matters when you're (a) crunching data and (b) updating graphics. If you're building HTML5 apps that need some serious data crunching, you can do that part in C and call from your code via a plugin. And unless you're making 2.5D-3D games, you don't HAVE to go native. And then you're most likely coding in C/Lua anyway. For most of the apps out there, raw processor speed isn't a necessity - responsive UI is.
ARGUMENT: HTML5 is ALWAYS easier/faster to code than Native
MY EXPERIENCE: Sometimes yes, sometimes no. It depends on your experience with all the available technologies. I can code views in HTML5 using CoffeeScript/Less/Bootstrap/Backbone relatively fast. I can code models/controllers in ObjC relatively fast. Views in ObjC get complicated and models/controllers in CoffeeScript/JS get complicated. If you have a UI-heavy app and you can code UI fast, go with HTML5. If you feel comfortable validating user data input in ObjC and have tons of forms, go with ObjC. There is no silver bullet.
ARGUMENT: HTML5 apps ALWAYS look bad/uncanny vs. Native ALWAYS looks boring
MY EXPERIENCE: Poorly designed apps look bad/uncanny/boring. I have to admit that using jQuery Mobile and similar libraries without doing any customization/tweaking pushes your HTML5 app into the uncanny valley. And unless you skin the Native UI, your app will look no different than the phone's native contacts list. My preference is to (a) Not use libraries that make fake native-looking-UI when doing HTML5 (b) Adding graphics/skin to native UI to make it standout from boring address-book UITableView lists. Ugly/boring apps are a graphic design problem, not a side-effect of platform choice.
ARGUMENT: HTML5 is ALWAYS easy to port, Native is not
MY EXPERIENCE: Far from the truth. When porting, you're not just porting to a different software subsystem but also different hardware parameters. Even the best designed HTML5 apps can't suddenly go from Android phones to iPad or iPhones to Nexus 7. Moreover, if you code the core functionality of your Native apps in C, it makes it quite portable. If you make your HTML5 views fluid/responsive, it makes it quite portable. If you're relying on special hardware functionality (camera, GPS etc.), it's a case-by-case issue of what's portable and what's not. If you have a data logging CRUD app that accepts user input on HTML5 views, posts to a remote server, and displays results, you might get away with 1-hour port like the author of this article. But more often than not, you have more issues to consider. In-App purchase? Yeah, can't port that easily. Facebook-integration? Can't port that easily unless you're using portable libraries.
Software development is just as complex on mobile devices as it is on servers. Your choice of platform (HTML5 vs Native) really depends on your specific app's requirements. There is no way you can make WordLens in HTML5 (today) and there is nothing wrong with going HTML5 if it saves you time and resources in the short and long-term. People need to realize that there are no absolute GOODs or BADs in software development. Pick the best option after you weigh in the cost of design & architecture, development, legacy support, resources, training, deployment, and maintenance.
marknutter|13 years ago
My personal opinion based on my experience having written both native and html5 mobile apps is that the closest you can get to a "silver bullet" is a well thought out responsive HTML5 design packed in phonegap/cordova with native navigation elements. You get the benefit of snappy, native navigation while being able to go cross platform very easily with one code base.
spion|13 years ago
1) speed - while not 100% fluid, with the latest phones this year and Android 4.1, rendering speed is easily kept within reasonable FPS (>40). On Android, even native apps aren't always fluid.
4) porting - This is true, however I think you underestimate both the power of HTML5 and the easiness of using PhoneGap or interfacing between native libraries and JavaScript on most platforms. Our prototype app isn't just a CRUD app - its a presentation maker with lots of GUI that needs to access to local files/images.
(Of course, in-app purchase and platform-specific libraries mean harder to port apps)
hammersend|13 years ago
jefflinwood|13 years ago
A similar post in 1999 would have been titled: "Why native development sucks and Java Swing rocks: Porting to Mac OS 9"
megaman821|13 years ago
GeorgeTirebiter|13 years ago
HTML5/CSS/JavaScript are finally moving in the right direction.
However, what we should be doing is making the browser nothing more than an x64 VM. That way, all of the underlying OS calls could be wrapped in an OS-independent way, and for those that are specific to a particular platform, a generic way to access host-specific features.
Because each generic OS call maps into a real OS call, every call can undergo a security check. We can use ACLs or web-based authentication, or distributed authentication, etc. Or perhaps none at all for something like "give me the current date".
Each "app" (and, they would be real apps!) would run inside a separate VM. Communications to other parts of the system - for example, to another running app - would be done via messages (or some other method that could also be authenticated).
Now, some of the beauty of this scheme is that existing apps could run without modification on this platform because the VM would trap all the "real" OS calls and authenticate them, validate them, etc. As in unix, I/O would get mapped to arbitrary streams; for example, if the existing app was console-based and did printf() and scanf(), those would be mapped to the user's keyboard and output of the VM on the screen.
I wrote a much longer version of this and sent it to Alan Kay, but I must not have his "real" email, as I've gotten no reply. (Or maybe I'm nuts...)
What is astonishing to me is that if one of the "big guys" (Google, Yahoo, Microsoft, ???) were to build this "Web-Enabled Application Platform" (WEAP sigh...) [perhaps using Xen] it would TAKE OVER the entire OS market. The only "program" a user would run (at least what was visible to her) would be WEAP.
Years ago, this would have been a crazy idea. But today's machines are so fast that I believe we're finally ready to accept the need for better security and authentication, and, at the same time, accept a bit of a slowdown of our apps to trade for robustness and safety. Not to mention the side benefit of getting rid of HTMLx CSS and probably JavaScript !
I've never seen this idea written up anywhere else, so I hereby put this into the Public Domain.
This concept needs much more detail before doing a reference implementation, and I definitely haven't considered every corner case. But, given the exceedingly poor state of "the web" these days, something like this will (clearly!) eventually happen.
jawngee|13 years ago
herdcall|13 years ago
lubos|13 years ago
Danieru|13 years ago
kodablah|13 years ago
I must toss https://github.com/rogerwang/node-webkit/ into the mix. I have found it incredibly easy to develop with...and even easier to distribute.
Metrop0218|13 years ago
ta12121|13 years ago
strandev|13 years ago
WayneDB|13 years ago