I ran the HTML5 app on my iTouch 4G running iOS 6 (roughly equivalent to iPhone 3GS) and compared it to the native FB app. The HTML5 app had noticeable lag in the swipe transitions. It also crashed once when loading a photo (only once though). Not to mention that they implement almost everything differently and leave out 90% of FB's features.
That being said, it was really smooth on my iTouch 5G.
The demo HTML5 app also runs in Safari. The problem is that Safari's Nitro JS engine is much faster than the older JS engine used in a UIWebView (I think the restriction is supposedly due to security).
For the moment, native is still the way to go, IMO. But I've always believed that at a certain point iPhones/Androids and their browsers will be powerful and efficient enough to negate any performance drawbacks to HTML 5. I think that point might arrive by the iPhone 6 or so, when developers might feel comfortable dropping support for the iPhone 3GS and equivalent. In fact, many devs are already dropping support for the iPhone 3GS.
Many seem to be missing the point here. While native in the mobile context, has the potential to be faster, it's a necessary, but not sufficient condition for superior responsiveness and usability.
Even with the native app, the same poor design decisions are being repeated once again. For example, not caching data locally between screens - an especially egregious oversight in the context of mobile networking.
I think the broader issue however, is just how out of touch Mark Zuckerberg was with regards to mobile and perhaps even emerging web technology in general.
He eventually admitted to screwing up (great!), but then got it so wrong again, by declaring HTML5 as the culprit. The problem was almost certainly more attributable to people and management issues, rather than a technological misstep, irrespective of whether that resulted in a more palatable conclusion for Mr Zuckerberg's ego.
As for the Sencha demo, after installing it on my iPhone 4s it works really well, and installing it as app on the home screen makes it virtually indistinguishable from native. I think it's fair to say this is a rather significant achievement by Sencha, indeed considering it's a part time effort.
Which makes one wonder what a full time team, with the right leadership and resources, could have achieved at Facebook.
I am currently developing a vanilla (no mobile frameworks like sencha) mobile web app I can attest that on IOS you can pretty much get native performance if you do some trade off and optimize your app rendering.
On android that's another game and you can forget about all those cozy animations and only devices with android 4.0+ will perform well, or at all (in my case anyway).
Also I'm really not sure why people currently associate html5 apps with bad battery life, personally I did not see any noticeable differences in usage from a native one, hell native use a lot more the gpu so it should be worse.
I have the same experiences. We wrote http://hyves.nl/hybrid which works wonderfully on iOS. But didnt really deliver the HTML promise on Android. Maybe because of the browser which was not as good as the safari a year ago. And maybe also because of slower phones.
However the same code did run on iOS blackberry and Android. However the experience was sub-native on most devices. And we really needed to do a lot of tweaking and work to get the native look and feel on iOS.
So if you want to be the best, no matter the costs, go native. Otherwise Sencha is not a bad choice to make. It really depends on your requirements.
Even when browsers are powerfull enough the mess what is trying to shoehorn technologies created for hyperlinked text into apps development will still be a mess. It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks.
As for the appeal "run everythere"—that's just some more quirks. Good luck with that.
I am very experienced web developer and probably know html, css, js and all that jazz better than I do know Objective-C and Cocoa Touch, but building mobile apps with web technologies is the last thing I want to do.
>trying to shoehorn technologies created for hyperlinked text
Genetic fallacy. For 75% of its development, HTML has been taregeted at greater things than hyperlinked text.
>It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks.
I would say the opposite is true. Native doesn't protect you from quirks. On the contrary, it makes them worse. If you use HTML5, you're (eventually) dealing with standards that you can rely on so that you know your app will still work years down the road. Point your modern browser at the website for the movie Space Jam, and it works exactly the same today as it did in 1996.
But with native frameworks, you have no such security as a developer. The "standard" is defined as "whatever the documentation currently says". Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature without deprecating it first? Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself.
And that's to say nothing of the power that you lose when you write native apps in today's world of walled garden app stores. Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like blue today"? Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell your iOS app outside of the App Store, and it won't run on any other platform.
> For 75% of its development, HTML has been taregeted at
> greater things than hyperlinked text.
Where did you get this kind of nonsense and numbers? Before Web Applications 1.0 which evolved into HTML5 were was little considerations for web apps.
> If you use HTML5, you're (eventually) dealing with standards that you
> can rely on so that you know your app will still work years down the
> road.
Oh my, where do I start… I rather not. You know, I've been making websites since 1996, I happen to know a thing or two about web standards and web browsers and I happen to be on HTML5 mailing list since before it was known as HTML5, so let me just say: you cannot rely on anything.
> The "standard" is defined as "whatever the documentation currently says".
As opposed to what? You do know that no browser implements HTML 4? You do know, that versions of HTML are basically meaningless?
> Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature
> without deprecating it first?
Except that did not happen. Your web app won't run on pure spec. It needs browsers. Guess who develops browsers. Guess who picks up which features to implement.
> Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself.
I guess your up to date web app has better luck with broken Android browser of the previous versions.
> And that's to say nothing of the power that you lose when you write native apps in today's world of walled
> garden app stores.
I lose no power. Some people are scared by walled gardens because… well, because they are supposed to get scared.
> Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like
> blue today"?
Oh, those scary stories of the days past. There is a name for them: FUD.
> Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell
> your iOS app outside of the App Store, and it won't run on any other platform.
As opposed to many many ways to sell your web app. Good luck with that.
>Where did you get this kind of nonsense and numbers?
HTML first showed up in 1990. It started its evolution away from "hyperlinked text" with the introduction of elements like forms in 1995. It has been around for 22 years, and for 17 of those it has been for far more than hyperlinked text.
> Oh, those scary stories of the days past. There is a name for them: FUD.
I'm glad to hear that you haven't yet been bitten by placing your eggs in a basket held by a single company. Please do some research before assuming that your experience can be relied upon.
Personally, I've been bitten repeatedly. Forgive me if your screams of "FUD!" elicit a chuckle.
Adding forms in 1995 did almost nothing to change HTML from hyperlinked text documents to anything resembling modern web apps. It took about a decade before (somewhat cross-browser compatible) asynchronous Javascript appeared on stage, what changed the whole game. 10 years of forms gave us rainbow sparkle generators and rudimentary webmail. Then 7-8y of "AJAX" gave us a generation of kids that truly does no longer intuitively grasp the difference between native apps and web apps.
While the form element was probably a great improvement (I wasn't there, not until '98 until my first steps in HTML), think about literal meaning of the word "form" for a bit. It's still a document. HTML was normal documents with hyperlinks in it, add form elements and now you also got fill-in document with hyperlinks.
Yes you could potentially make web apps that way, but everything (everything) required a server-roundtrip. It may be a hard to imagine what a far cry that was from what we now consider a "web app". Every single UI change had to go through a form submission request and a response from the server that contained the entire page regardless of what was updated. "... but .. frames!", I can hear you wonder, well IMO frames weren't all that. They didn't really make selective updating possible in pretty much the same way as forms didn't really make web-apps possible either. Plus, I can't remember if there's been any time people weren't hating on frames (it broke navigation and bookmarking--sound familiar?).
I say this, because I remember discussing the idea of web-applications in 2002/03 or thereabouts with a friend in college. I had just discovered the SCRIPT SRC trick so you could actually load data from the server without reloading which was paradigm-shattering magic, at the time (the technique is still in use as part of JSONP, btw). I had already written a chat-client and it was beautiful, I wanted to pick his brain for more ideas of what to do with this new ability.
(please remember, this discussion occurred during the height of the Browser Wars, 1-2 years before the tide started turning. if you weren't there, or doing webdev at the time, imagine it 10 times worse. digital trenches, man)
My friend told me pretty much the exact sentiment I see pop up in this thread here, that HTML was intended as a document markup language, not for application building, and that while we could hack all these cool interactive features on top of a markup language, and surely these were some quite impressive feats of creative thinking, it would always remain on shaky grounds because you should build an application framework from the ground up with application framework foundations, not by bolting things onto a markup language. Back then, I knew this to be true (one picks up a few things about software design, studying CS) even though I didn't want it to be, because the tech was so cool and the possibilities so enormous (hackers should be able to relate to that feeling :) ).
Now, many years later, I got what I wished for, and my friend got to be right.
(at some point CSS and JS incompatibilities started to slowly disappear and the Browser Wars came to a sort of uneasy peace--this was a slow realization I can't really say when it happened, but I don't have to resort to black magic anymore to write a basic webpage that works in FF,IE,Chrome and Opera--particularly if I write it in Opera first)
Looking at the state of web-apps today, we are using that technology ("AJAX") to build things beyond my (I won't say "wildest") imaginations back then. But it's still clunky here and there. Javascript is still a pretty crummy language (though I love coding for that weird prototypal beast), and as soon as you write more than 5 lines of DOM-manipulation, you're going to want a framework like jQuery. And for some mysterious reason, people still manage to write JS code that works in one or two, but breaks in the latest versions of other major browsers. Minefields are hard to clean up I guess. There is more, but you get the idea--and IMO a lot of the problems can be traced back to bolting application-behaviour capabilities on top of a document markup language.
Still, I do believe we're heading in the right direction. Things can be made much cleaner than say 5 years ago, and there's new standards looming on the horizon that may make things even better. Sure, a from-the-ground-up design would have been so great and so clean. But the industry would have probably found a way to crud it up regardless. And given the global scale and heterogeneity of the Internet as a communications medium, the immense market forces that come with such an environment, personal computing capabilities over time, maybe this was the only way it could've been pulled off, who knows?
What mess? HTML/CSS/JS is exceptionally good at building user interfaces. And you're on the right side of technology by attaching yourself to the HTML bandwagon. I would go as far as to say that if you're starting development on a new ("form-based") native app, your first choice should be HTML. You only go native if you have a very good reason to do so.
> HTML/CSS/JS is exceptionally good at building user
> interfaces.
Except they are not. Even with all the nice tools we have now: backbone.js, CoffeeScript, CSS preprocessors it is still a mess. Just take a look at all those struggling to get sane view management, event binding, notifications, callbacks:
it is years behind mature native frameworks which has very little cruft.
I really doubt all this mess can be solved with HTML, and I really doubt that web can now have any alternative to HTML.
Why is the idea to craft an app for each platform using native tools so scary? Were all those desktop apps using cross-platform toolkits successful? Or do they look alien everywhere?
I do like web. I love web. And that's why I don't like to see it turning into frankenweb.
With HTML-native-apps you get free cross-platform support, and you get to work within a very-well supported, constantly improving and performant framework. Furthermore, if you're building a SASS-type app (e.g. where your content is primarily hosted online) then using a WebView-type component will let you instantly "upgrade" your clients and you never have to worry about old versions of your app in the wild. You better have a damn good reason to give that up.
Please don't listen to this person, webdev is hard and you don't get anything for free. Actually, it depends if you prefer learning from painful experience or simple advice...
> HTML/CSS/JS is exceptionally good at building user interfaces
Only if your background is HTML/CSS/JS. If you have no web background, figuring out the idiosyncrasies of CSS and JS, while very doable, is still very time-consuming. I can't imagine it being any faster than someone going the native route assuming they do not have an existing web skillset to leverage.
Even with multi-browser support, it isn't that bad. But we're not talking about websites here, are we? We're talking about using HTML/CSS/JS to build native apps for mobile devices - which are by and large webkit-based. This greatly simplifies everything.
Oh really? Let's take my webkit-based mobile browser then and look at an instagram picture. Hm, it's cut in half and I can't scroll. Mobile web apps are actually iOS webapps that most of the time work on Android. Stop pretending you actually care about standards and cross-platform, you're only interested in doing less work, learning fewer things and holding users firmly by the balls in the cloud.
My issue with HTML apps (like your issue) is many developers think it's perfectly okay to use that iOS interface on Android because Android does not force you to change it. The Android ecosystem is so polluted with apps like this that it almost makes me long for Google to put their foot down and start forcing UI compliance like Apple does.
It's bad enough Android users have to deal with legacy apps on their own OS that still use pre Android 3.0/4.0 UI conventions (or worse, poorly slap them on top of their old interface without consideration). The only apps that should be allowed to get away with rolling their own UI are games.
I got maybe half your point though I'm not quite sure what your objection is.
"Holding users firmly by the balls in the cloud"? If your service already resides in the cloud, the technology you implement your client software in, hardly matters, no? Facebook app, whether is HTML5 or native, is largely unusable without a persistent internet connection. Yes, I am interested in doing less work. I do care about standards, thanks. I certainly wouldn't stand in the way of anyone wanting to learn whatever they want. If you want to build an app to learn Objective-C, all the power to you.
The problem with this that reasonably large subset applies mostly to content related stuff. For web app you will need more envelope-pushing things and the picture won't be as nice there.
Not to mention other issues that are not taken care by HTML at all: views management, efficient lists, etc. etc.
>Making web sites that comply to customer requirements down to pixel level, across all required target browsers is a major pain.
How is that a fair comparison to native apps? A native app can run on one platform. Making native apps pixel-for-pixel identical on multiple platforms is way more of a pain than doing so with HTML5.
In a consistent way down to pixel level in a 1:1 correspondence to Photoshop designs required by customers, across all required browser versions in all required operating systems, yes.
1. The main discussion here was about HTML5 based apps using a native web-view app wrapper. That makes "OS version" and "browser version" identical, and puts you in an identical position to native apps in terms of number of platforms to deal with.
2. Even if you're dealing with multiple browser versions, there isn't very much difference between how a given version of a modern browser behaves under different OSes. And if a page works correctly in an old version of a browser, it is very unusual for it to start working incorrectly in a newer version of that browser.
3. Maintaining a single code base with special cases for different platforms is way easier than maintaining multiple disparate code bases. It's the old DRY principle.
The fact is this: writing an app and supporting multiple OSes (even multiple versions of the same OS) is hard. Doing so while making everything pixel-exact across different platforms is really hard, and usually pointless. But the idea that it would be somehow easier when maintaining entirely separate code bases is ludicrous.
>1. I don't understand wasn't the HTML5 model the portability everywhere? So why the constraint to mobile devices now?
Ideally, HTML5 apps would automatically be completely portable everywhere, but that ideal isn't realistic. HTML5 is still great for simplifying porting (which is not to say that it is without disadvantages) because it gives you a single code base that behaves nearly identically everywhere, and then you have to tweak it. Constrain your problem to a couple of mobile browsers, and the number of tweaks drops dramatically.
Now I understand the draw of simply maintaining separate code bases. It's the same draw as the urge developers have to rewrite a project from scratch. It feels like starting with a clean slate will be more efficient than hunting down and eliminating every blemish. But that's an illusion. Working from a clean slate, you'll still be tweaking out blemish — it'll just take longer before you even have the privilege of thinking about them.
>2. It is always fun to see junior developers learn the quirks of CSS across browser versions of the same browser.
Oh, they're there. But in aggregate, they aren't as bad as working across different native platforms.
>Have fun talking to our Fortune 500 customers doing pixel counting on web applications, before signing the pay-check.
Yes, I realize that some clients require it even though it's usually pointless. Some companies have more money than sense, after all. My point was that it's hard no matter how you develop the app.
Uhh, the callbacks aren't from node. The fallbacks are from vanilla JavaScript. You just notice them more in node, because you're doing event stuff, like making http connections. You have callbacks in browser JavaScript when you use AJAX.
It's a very strange comparison to me. JS is intrinsically tied to the DOM, HTML and Web technologies, the underlying VM has widely used open-source implementations (V8, WebKit, Gecko), and JavaScript is not controlled by any single company.
My comparison was of a more practical nature and practically speaking the most distributed VM is the browser.
The browser itself used to be too slow for many use cases which led to Flash filling in the gap, but thankfully that's rapidly changing with improved JIT VMs and HTML5 standardization efforts (WebRTC e.a.) all leading to the eventual demise of Flash.
Hence; JavaScript is the new ActionScript.
P.S. They're both just ECMAScript flavors so in that sense I would say they're very close ;)
Saying that HTML is nothing but a technology created for hyperlinked text is like saying the mobile device you're using all the time was created to pass phone calls. While this is true, it is a truly weak statement.
You make it sound like learning the native will magically lead to create better working apps. This is just not true.
I'm not saying going native doesn't have to potential to help developers create faster apps, but when making something like this feed, HTML5 would not seriously be a bottleneck.
And you're claiming to be a "very experienced web developer"? Dunning-Kruger much?
Safari uses a tracing JIT compiler, meaning that it's taking pieces of javascript and, in real time, turning them into machine code and executing the machine code. It then will save these "traces" and reuse them for recurring pieces of code.
This requires special permission to add execute permission to memory that the app had allocated and used for data, which is pretty dangerous. So Safari gets it and 3rd party apps do not.
Why do we see plenty of articles saying that HTML5 can be as good or better than native code and no actual applications doing it?
Facebook and Google tried and miserably failed, LinkedIn and Twitter are probably the ones closest to actually doing it, but users still prefer the native version, why?
One I think is a big reason is clearly visible in the video: scrolling physics are different. It's annoying and feels wrong and I think people notice even if they probably don't know how to describe it.
Maybe with this Sencha contest we'll see some good ones.
Add Tumblr to that list as well. They recently converted their iOS app from essentially pure HTML5 to pure native, which was no easy feat considering the dynamic nature of blog posts on Tumblr, which can contain almost arbitrary HTML content.
We've yet to see a web app that meets or exceeds the experience offered by native desktop apps.
Natively built apps are almost always "better" because they're closer to the OS and implement the native UI conventions. At the same time, web apps are almost always cheaper, because you don't have to develop for each platform from scratch (or suffer a lowest common denominator experience by using a cross-platform non-web dev framework.)
Mobile has the same dynamic. Mobile web apps can get away with being worse, as long as they are "good enough" and available on all platforms. The app store's ease-of-shipping bonus has delayed this, but the shift to mobile web apps is pretty much inevitable because of the cost of development and the ease of deployment.
I think it's a mix of FUD and reality. It's true that for most older devices HTML5 apps just don't perform very well, but they are slowly disappearing from the market.
Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them.
>Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them.
Maybe I'm mistaken but Google released an official Gmail app on iOS that was basically HTML. Everyone hated it. The same goes for the situation with GMaps. Virtually no one used the web app and now Google Maps is the top ranked free app.
There's a tech community confirmation bias at work here. I can't see what the ratings were like before the most recent version, but Gmail has a 3.5/5 rating on the App Store right now. I suspect that a lot of "ignorant" non-tech users found it to be fine.
The ratings were particularly low before it went native. I know because I have a Gmail account in Mail.app and didn't use it because of this.
It's one thing not to listen to MG Siegler complain. It's another to excuse everyone else who complains on the App Store. They may not know the reason but they know the effect.
Strawman. They may not be scientific (statistics is a science, btw), but they are one way we have to infer whether people hate an app or not, which was the topic of this branch of the conversation.
I suspect that a lot of "ignorant" non-tech users didn't find it at all. You have to be fairly adventurous to even try a different mail client than the default Apple app.
I've never actually been able to get a confirmation one way or the other oh which of Google's native apps are "hybrid" apps and just how much of those apps is done in HTML5. The previous version of their gmail app seemed to employ a lot of HTML5 because you could see the main inbox list re-render occasionally. That app performed perfectly well for me. Unless we hear from Google officially about the new app we'll never know. It could be that it's full native, or it could be that they've perfected the HTML5 code to make it feel completely native. Who knows.
I assume the current Gmail is mostly written in native code because it is faster and there are elements in it that don't exist on the web site.
The original was just a wrapper for the web site which had unusually high negatives from users and reviewers alike. I never used it since I read the reviews before I actually downloaded it.
It's certainly not fully native. It has a number of issues that make it a poor experience in my opinion.
- Emulated scrolling feels wrong. This is my biggest issue.
- Slow launch and mailbox load time.
- Numerous short pauses while navigating.
It's a big improvement over the previous iteration, sure, but as a user I don't see why I should lower my standards just because Google (a company not short of engineering resources) chooses to advocate a particular technology.
I believe the scrolling physics can be updated. In the Bonus Points section they mention:
> Also, you may notice a difference in the scrolling deceleration time between the native iOS app and Fastbook. In the native app, scrolling doesn't stop for about 3s. We decided to increase friction and reduce the animation duration to 1.4s. This not only makes content ready to read faster, it also provides extra idle time for the app to buffer more items while the user is still reading existing content.
Because end users couldn't care less if an app is build using native sdk or web technology; is it multi-platform or not.
All they care is how it works.
As for developers: some only know web tech and are not willing to learn native—their loss. Some buy an idea of developing universal web-tech based app for two or three platforms will save them time. I doubt that very much. Either you get a crappy app on all platforms, or you spend more time polishing it than it would take to go native for all platforms from the very beginning.
>> One I think is a big reason is clearly visible in the video: scrolling physics are different.
From the article:
"In the native app, scrolling doesn't stop for about 3s. We decided to increase friction and reduce the animation duration to 1.4s. This not only makes content ready to read faster, it also provides extra idle time for the app to buffer more items while the user is still reading existing content."
Google has failed miserably? You might want to tell them that. I'm pretty sure their iOS dept will be shocked to hear that.
The scrolling physics are wrong because they made the horrid decision to emulate that stupid bouncy scrolling. The damn stuff makes my head hurt compared to the subtle, glow effect rather than shit bouncing around my screen. If they would let Chrome for Android handle the scrolling natively, I'm quite convinced that this app would feel as fast as the native app.
But then again, I know that I'm spoiled with Chrome for Android.
Google's current iOS apps are great, the previous releases, the ones with heavy HTML use, were definitely not. I don't think they would be shocked by this, a guess supported by the fact that they have new, completely different ones.
It's wrong for Sencha to force the bounce where it doesn't belong, but that's not what I was referring to and the physics are wrong on iOS too.
Haha. Jesus this whole thread was a disaster I should've stayed away from. It's a bunch of people who don't know what they're talking about spewing years old tropes about HTML that aren't even true.
Gmail, Google+ are both HTML wrappers on iOS. I'm not sure what to tell you, those are well known facts, easily confirmed with half an ounce of Googling.
I wish most developers would turn to HTML5 today, like right now, and avoid native apps at all cost unless there is really no alternative.
Why?
Because I remember the browser wars and how much it was a terrible idea and the terrible experience it made for users who simply could not experience the internet from a single starting point. This time it's not simply a matter of downloading another browser, if there's content I want to consume and there's not a native app for my phone, what do I do? I buy a different one? What about the content that I already consume and that's not over there? Should I have multiple phones?
I could not care less if it's optimize to integrated well with the native environment or some whatnot, let the browser handle that with default behavior. I want the content, the feature, and not wait for companies to port over apps from one place to the next.
This platform cult is pretty meaningless to me, in fact I don't even want to buy any device right now because I'm pretty sure I'll get burned as a user either way. The only platform I'm betting my money on as a user is the upcoming Firefox OS. Hopefuly Mozilla will be able to undo the damage done in this fragmented mess, again.
I was with you until you said "This platform cult is pretty meaningless to me." Actually the platform wars are quite meaningful insofar as they represent large-scale manipulation of consumers. Both Apple and Google are playing the following game: hey consumer, here's a shiny device, it's pretty cheap and then we lock you into a 2-year contract, meanwhile you acquire apps that can only be run an iPhone, and now even if you wanted to go to Android, you are faced with the prospect of ditching your entire software library (or vice-versa). It's called lock-in and it's a long-term manipulation of a market. I'm sure that both Apple and Google rationalize that it's a way to recoup R&D costs, and that's true enough, but it's a sneaky way to do it.
There's also the not insignificant problem of app security. Not so long ago there was a news item about the FB native app accessing contacts and uploading them to FB servers. The web app cannot do that, and that's a Good Thing.
There's also another reason why HTML5 apps are better than native: they are composable. There isn't much out there other than search engines that takes advantage of this fact, but webapps can be composed, parsed, and otherwise uniformly manipulated in useful and interesting ways. Android and iOS do indeed offer some integration points for their native apps, but nowhere near at the level that the web allows today.
The web app already has all my data on a server somewhere. And that web app is 99% of the time closed source. And the company can cut me off, change the TOS or sell my info to advertisers. Now THAT's a lockin.
While you identified the problem, the solution is a truly open mobile OS, not webapps.
How does a truly open mobile OS (and applications, presumably) solve the problem of vendor-specific data lock-in? Data lock-in is a totally separate, and far more difficult, problem. Part of the reason is that our data a) probably wouldn't exist, and b) probably doesn't make sense out of the context of being mixed together with everyone else's data. There is a strong a priori centralizing force for some important kinds of data.
You moved effortlessly from "app" to "content I want to consume," as if apps are mere passive content delivery channels. But they're not: they're tools. A well crafted tool is a pleasure to use, while a bad tool can make any task miserable.
Tools matter even for content delivery! Hulu recently migrated their PS3 app from native to something that's apparently based on web technologies, and the experience became much worse in almost every way: slower loading, laggy scrolling, more confusing interface. Hulu ships on many devices and I think they hope to share aspects of their front-end, but with their new app, watching TV became more difficult and less pleasant.
I don't believe you when you claim to not care, that you would rather live on the lowest common denominator in perpetuity than be faced with a transient zero.
Is an app that you have to fight with really better than no app at all? If it didn't exist, at least you wouldn't have gotten in a fight!
There's many sites that I consciously avoid on my phone because they work so poorly that I don't even want to bother. These sites do mobile users no service by existing. An app or website has to at least meet the "user will tolerate it" bar.
The future is bright for HTML5 apps, clearly. There will come a time when everyone's phone is fast enough to run apps like the FB clone Sencha made and the need for native apps will start to diminish. However, we're still in the transition period where there are a sufficient number of older phones on the market that don't run HTML5 apps well, so until they are filtered out your best option is still native.
I do hope this app silences the HTML5 critics out there who say you can't get a good UX with HTML5, though. The proof is in the pudding.
>The future is bright for HTML5 apps, clearly. There will come a time when everyone's phone is fast enough to run apps like the FB clone Sencha made and the need for native apps will start to diminish.
I believe you're wrong. The question isn't whether HTML can keep up with what exists today but what is offered in the future natively.
We are already living in a world with data caps and it will be so for the foreseeable future. That alone hinders the capabilities of the web. We're not even including the distrust that consumers have for paying for something unless it is through a system owned by Apple, Amazon, Google and MS. This is even including Gen Y users.
I have no doubt that the web is the future but the future is a ways off. There are just too many obstacles that are in the way currently.
I'm not sure I understand the connection to data caps. HTML5 allows you to cache apps and data locally, and wrappers like Trigger.io and Phonegap allow you to run an HTML5 app completely on the client without any reliance on data from an outside network.
In theory, yes. In practice: after all that shamanic dance trying to get all this to work you will wonder, what's the point.
Native is just much much simpler to develop and more performant to run. Yes, you loose the cross-platorm appeal, but which will appeal more to your potential user: an app crafted to run on a few platforms (and therefore alien on all of them), or an app crafted with a specific platform in mind?
Not many predict that desktop apps will be replaced by web apps soon, but for some reason this a popular view regarding mobile. But it is backwards: on desktop you have much more room to manoeuvre.
I think it is more likely we will see the web going a bit back to its roots with a more pronounced cloud-web gaining prominence, basically backend servers talking to apps (and browsers) API calls and JSON exchange.
> after all that shamanic dance trying to get all this to work you will wonder, what's the point.
Shamantic dance? It's trivial to the point of being a non-factor. You wrap your app in Phonegap, and make json requests to the web if you need data from there. Otherwise, it is stored and runs on the client.
> Not many predict that desktop apps will be replaced by web apps soon, but for some reason this a popular view regarding mobile.
For most things, desktop apps were replaced by web apps. Which is why Facebook doesn't maintain a desktop app (or Hacker News for that matter). HTML5 proponents have never made the claim that it will replace all native apps. Instead, it will replace data/list style apps like Facebook or productivity apps, which frankly, make up the vast majority of apps in the app store.
> You wrap your app in Phonegap, and make json requests to
> the web if you need data from there.
You know what? I think you should try to do all those things you deem so easy, and then we can talk. Or you can google for phonegap success stories.
> For most things, desktop apps were replaced by web apps
Can you name a few? I was impressed with GMail in 2004, in 2012 I am using Sparrow to read and write my email.
> Instead, it will replace data/list style apps
In Cocoa Touch I have highly optimised UITableView for that. In HTML I have what, UL, OL and LI? And If I need to handle selection, edition, caching, cells with different layouts: HTML5 is still superior? Should I send markup over the web too? Or should I go mad trying to make offline cache work properly?
If I am doing native I have CoreData. If I am going web route what do I have, IndexedDB? Or do I?
>And If I need to handle selection, edition, caching, cells with different layouts
I'm not going to touch the rest of your comments but mutability of presentation is really not the place to wage your battle against HTML/CSS/JS from. Dynamic presentation is really web tech's strong point.
Building a well-made hybrid app requires a lot more work than developing an equally performant pure native app, I agree (assuming your standards for 'well-made' are sufficiently high; a vanilla PhoneGap app doesn't quite cut it).
There's a trade-off, though: a hybrid app is a lot more work, but in return you generally get much shorter dev times when creating new content. It's not always the right design decision to make, but there are use cases where it's worth the investment.
Maybe I'm wrong but, when I consider apps, I also consider gaming a part of the equation as well, since they are the most popular apps. We've already seen OnLive fail because the web is simply not ready to handle the tasks of real-time gaming for enthusiasts.
I think that OnLive is a very bad example to use when talking about web gaming, because, well, it wasn't web gaming. It was an attempt to shoehorn gaming platforms onto the web- little surprise that it failed.
That said, web gaming right now isn't good. But if WebGL becomes popular then there's no reason for it not to become a perfectly usable platform.
I disagree with this comment. If anything the video shows that the HTML5 version here does not lose state when moving between feed and wall. So in effect, it consumes less data when used.
Also, FB is an online community so there is no way to get content, whether native or HTML5 without data plans on your phone. While the native app will be able to cache some content, FB will never make it large enough because they want to get site traffic (and hence ads)
I was tasked with creating the phone app for the company I work for. Here are the key points:
- The project took 2 months for me to learn the sencha framework AND to build the app from scratch (it's live in the app store).
- The app performs well on the iphone 4, but the best performance is on the iphone 4S and later.
- The Android version is not as smooth. It's significantly slower. This means it's not truly cross-platform.
- People with the iphone 4S / 5 don't know it's not a native app until I tell them.
Similar experience here. We actually decided to scrap our Sencha app and go with a hybrid app where some UI components were done using native code and most of the app was done in vanilla HTML5/CSS3/Javascript. It's working out very well so far.
I'd like to clarify one thing. The "native" Android app that was tested, isn't actually native. Native newsfeed shipped in Facebook for Android 2.0, but 1.9.2 was used in the comparison. Thus, the comparison was between two html5 implementations of newsfeed. That said, I'd love to see a side by side video with Facebook for Android 2.0.
I suspect they misunderstood the "HTML5 is not ready" statement. Indeed, HTML5 can perform, and the future is bright. However, as plenty of people in the comments here have mentioned, for mainstream devices.. it's not ready. The frameworks are still coming up a learning curve, the hardware devices out there are still struggling to adopt proper HTML5 support and decent performance. Those points alone lend credit to the fact that it's just not ready.
Yes, but it will be ready, and the question is will devs and firms that have invested all their time into native development be ready too? It would be prudent to be ahead of the curve when the horizon is so clearly visible.
The problem with being a platform that serves such a large audience (indeed, one that gets paid based on the eyeballs it can sustain) is that you need to cater to the largest range of devices and their performance.
It's the same reason enterprises still support such obscure browsers and OS's (XP/IE6). They just aren't willing to sacrifice the overall experience of those who are slow to upgrade in favor of pushing the technology forward.
You don't have to support obscure markets if you don't want to. I'd say covering iOs 5+ and Android 2.3+ is going to cover an area most companies would be pretty happy with.
And let's not forget that OS fragmentation affects Native developers just like it does HTML5 developers (especially on Android).
It was also clearly visible 3 years ago. It's nice to be an HTML5 advocate, but lets be realistic, it's 3-4 years before HTML5 will be coming even close to native in performance or tooling.
In the meantime all those native developers will be kicking your ass in earnings and functionality.
> In the meantime all those native developers will be kicking your ass in earnings and functionality.
There's no need to get testy. There's no reason why HTML5 proponents can't implement some or even all of their apps in Native code (as I do). Without getting into a religious war, though, it's important to understand where the puck is going in addition to where it is currently.
Nitro Javascript engine? It could be an important difference between this test and FB's app. Safari gets it. It seems ambiguous still whether UIWebView users get it.
A more apples-to-apples comparison would be to put it in a iOS app running UIWebView and see if the performance is maintained. I'd certainly be interested in the results.
It's not ambiguous. On iOS, only Safari can JIT JavaScript. This is because Apple doesn't trust your app enough to let you made code pages. It also doesn't trust the app it makes when you install a web app to your home page (and it's not just a Safari bookmark).
I suspect the latter may change, but I wouldn't count on the former.
Performance is also great in a wrapped version. The bottleneck we had to solve was in event management, the GPU & compositor not in the JavaScript execution.
Good work. But they are cheating in one main spot:
- they use a proxy to cut down data transfer
Good choice, but comparing it with the orignal app is not valid anymore (its not really html5 that is making it faster)
Anyway its still a very fast mobile app, and html5 is sometimes the best choice to make.
Because it is very expensive to write a different app for all platforms currently.
However, currently, it is also very time consuming to have a html5 app that is on-par with native, and works well in both android and iphone.
So its a tradeoff really, html5 is not better than native, or vice versa.
To me the most impressive thing is that Sencha Touch can run at any reasonable performance level. Has anyone used the framework? iirc there's >1mb debug JS, randomly-generated element IDs, a mess in general. The thing would hang my chrome for a couple moments just to parse the js. Obviously this is solved with minification/dynamic script loading, but Sencha's kitchen-sink approach really doesn't seem to help much in the area of performance.
You're supposed to use the build tools to generate a file with only the subset you need for your project.
By the way, the download time for the native app is also non-zero. With appcache you pay the framework's download cost only once. Admittedly it still needs parsing to load, but i haven't had this seconds-long parsing experience myself in my sencha touch app.
> You're supposed to use the build tools to generate a file with only the subset you need for your project.
Both Ext and Sencha Touch are very monolithic. When you use Sencha Command to pair your app down to just what it uses, it still pulls in well over 90% of the framework.
HTML5 is cool and you can do a lot with it, but it has some very real drawbacks - like Android.
Also, if you are doing a bunch of optimizations to make it fast on HTML5, then you're basically doing the same work as writing a native app, so what are you gaining by doing a HTML5?
Seriously, at some point you can get a better user experience, have better access to native API's and can really leverage the full abilities of the device by going native. So, you know, go native.
Disclaimer: I have wrote HTML5 mobile apps and I think it's a great developer experience, but it feels worse as a user.
But this argument makes no sense. When you go native, you have to write N number of apps for N number of platforms you want to support. The point is that making a great mobile app is hard no matter what stack you choose to use.
It's also a bit disingenuous to say you are forced to optimize every HTML5 app. The whole point of Sencha's blog post is to advertise the fact that they've abstracted away all those optimizations you need to do so that developers can focus on building cross platform HTML5 mobile apps.
HTML5 is not the only way to achieve cross-platform. In native world, HTML5 is just "one of them". There are many cross-platform frameworks and you can choose any one you like. Look this report.
Actually this is a big reason I dislike HTML5 (or I think HTML5 is wrong). Developers don't have freedom on languages and APIs. There are no healthy competition.
And don't forget that web browser itself is a multi-platform application. You can use Chrome and Firefox on Windows/Mac/iOS/Android. These are written in a "cross-platform language" C++.
In addition, most video games are written in C++ so many games are released on multi platforms (Xbox360/PS3/PC/iOS/Android). I suspect most web developers don't even know this...
> HTML5 is not the only way to achieve cross-platform.
Nobody here, as far as I could tell, was suggesting that.
> In addition, most video games are written in C++ so many games are released on multi platforms (Xbox360/PS3/PC/iOS/Android). I suspect most web developers don't even know this...
But wait, aren't iOS apps written in Objective-C using Cocoa Touch and Android apps written in Java? I don't think you can simply write your app in C++ and call it cross platform.
> Actually this is a big reason I dislike HTML5 (or I think HTML5 is wrong). Developers don't have freedom on languages and APIs. There are no healthy competition.
I've honestly never heard lack of freedom as an argument against HTML5. This argument is strange. How is iOS any more "free" than the web?
Where are you getting your "quadrupled" number? It makes sense to claim writing two native apps two cover two platforms is roughly twice the work of covering one platform, but in now way does the claim that writing an HTML5 app requires 4 times the time and effort it takes to write a native app. If that were true we wouldn't even be debating this topic today.
> at some point you can get a better user experience, have better access to native API's and can really leverage the full abilities of the device by going native
This is very increasingly untrue.
>, if you are doing a bunch of optimizations to make it fast on HTML5, then you're basically doing the same work as writing a native app
This has never, ever been true for me, not even counting the fact that I don't have to make 3-4x the number of native apps, especially given BB10 coming out next year.
They take offense to Zuckerburg's "HTML5 isn't quite there yet" comment but in order to keep their implementation quick they had to build a custom iframe framework in addition to their TaskQueue and AnimationQueue implementations to replicate the fb timeline. It seems like that was part of Zuck's point - why would a company with a deadline take on all that technical debt to replicate things that you essentially get for free on a native platform?
Actually, you don't get those things for free on a native platform either. What we did in Fastbook has a lot of similarities to what the Facebook team had to build for themselves on top of Android:
You're forgetting one small point: you have to write two (or more) native apps once you go that route. Hence the reason Facebook's Android native app came out roughly 6 months after their iOS native app did.
That's true but wouldn't you (as of today) still be much more comfortable going that route with a non-trivial project? Less time spent on the cutting edge battling the idiosyncrasies of the platform and more time building your app.
It depends on the resources available. If I were a CEO and the company was flush with cash, I'd just brute force it by hiring native developers across all platforms or farm it out to specialized native dev shops. If was a CEO of a smaller company tight on cash with a bunch of web developers, however, I'd go the HTML5 or hybrid route because it'd be the best utilization of my company's time and resources. This isn't a black and white issue.
Definitely agree. I'm not sure why many people think its just so cut and dry. The tradeoffs between html5 vs native are pretty much known at this point. Take those and rationalize along with the resources you have available, the cost, and time you can afford. Just ship something.
you also need to write two (or more) web apps too. Each OS has dramatically different user interface paradigms. Sure, you can run an iOS looking app on Android or Windows Phone, but it's going to be awkward and out of place.
Looking at this from a different point of view maybe altogether, one of the big issues I think concerning HTML5 mobile web apps (not used in a native app wrapper to get included in the appstore) is discovery.
Where do I actually find compelling mobile web app user experience when I am trying to solve a problem in my web browser as a user when I search using a search engine?
I noticed a few years ago that Google cut out their mobile only results option - and now when you search for anything on a smart phone you get a mish mash of mobile friendly and conventional web optimised results. For a little while there Google would put a little mobile icon next to mobile optimized results - but that has gone too. I know perhaps the point of mobile is moot now - since we have a sizeable amount of tablets accessing websites too. But just in my own personal research all my friends who aren't techy say they much prefer sites that look right on their 'touch' (be it mobile or tablet). For instance, is there even such a thing as a 'mobile web app store' out there?
If consumers had an easier way of finding great mobile web apps perhaps this would grow this channel? I'd be interested in perspectives on this - maybe I'm looking at it the wrong way.
I'd also like to make the case that I think HTML5 will continue to make a very important contribution moving forward - why? Because as we get more devices, it's really starting to get silly how many apps I constantly need updated and feel like I need syncing. I think as prices come down we will find ourselves with several devices for home, out and about and at work - using the 'fat client' model of installing all these apps just gets annoying.
A lot of the points that they make in the video are just flaws with Facebook's implementation of the app, rather than being a point for HTML5 or a point against native.
Truth is - HTML5 apps can be made to perform well but there are limits. Battery life suffers and you may find in future that the cool animation/whatever you wanted to add in is too laggy (especially on older devices).
Older devices will slowly dissipate from the market because of the ubiquitous two-year contracts, though, and eventually everyone's phones will be capable of delivering native-like performance on HTML5 apps. It's only a matter of time.
Doubled from awesome to... awesome? Native performance is the goal. I don't see how much better a data heavy native app like FB can get, but I do see how HTML5 apps can get better.
Really? If anything I would have thought that HTML5 was more battery efficient- there's only so much you can do with it, after all.
I spent a long time optimising a mobile webapp I was working on and while it was 95% there, that last 5% bugged me to no end. So I investigated native options. But I learnt to avoid mixing CSS3 box-shadows with transition animations and that sort of thing- you definitely suffer in FPS.
Of course native is more efficient - it takes fewer CPU cycles to get what you want done. Now you're right that as a result you might be more likely to include animations and effects etc which will drain more power, but that's a choice you can make.
It started with the implementation of an Infinite List Component that handles items with unknown sizes. Only a very small set of DOM nodes is actually created to fill in the actual visible screen area. They will then be constantly recycled to render next / previous data on-demand. As a result, memory footprint is kept minimal, regardless of the amount of data in the Store. Making this work is the easy part. Making it fast with the complexity and variety of items such as News Feed stories is the real challenge. The bottleneck lies within the core processes that a browser has to perform: layout and compositing.
I wished jQuery Mobile has Infinite List Component that handles the list item recycling the last time I used it. It is the equivalent of UITableViewCell's dequeueReusableCellWithIdentifier.
I have just finished a mobile app in HTML5. Although it works fine on iOS and Android 4.x, it caused many problems on Android 2.x. As Android 2.x still has more than 50% of Android market share it is a platform we cannot ignore. I am sticking to native development for now.
I agree with you. I was going to ask this same questoin. From TFA, they stated above. Well, that really sounds like Mark Zuckerberg didn't know what he was talking about at the beginning of this year!
A lot of people are still on Android 2.X as you have stated, and a lot of people are on slow Android devices. I know several people on ZTE Blades running 2.3 which were available over a year ago for less than £100. Sure, not the snappiest of devices, but usable. What is the HTML5 version going to be like for these users?
Blah blah blah, hardware limitations, you can't limit yourself to lowest denominator etc. But Facebook HAS to support all these users. And it's not just users in the western world. There are millions of users in third world countries who pretty much exclusively access Facebook from mobile phones, usually not the latest spec (or even close) or most up to date s/w version (I doubt many would even know how to update it).
I agree that web apps are the way to go. But it is VERY much going to depend on your target audience.
I'd say the problems the Facebook team ran into were related to the universal difficulties of HTML5 development. The tools are nothing compared to native app development. In making native apps, developers can visually create the GUI, double-click an element and immediately program its response. But with HTML5, everything is done programmatically, with great pains. When you run into problems you have to debug JavaScript, CSS, HTML, and any client libraries, possibly written in yet another language. The tools just aren't there, so continuing to maintain an HTML5 app that performs quickly and nicely like "Fastbook" does is far too costly, considering how much more easily a native app can be created and maintained.
HTML5 can be fast just like Native applications, but you need to know how to make it faster. Hopefully we are going to get more awesome libraries and frameworks like Sencha Touch to make our life easier.
This. It's a lot harder to screw up when using native SDKs vs. the plethora of HTML5 frameworks, some which are more mature than others but none really seem to have a "standardized" way to easily make a performant app in the same way that the native SDKs do.
We saw the latest generation of mobile devices — running at least iOS 5 or Android 4.1 — push ever increasing performance and HTML5 implementation scores.
Do the new native FB apps only run on iOS5+ and Android 4.1+? HTML5 may be ready on those platforms, but Android still has a lot of 2.x phones floating around. How do the HTML 5 benchmarks for iOS 5 run on the original iPhone 4?
Although I have to admit that Sencha's implementation isn't all that great. If you're going to offer an alternative, at least make it better than the other option.
I agreed that writing app in HTML5/CSS/JS is easy to mantain. But why not get access to those native features too? Hybrid apps seem to be very logical way to build apps now.
Take a look at many emerging services like http://trigger.io and get the best of both world.
This is cool, however, I'd say HTML5 has a bright future regarding web-based apps, or apps with a specific use case where you pull some data and display it in a list/table view etc ..
HTML5 will never be as capable as native if you have many other use cases (ex: image/video processing, music recognition ) ..
I think its very possible to imagine a world where HTML5 can be just as good as native. It comes down to two things:
1) HTML5 needs more JavaScript APIs to access hardware like camera, contacts, etc. It's is not very difficult to imagine HTML6 (if you will) supporting this in much the same way that it supports geolocation today.
2) Improved JavaScript performance. It's common knowledge that the embedded web views on iOS are much less capable than Safari. There's no reason to think this would continue forever. Furthermore, better JavaScript performance makes things like image progressing, music recognition possible.
Right now, you are absolutely correct that HTML5 is not as capable as native. No argument there. But, this gap narrows as time goes on. I firmly believe the opposite of you; we will eventually see a time when web-based applications rival native apps in terms of power and functionality. You can already do some awesome image processing stuff using canvas and JavaScript.
1 is more or less already here. Both Chrome and Mozilla are working on it and collaborating on specifications: WebRTC, Mouse lock, Fullscreen, low level Audio creation, MediaSource API for appendByte() style free-for-all video.
It's already becoming easier to build interactive rich applications with web technologies. Frankly, most people aren't paying enough attention.
If you insert a big image into the DOM, MobileSafari locks up for quite a few frames (whether or not it's preloaded.) Sencha's implementation just swaps pictures when you're not doing anything else! But most native apps can update photos while you're actually scrolling around.
Where are the benchmark reports on phone's from 1.5 to 4.1? 64% of android phone's are still pre-honeycomb(3.0). HTML5 on Android is good now but it sucks on those earlier phones. I am sure Facebook has to take care of everyone.
I think the problem with HTML5 is that Android and iOS treat it like a second class citizen. For all its faults, the one thing Windows 8 got right was that it allows developers to build native apps using HTML5.
The problem with HTML5 are the different vendors with their different opinions. And that problem will make native apps faster and easier to maintain than html5 for the next few years....
All the HTML haters (I jest, but that's not a totally unfair characterization of some here) should check out the Chrome team's efforts for Web Components (although I think the name just changed) for Dart/W3C spec, and AngularJS.
They make building HTML apps much, much, much more similar to building native applications.
That being said, it was really smooth on my iTouch 5G.
The demo HTML5 app also runs in Safari. The problem is that Safari's Nitro JS engine is much faster than the older JS engine used in a UIWebView (I think the restriction is supposedly due to security).
For the moment, native is still the way to go, IMO. But I've always believed that at a certain point iPhones/Androids and their browsers will be powerful and efficient enough to negate any performance drawbacks to HTML 5. I think that point might arrive by the iPhone 6 or so, when developers might feel comfortable dropping support for the iPhone 3GS and equivalent. In fact, many devs are already dropping support for the iPhone 3GS.