20 comments

[ 2.5 ms ] story [ 50.7 ms ] thread
(comment deleted)
I write HTML5 mobile apps and I've written native mobile apps and native lets me craft the best possible experience. HTML5 is pretty great in a lot of contexts, but I wouldn't go so far as to call is superior. It might be a better fit for your project, but it doesn't make it superior in a general sense.

Just remember that the web runs on top of a runtime called a bowser and you will always be at the mercy of said browser for a lot of functionality. Without native code, you don't have access to the services that make mobile phones more special and interesting than just a really tiny browser screen with a always on internet connection wherever you go.

(comment deleted)
Well, each time a new article claiming that HTML5 has better user experience (as stated by this article "Speed and user experience"), i can't find an app that feels just right made with HTML5.

Just can't find any HTML5 app that feels better than a native app. It doesn't even feel the same, at least to me.

I've seen great apps, with great user experience, but all of them could be a lot better if they were native.

Just my opinion, no disrespect to anyone, and i'm not saying i won't develop an app with HTML5, i just think that we just can't compare them, so we should stop comparing them.

This is basically spam.

While many things in the article are just bogus, what tickled me the most is the one about how html5 helps design innovation. Hardly! In fact HTML is a terrible language for designing good ui's. The only reason we do it is because of its pervasiveness.

Extraordinary claims require extraordinary evidence. Meanwhile, let me keep thinking native gives better results...
Building a single page is just the step 0 of building a native apps. Rendering the DOM efficiently is another issue much harder to solve.
Having done both, this is laughable, native is always the correct way, you may get away with HTML5 for a few months but it will not scale, ask Facebook.

I can't be bothered to go into a full reply but...

Continuous deployment: No, your users don't want their apps changing on their phones without any interaction. "Why did app XYZ just look totally different, I didn't update it" ? They are used to an update strategy and they might not want your amazing feature you just wrote.

One code base: I get this, but this is not the way you do it, you should create a library and your applications are thin views of this, using cross platform tools like Mono-esq.

Design advantage: Meh, you have design patterns you must follow on each platform, the amount of HTML5 + Phonegap applications that look like iOS on Android on Windows phones is laughable. You can do exciting things on the platforms without thinking that CSS3 is the only way to do it.

Speed and user experience: Never in a million years, I'm not a purist, I tried using Phonegap for projects, but it always came down to speed on all devices being less than native, so why would they use ours?

This article is mostly rubbish (sorry) but the point about conintious deployment raises some questions. Does anyone have any ideas or experiences about continuous deployment with native apps? What's possible (on iOS and Android) with self-updating apps?
You can't push updates on iOS without going through the app store approval process.
Native if you an afford it, HTML5 if you can't.
As a smart phone user, I applaud the move to HTML-based apps. The storage on my phone is limited, and Android has moved towards making additional storage useless. A significant amount of that limited space is also taken up by the phone maker's notion of a UI and with preinstalled apps that I will never use and can't remove without significant hackery. If I can't fit your amazing user experience on my device, it doesn't matter.
Well JavaScript works fine in Mobile Safari, not so much on WebViews.

Apple is playing security card here by no enabling JIT compiler. The reality is probably a bit different. They could have solved the issue long time ago, but I guess for now it's just better (for them) to continue building Objective-C developer community. In some sense they are sustaining higher app quality by... making it worse.