Live data from Hacker News

Making Facebook's native mobile app faster using HTML5

sencha.com

31–40 of 166 posts

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

#31

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.

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

#32

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

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.

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

#33

Earlier quoted context omitted.

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

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

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

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

#35

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

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:

https://www.facebook.com/notes/facebook-engineering/under-th...

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

#36
post #5

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

Battery life suffers 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 defini…

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.

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

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

This is only the beginning...

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

#38

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…

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.

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

#39

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.

Totally agree. Just like on the desktop, most gaming will probably still be done in native code.
Post reply on HN