Live data from Hacker News

Making Facebook's native mobile app faster using HTML5

sencha.com

91–100 of 166 posts

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

#91

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

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.

Cross-Platform Developer Tools 2012 | VisionMobile http://www.visionmobile.com/product/cross-platform-developer... > the landscape of 100+ cross-platform developer tools

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

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

#92
post #83

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…

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.

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

#93
I'll be saying this as a user.

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.

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

#94

Earlier quoted context omitted.

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

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. Cross-Platform Developer Tools 2012 | VisionMobile http://www.visionmobile.com/product/cross-platform-developer... > the landscape of 100+ cross-platform developer tools Actually this is a big reason I dislike HTML5 (or I thi…

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

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

#95

Earlier quoted context omitted.

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.

Ratings are far from a scientific way of deducing an app's value.

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.

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

#96
post #93

I'll be saying this as a user. 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 an…

Well put. The worst usability problem an app can have is simply not existing.

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

#98

Earlier quoted context omitted.

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…

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.

Because each single browser out there has a different understanding of what HTML/CSS/JS means.

Making web sites that comply to customer requirements down to pixel level, across all required target browsers is a major pain.

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

#99

Earlier quoted context omitted.

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…

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

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

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

#100
post #98

Earlier quoted context omitted.

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.

Because each single browser out there has a different understanding of what HTML/CSS/JS means. Making web sites that comply to customer requirements down to pixel level, across all required target browsers is a major pain.

Not true. A reasonably large subset of HTML/CSS/JS is perfectly cross-platform if you:

1. Use industry standard libraries (jQuery or a lightweight alternative.

2. Can ignore pathologically broken browsers (<=IE7 mainly)

Post reply on HN