Mobile Apps: HTML5 vs Native
ericsink.com
ericsink.com
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.
In short, how about some proof by example? Lots of examples...
On the other hand it has probably been the driving force to make mobile safari better.
I guess there is Newsreader or whatever but I haven't used it and can't comment on it.
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).
I wasn't talking about mobile.
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.
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 decides it wants in on the action and cuts you off a la twitter...
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.
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.
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.
I wait for the day when these debates are equivalent to arguments about programming language preference.
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.
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.
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.
It has come to replace Java with code once, debug everywhere.
Every single browser version, even from the same vendor, or operating system has a different understating what CSS, HTML, JavaScript means.
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 :(
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.
By this argument, native will always have features that HTML5 is not able to achieve.
As bad as UIWebView is, it somehow manages to be the best webview out of any mobile OS.[1]
[1] as for BB10, I'll believe it when I see it.
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.
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).
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-...
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.
open source, mobile cross-platform logic, freedom to build great UIs