[gisenberg]

There's a bit of irony in that the strengths of HTML5 shine through when confined to a single environment. If the best experience comes from targeting a single environment, then why go web at all? Further, HTML is considered a strong contender for true cross-platform app support, which is where it fails the hardest. In my experience, it's less effort to target native apps per platform than to try and use something like PhoneGap for apps of reasonable quality and complexity.

The single environment HTML5 showcase is also often supported by another development team who is actively trying to support their specific use cases; Microsoft with IE/WinJS, Mozilla with Firefox/WebOS, Sony with a PS4-optimized WebGL implementation, etc.

When the big players hit roadblocks during the development of something as high profile as their UI for their next-gen console, the browser can be changed on-the-fly to overcome them. That option isn't available to the rest of the world, and "audio doesn't work like we need it to" being a solvable problem can certainly influence whether or not you believe HTML5 is a suitable app platform.

[kllrnohj]

HTML5 and WebGL are two entirely different things. If anything this would be evidence that HTML5 isn't a suitable app platform, because even though they spin up a browser they decided to not use it and do everything with custom OpenGL ES instead.

[erikpukinskis]

> it's less effort to target native apps per platform than to try and use something like PhoneGap for apps of reasonable quality and complexity.

Sorry, are you saying that it's the effort for you to build a native Android app, a native iOS app, a native Windows Phone app, and a mobile web app combined add up to more than the effort it takes to make a single web app and get it to run well on Phonegap on multiple platforms?

That's a pretty bold statement. Are you on a big team? I would expect you'd need at least a half dozen developers to pull off four separate apps, while I can easily imagine a single person building a web app that could run well in PhoneGap.

I just spent six months building a quite complex single page web app with the hope that I could in the future package it in PhoneGap (or similar), so if what you're saying is true then I'm fucked, because it would take me easily a full year to build 3 native apps of the same complexity. Probably much longer.

[gisenberg]

In my experience, implementing a sufficiently complex app in PhoneGap targeting Android, Windows Phone, iPhone and iPad is absolutely more work with lower quality result than doing native versions of each app through Xamarin.

HTML apps have a tremendous hurdle to overcome. Customer expectations are different between something opened in a web browser and something downloaded from the app store. Apps that are amazing as web pages can be awful as apps. The amount of effort required to get a web application to perform in a way that matches user expectations for native UI cues, animations, quality and responsiveness across platforms is enormous and incredibly more difficult than your standard web app.

Of course, if you target just one platform, things get a lot better, but at that point, why not just use the native tooling?

This has been my experience, having tried both approaches over the course of several years, across team sizes ranging between one and ten developers.

[erikpukinskis]

Ah, I see. All that matters for me is that it works and it looks good. I constantly modify my designs so that they are as easy as possible implement, without losing any usability. There are no fancy transitions, no fancy widgets, just a handful of animations where they are necessary for comprehensibility. My focus as a designer is on what users are able to do with my app. All my design effort is in service to that.

I don't have the resources to care about nativeness. I think you're definitely right that if you want something that behaves like a native app you're much better off just building a native app. I suspect for most people that level of nativity doesn't materially affect their business though.

[gisenberg]

One thing to keep in mind is that targeting a browser is not the same as targeting an API level. API levels guarantee consistent behaviors across different targets, but if you use the WebView, you'll encounter different behaviors across the same version of Android across different hardware vendors. Debugging PhoneGap apps isn't exactly painless, either.

It's a bit of magic to see a game work reliably across Android devices dating back to Froyo with excellent performance. Running your web app on the same hardware is not quite such a delight.

It's also interesting to note the bigger players that have recently made the transition from HTML5 to native apps. That said, the good enough bar may be good enough for many people.

[marknutter]

Netflix has been using HTML5 for their mobile apps for years and the vast majority of people you will ask about it, developers or otherwise, probably don't realize it. It can be done, and is being done by many apps out there. And no, it does not take as much effort as writing N native apps for N platforms.

[gisenberg]

YMMV.

There's no argument that it can or can't be done, only that the time and cost to implement is equal to or greater than implementing N native apps. Wouldn't mind a contradictory citation for apps that have taken the plunge and found it to be worthwhile, and that the write-once-run-anywhere promise was fulfilled to their satisfaction.

You'll notice that the Windows Phone Netflix app certainly isn't using the same approach as the iOS and Android counterparts, and the iOS/Android versions use a non-trivial amount of native UI components for their respective platforms.

[camus2]

> Sorry, are you saying that it's the effort for you to build...

native development takes advantage of sdks you wont find on your html plateform ( which is really an hybrid app, since you depend on phonegap container,so it's still native somehow, you just abstracted it away ,so it's not an html app ). so you are just building a packaged website.

> I just spent six months building a quite complex single page web app

define complex.

> while I can easily imagine a single person building a web app that could run well in PhoneGap

Except your app wont have a native feel , wont follow the plateform guidelines regarding ux since you are not using native widgets and will feel like a second rate ux on the plateform yo u are developing on.

Let's not even talk about performances. Is Your app multithreaded ? can it run on the background and to some stuffs while the user is on another one ? can it display anything on the user homescreen ? see , unless you go native , your capabilities are limited to the least common denominator instead of embracing the platerform , maybe that's why you spent 6 month on building it.

[christocracy]

Background geolocation and background fetch are possible with PhoneGap.

https://github.com/christocracy/cordova-plugin-background-ge...

https://github.com/christocracy/cordova-plugin-background-fe...

