Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Facebook's native mobile app faster using HTML5

sencha.com

Post reply on HN
Print view View original

101–110 of 166 posts

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

#101

Post by macspoofing »

pjmlp wrote: post #98
macspoofing wrote: post #61

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.

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.

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

#102

Post by andybak »

macspoofing wrote: post #62
mtrimpe wrote: post #60

Earlier quoted context omitted.

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.

>It seems like JavaScript is the new ActionScript Not even close.

Why not?

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

#103

Post by andybak »

untog wrote: post #51
technoslut wrote: post #33

Earlier quoted context omitted.

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.

Still quite happily playing Assasins Creed on my OnLive box here.

If the business model failed that isn't a point against the technology which worked very well.

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

#104

Post by rimantas »

macspoofing wrote: post #61
rimantas wrote: post #46

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.

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

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

#105

Post by cpdean »

macspoofing wrote: post #62
mtrimpe wrote: post #60

Earlier quoted context omitted.

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.

>It seems like JavaScript is the new ActionScript Not even close.

I can't wait till node.js gets ported from its fringe-language to ActionScript. Asynchronous callbacks will make Flash run so much faster.

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

#106

Post by rimantas »

andybak wrote: post #100
pjmlp wrote: post #98

Earlier quoted context omitted.

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)

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.

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

#107

Post by rimantas »

marknutter wrote: post #54
rimantas wrote: post #47

Earlier quoted context omitted.

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

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

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

#108

Post by javajosh »

ttt_ wrote: 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…

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.

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

#109

Post by rimantas »

marknutter wrote: post #63
tehwebguy wrote: post #43

Earlier quoted context omitted.

Maybe people that make this argument only care about supporting one (or two) platforms.

IMO as soon as you want to support two platforms natively you've nearly doubled your work.

And if you try to support them by doing web based app you quadrupled your work, only it is on the same code base.

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

#110

Post by spamizbad »

macspoofing wrote: post #61
rimantas wrote: post #46

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.

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

Post reply on HN