Hacker News Reader

Comment by marknutter | Hacker News Reader

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.

View on HN

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

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

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

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.

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

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)

Reply on news.ycombinator.com