[camus2]

Of course since phonegap is just an hybrid app container. Someone had to write that java and objective-c code for you.

[christocracy]

Why must it have been "someone" else who wrote it for me? I wrote it.

[hrktb]

> Sorry, are you saying that it's the effort for you to build a native Android app, a native iOS app, a native Windows Phone app, and a mobile web app combined add up to more than the effort it takes to make a single web app and get it to run well on Phonegap on multiple platforms?

Actually, depending on the level of quality you need, yes. A very basic form based app can be better served by a phone gap app, and be of better general quality.

But the case where you won't be helped by a cross platform solution are numerous. It is obvious if you heavily need performance or rely on a lot of native API where you want very fine grained control (you might even not want feature parity between platforms, if some platform give better tools than an others), or use native third party libraries.

But even in cases where you require near pixel perfect layouts for a wide range of devices, or have unusual set of rules to position or move your elements, handle device rotation in non standard ways. In these cases you might be better off doing native apps as many times as you need to. It seems extremely wasteful, but dealing with hacks on top of hacks in a single HTML+CSS+js codebase relying on an extra abstraction layer enclosing wildly different platforms is a hell in itself.

edit: spelling

[cdata]

As a developer who has working on and in the browser platform for a long time, I totally agree that the irony of stories like this is thick.

On the other hand, watching browser technology evolve from whatever IE6 was into the sole interface presentation layer for top tier operating systems has been fascinating. Browsers may have failed to bring us a "one true platform" by themselves, but the technologies involved are quickly reaching ubiquity.

[gisenberg]

On a long enough timeline, HTML wins and posts like mine look dated and short-sighted. There's no doubt that things are getting better, and I can't look at at an in-browser demo of Epic Citadel and say that HTML isn't good enough for native apps. Once the tooling catches up, it'll be a moot point.

That said, things are also getting worse.

Fragmentation on the browser and device side is worse than ever. Implementation starts with caniuse.com, followed by ripping out the feature later when browsers support (or partially support) features differently across tablet, desktop and mobile form factors. Mobile browsers tend to be an absolute disaster, in which something as simple as a div with overflow-y requires Herculean effort to implement across devices spanning Android 2 to Windows Phone 8. That's something that should be brain-dead simple, and things don't get much better once you move beyond that.

One popular train of thought I've had enough of is "consistent implementation of X isn't a problem, just include library or polyfill Y and things will be great", which is a mindset that tends to defer problems over solving them when the solution eventually tips over and requires in-depth bug fixing or a from-scratch reimplementation.

[_random_]

Epic Citadel is not implemented using HTML - it's WebGL and JS. Furthermore it's asm.js. And asm.js is an output of C++ transpilation. Why on earth would you run it on tablets instead of just using existing C++ code base to get native performance on all devices?

[pjmlp]

And lets not forget it is based in the 2006 release of Unreal Engine.

So in 2013, WebGL offers a 2006's 3D GPU performance.

[coldtea]

>So in 2013, WebGL offers a 2006's 3D GPU performance.

I hope you don't say it dismissingly, because to me it's amazing already (given all the other conveniences it gives).

[eonil]

Did you mean feature?

Performance comes from GPU device, not the interface.

Interface like GL just defines features, not how it should perform.

[pekk]

Didn't you hear that Javascript is now faster than C?

[eonil]

Nope. I heard LuaJIT does in some cases. So bring some numbers. I want to check it out.

[_random_]

In some sort of carefully "crafted" regex tests? Also a language can't be faster, did you want to say that JIT is faster than native?

[camus2]

> On a long enough timeline, HTML wins

As a developer never ever take any technology for granted, ever.

> I can't look at at an in-browser demo of Epic Citadel

I have a pretty decent laptop , this demo wont run on any browser. The performances are just not here , they are nowhere near native even on desktop.

[icebraining]

It depends on the drivers and such as well, though. I have a Sapphire HD5750, which was a low-end card two years ago, and the demo works fine, with the CPU barely hitting 30%.

[nevir]

You're missing the point.

The value judgement for using a web rendering engine on your _closed_ system barely touches on "cross platform" benefits. The primary concern is whether or not the rendering engine saves you time and effort.

People seem to forget that browser engines are fantastic at a wide variety of tasks:

* Best in class UI layouting.

* A great scripting engine.

* Very performant rendering pipelines (for what they're doing).

* Easy extension points when integrating with your native layer (e.g. exposing your own 'native' JS objects).

* Fantastic dev tools.

* Etc.

Browser engines are a _platform_. Why reinvent the wheel?

[_random_]

> Best in class UI layouting

XAML is best in class, HTML is legacy and illogical

> A great scripting engine

yet a crappy script language

[tuxracer]

If the sole purported benefit of HTML5/WebGL was cross platform then you may (debatable still) have a point. Cross-platform or no, these tools can be incredibly efficient for developing UI.

[rfnslyr]

I disagree. I work at a bank on a complex mobile investment application and we're building it on top of Phonegap. The barrier of entry is easy, people can pick up HTML5/JS/CSS in no time. We were building it in OBJC before and while it wasn't a disaster, the people we hired ended up costing over 8 million more than our current team because it's very hard to find real specialists in OBJC.

The beauty is we have one responsive code base that works PERFECTLY on over 20 devices. It's pretty awesome.

[eonil]

Are you trying to compare UX of banking app to game console? Seriously?

[rfnslyr]

Am I supposed to sit here and make your point for you or are you actually bringing something to the table?