7 ms·

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

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.

erikpukinskis 13y ago
> 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 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
    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 13y ago
      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 13y ago
  > 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 13y ago
    Background geolocation and background fetch are possible with PhoneGap. https://github.com/christocracy/cordova-plugin-background-geolocation https://github.com/christocracy/cordova-plugin-background-ge... https://github.com/christocracy/cordova-plugin-background-fetch https://github.com/christocracy/cordova-plugin-background-fe...
    - camus2 13y ago
      Of course since phonegap is just an hybrid app container. Someone had to write that java and objective-c code for you.
      - christocracy 13y ago
        Why must it have been "someone" else who wrote it for me? I wrote it.
- hrktb 13y ago
  > 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 13y ago
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 13y ago
  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_ 13y ago
    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 13y ago
      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.
kllrnohj 13y ago
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.
nevir 13y ago
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?
- deviltry 13y ago
  Best in class layouting? Oh god, CSS. >:(
- _random_ 13y ago
  > Best in class UI layouting XAML is best in class, HTML is legacy and illogical > A great scripting engine yet a crappy script language
rfnslyr 13y ago
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 13y ago
  Are you trying to compare UX of banking app to game console? Seriously?
  - rfnslyr 13y ago
    Am I supposed to sit here and make your point for you or are you actually bringing something to the table?
tuxracer 13y ago
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.

erikpukinskis 13y ago

> 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 13y ago
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 13y ago
  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 13y ago
    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 13y ago
  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 13y ago
    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 13y ago
> 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 13y ago
  Background geolocation and background fetch are possible with PhoneGap. https://github.com/christocracy/cordova-plugin-background-geolocation https://github.com/christocracy/cordova-plugin-background-ge... https://github.com/christocracy/cordova-plugin-background-fetch https://github.com/christocracy/cordova-plugin-background-fe...
  - camus2 13y ago
    Of course since phonegap is just an hybrid app container. Someone had to write that java and objective-c code for you.
    - christocracy 13y ago
      Why must it have been "someone" else who wrote it for me? I wrote it.
hrktb 13y ago
> 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 13y ago

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 13y ago
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_ 13y ago
  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 13y ago
    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.

kllrnohj 13y ago

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.

nevir 13y ago

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?

deviltry 13y ago
Best in class layouting? Oh god, CSS. >:(
_random_ 13y ago
> Best in class UI layouting XAML is best in class, HTML is legacy and illogical > A great scripting engine yet a crappy script language

rfnslyr 13y ago

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 13y ago
Are you trying to compare UX of banking app to game console? Seriously?
- rfnslyr 13y ago
  Am I supposed to sit here and make your point for you or are you actually bringing something to the table?

tuxracer 13y ago

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.