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.<p>ARGUMENT: Native is ALWAYS faster than HTML5<p>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.<p>ARGUMENT: HTML5 is ALWAYS easier/faster to code than Native<p>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.<p>ARGUMENT: HTML5 apps ALWAYS look bad/uncanny vs. Native ALWAYS looks boring<p>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.<p>ARGUMENT: HTML5 is ALWAYS easy to port, Native is not<p>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.<p>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.