The argument that HTML5 apps cannot provide sufficient quality is growing increasing weak. There is no question that native apps provide better UI's, especially in the case of iOS.
As for Facebook, they built a terrible iOS app and blamed the technology. It doesn't matter what technology you use: own up and build good products.
HTML5's problem is mobile browsers. They are all non-compliant with a myriad of quirks. You can build nifty native-like UI's in the iOS browser, but it takes lots of time to understand exactly how Mobile Safari implements 3d transforms and how they are so terribly bizarre. I won't even start with the Android browser because the situation is significantly worse[1].
We can build good mobile browsers. The problem is that mobile OS venders have had little incentive to build browsers capable of hosting competing apps with their respective marketplaces. They all build browsers that can view traditional webpages well, but no more.
[1] Anyone who brings up mobile Chrome will get a mouthful about why that's terrible as well.
Rather than provide an academic argument as to why HTML5 apps are as good as native, it would be better to provide great examples of where it has worked. Even Steve Jobs originally thought web apps were all you needed but he was eventually convinced otherwise.
In short, how about some proof by example? Lots of examples...
Because the iTunes platform is written in Java with a legacy web framework called WebObjects. Also the iTunes business unity has more characteristics in common with Amazon than Apple itself. That's why we're stuck with a thin client for the AS.
> There is no question that native apps provide better UI's
This is was me talking about mobile. Then I went on to explain why. So I don't think I need to provide any examples there.
As for HTML5 on the desktop you can peruse the Chrome Web Store to find some good stuff. iCloud.com is actually an excellent example of HTML5 done right (for the most part).
As you may know, iCloud is written in SproutCore. If you compare the development process and programmer productivity of SC with let's say Cocoa, you'll see SC can't get near Cocoa in these aspects. It's a mess.
Try iCloud.com on Mac Safari, it's quite nice. Not sure what browsers Apple is targeting for this.
My assumption is that the 5 major desktop browsers can host web apps of this quality if the app developer chooses to target them. Hopefully as time passes the "chooses to target them" part won't be an issue if standards-compliance is a norm.
Most of the artifacts in Chrome Mobile stem from the fact that the latest stable version branches from Chrome 18 at which point the chrome compositor was in somewhat of a disastrous state (things are somewhat better in Chrome 20 and up). Chrome attempted/attempts to support transforms regardless of the underlying engine (be it OpenGL ES 2.0 or skia) and as result of this ended up implementing a lot of things that would be handled by OpenGL ES natively within Chrome itself, like backface culling, clipping, layer sorting, etc. Unfortunately, most of this math was wrong and as a result many things that use css3d transforms are a flickering disaster. Instead, I think they should have interfaced entirely through OpenGL ES and let a software implementation simulate it in the case of GPU-less hardware (which I think they've actually licensed and are already deploying in some later versions).
If you look at Safari, on the other hand, the only real major issue with 3d transforms is hit detection can sometimes be wonky, but this isn't something that OpenGL makes particularly easy anyway.
The ironic thing is that the stock Android browser is actually much better than Mobile Chrome, likely because it was written directly on top of OpenGL ES 2 from the start, whereas mobile chrome was actually a full port from the desktop. I haven't read much of the Android browser code though, so this is largely speculation.
Facebook's API is out there. If "they built a terrible iOS app and blamed the technology", how come no one has come up with snappy fast HTML5 client against their API?
There are not many third-party clients for Facebook (mobile or otherwise) because Facebook's public API has several limitations that make creating and supporting such an application difficult. For example, users can change their privacy settings so that some or all of their information is inaccessible to the API.
It might not be entirely 'snappy', but it's a hell of a lot better than the installed app version. I laugh every time I go to the website and it suggests I install their app on the login page.
[1] Anyone who brings up mobile Chrome will get a mouthful about why that's terrible as well.
Personally I prefer stock browser over Chrome because I find it faster and more responsive. That said: I'll bite.
What's so horrible with Chrome on Android? And I say that as someone who is interested in learning, not someone debating the correctness of your claim.
Come on now, it took at least this long for web apps to obsolete most native desktop apps. As mobile devices get more powerful with every passing year, I see no reason why history won't repeat itself.
Yeah, none of us are using Microsoft Word any more.
Ever print anything from Google Docs? Look at the typography. Look at the letter spacing and kerning. It's a joke.
And don't even get me started on javascript.
I like to use word processing as an example because it's probably been the #1 client app for 40 years with no web app competitor even close. I would argue 1992 WordPerfect is better than Google Docs in quality, features, and reliability.
The last decade of software development has been focused on web apps, and the promise that it's write-once-run-everywhere. So we've all been suffering by taking a huge step backwards in UI/UX by shoving everything in a browser.
It is just not there. So you can keep struggling with your ugly javascript hacks and unsupported CSS quirks. But the best stuff is being made on the client right now. It's cleaner, easier to maintain code, and the UI/UX is delighting users. User's don't care about cross-platform.
Can you be more specific about "most"?
I enjoyed GMail, but now I use Sparrow (desktop and mobile) to access it: it is just much nicer. A lot of people use apps to access twitter.
The only native desktop app that the web has "disrupted" for me is email. I still use Lightroom, Photoshop, VLC, MS Office, various native video & audio editing tools, etc.
I'm not seeing how thick vs thin clients has anything to do with the html5 vs. native debate. You can build an html5 based app that's just as "thick" as a native iOS app, it just uses a different technology to render the UI.
I actually like the way Web Workers can't touch the DOM. It's nice to finally give the DOM it's personal space for UI operations, which often leads to much more responsive apps especially at a large scale.
The pain points for me come in the form of shared dependencies. Large pieces of code that are accessible to multiple threads, and perhaps the UI thread, must get imported several times.
The lack of access to localStorage hurts in a lot places because any cache access must send data back and forth on the UI thread for operations that are probably entirely unrelated.
The lack of console.log makes debugging considerably worse. There are a couple of hacks to get around this but it's a bit crazy to pass messages between threads just to get a log printed.
Having to create a file per thread is very much a pain. Certain operations are tiny in terms of code and make more sense in the context of where you want to run theme. It'd be nice to run any function on a separate thread. Conceptually that would get weird because it would violate several properties of JavaScript closures. But it'd be nice to find some acceptable way of doing this sort of thing.
Web Workers are pretty good but can be unfriendly to developers at times.
My two latest HTML5 apps, http://appeio.com for App.net which made it into the Apple iOS store and brand brand new http://podglass.com which is my personal solution to podcast headaces.. and a reason to start pushing boundaries with <audio> and <video>.
It's getting there, in two years a good HTML5 app will be very close and in some situations a better choice. Native will improve also but browser tech is due to leap by 2014.
iOS will have a good run and so will Android but the web is open and will never get obsoleted.
I can't help but find his arrogance about being right annoying, especially when he points to how battery technology hasn't improved since Kennedy was in power, which is just ignorant and wrong. Much of the limiting growth in mobile computing power has been gated by battery power and steadily the technology has improved.
The debate has been going on since the browser was created, and it's really not a debate at all, the HTML to render a text box and the iOS native code to do so all call the same operating system library anyway, it's just a matter of where the development team decide to draw the line between ease if install and development vs speed and a richer user experience. This is fluid and shifts over the years as browser technology becomes more expressive.
But I dislike reading articles that are just full of weasel wording, no examples to back up his points and technology inaccuracies.
And all this on top of the fact that HTML was not intended to build apps and it shows. No matter what is built on top foundation will still be messy and shaky.
Just a few months ago I was working on moderately complex web app and even with some nice tools helping to bring some sanity into it (backbone, coffeescript, etc.) we had to reinvent a lot of thing that native APIs give you for free.
It really makes me wonder about those proclaiming superiority of HTML5 over native:
did they build anything nontrivial in it and did they try to do the same with native
approach.
Alas, I see html approach as "mediocre everywhere and pain to develop". And I say this as a guy who does know HTML, CSS and JS :(
As a contractor most of the projects I work on are web based ones.
Every time I manage to land a native application contract I am thrilled to get away from such headaches.
Specially the ones discussing pixel level behavior with the customer or trying to making him/her understand why certain desktop like features are not possible at all in a browser world.
Nice analysis, but only half of the story. As pointed out in the comments, you can make thick or thin clients in both native and HTML5. The issue is rather the one about lowest common denominator. HTML5 aims at working in very varied "runtime environment", where standards are bendable, bugs are rife and feature support a few years behind what native could muster. HTML5 is more difficult, and does not have all the tools, of the native environment. So the question is rather - will HTML5 develop faster than native and thereby be on par with it, or will it always be the straggler?
There is incentive from the platform creators to make their native UI better and better, but not the same incentives for making the HTML5 support (if they are in charge of it, e.g., a browser).
By this argument, native will always have features that HTML5 is not able to achieve.
The reason everyone asumes HTML5 apps can't work on mobile is because how awful UIWebView is on iOS. Apple really need to explain how limiting JavaScript speed in WebView makes it anymore more secure.
You're kind of misreading why Nitro isn't in UIWebView. Since Nitro is a JIT it requires executable pages. Non-apple apps don't allow executable pages because you could then download native code and run nearly anything you want (within the process sandbox), which adds a risk that what Apple approves for the app store may not be what ends up running on a consumer's phone.
The good news is, that with Remote View Controllers in iOS 6, we may get Nitro'ed UIWebViews in a separate process (like how home screen apps work) that have their own secure set of executable pages. See: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-...
JavaScript execution speed is no longer a major limiting factor on mobile. In terms of UI JavaScript execution speed will help you if you're using jQuery (or any naive animator) to animate 2d CSS properties. The DOM, 3d transforms, etc are the real pain points.
As bad as UIWebView is, it somehow manages to be the best webview out of any mobile OS.[1]
I'm going to assume you're getting downvotes for saying that jquery animations are better performing than native CSS animations. From everything I've seen, that's simply not true, regardless of the platform.
I sure hope the downvotes aren't for saying that iOS's uiwebview is the best one we've got. Android web views mean using the android browser rendering engine, which is terrible. It might not be intentionally crippled like apple's is, but it is less capable to begin with.
I'm pretty sure I made no comment as to which is better, jQuery or CSS3 animations.
On mobile there is no question whatsoever that CSS3 animations are much better. The big issues tend to be regarding 3d stacking contexts. You can end up with strange artifacts, z-index breaking transforms, and sometimes downright wrong positioning. Also GPU accelerated elements can sometimes come out blurred. jQuery animations fix this but perform much worse.
On desktop it really depends. Browser compliance is an issue a lot of the time. You can actually slow down a 2d transition by using translate3d or any other GPU accelerated value. GPU acceleration hasn't had all its kinks worked out yet in browsers but its very likely that CSS3 transitions will be miles ahead for regular use cases in the future. I'm not saying that CSS3 transitions are worse, just that they are not better all of the time (only most of the time).
I don't get it. Client thickness is one area that seems to have no bearing on the HTML5 vs. native debate. A canvas and Javascript based application will most often be as thick as a native app, the client downloads it once off the web never to be heard from again. With the HTML5 game I'm developing[1] I can reboot the server with hundreds of active players and no one is the wiser.
Tell me HTML5 apps feel wrong, are unresponsive, a pain in the ass to develop or lack features, but framing it as thin vs. thick client makes it sound like we are talking about native versus the page-based web apps of the 90's, which is unfair to the web. The art has developed and HTML5 in particular, with the immediate mode graphics of the canvas element and the increasingly sophisticated Javascript frameworks, is as capable a platform for rich clients as any, imho.
As for Facebook, they built a terrible iOS app and blamed the technology. It doesn't matter what technology you use: own up and build good products.
HTML5's problem is mobile browsers. They are all non-compliant with a myriad of quirks. You can build nifty native-like UI's in the iOS browser, but it takes lots of time to understand exactly how Mobile Safari implements 3d transforms and how they are so terribly bizarre. I won't even start with the Android browser because the situation is significantly worse[1].
We can build good mobile browsers. The problem is that mobile OS venders have had little incentive to build browsers capable of hosting competing apps with their respective marketplaces. They all build browsers that can view traditional webpages well, but no more.
[1] Anyone who brings up mobile Chrome will get a mouthful about why that's terrible as well.