Live data from Hacker News

Making Facebook's native mobile app faster using HTML5

sencha.com

51–60 of 166 posts

Re: Making Facebook's native mobile app faster using HTML5

#51

Earlier quoted context omitted.

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.

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.

Re: Making Facebook's native mobile app faster using HTML5

#52

Earlier quoted context omitted.

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.

> HTML5 allows you to cache apps and data locally 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…

Have you actually done it? It's not that hard at all compared to a native app...

Re: Making Facebook's native mobile app faster using HTML5

#53

Earlier quoted context omitted.

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 n…

Everyone hated it.

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.

Re: Making Facebook's native mobile app faster using HTML5

#54

Earlier quoted context omitted.

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.

> HTML5 allows you to cache apps and data locally 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…

> 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.

Re: Making Facebook's native mobile app faster using HTML5

#55
post #10

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 wro…

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.

Re: Making Facebook's native mobile app faster using HTML5

#56

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…

> 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.

Re: Making Facebook's native mobile app faster using HTML5

#57

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…

>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 foreseeab…

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)

Re: Making Facebook's native mobile app faster using HTML5

#58
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.

Re: Making Facebook's native mobile app faster using HTML5

#59
post #37
post #27

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 ) ..

"HTML5 will never be as capabable as native..." 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…

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.

Re: Making Facebook's native mobile app faster using HTML5

#60

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 a…

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 th…

It's all about who is able to get their VM in the most places; Java already lost that battle and Flash is on the way out.

It seems like JavaScript is the new ActionScript.

Post reply on HN