15 ms·

Of course web apps aren't ever going to be as fast as a native application (especially on iOS because Apple deliberately hampers performance for web apps) but t

Of course web apps aren't ever going to be as fast as a native application (especially on iOS because Apple deliberately hampers performance for web apps) but they're by no means a hopeless cause. A HTML5 web app might take a little while longer to develop, but it'll work out cheaper than building an iOS application. LinkedIn to this day remain the perfect example of how to build a straight-up HTML5 mobile app that performs beautifully.

fjarlq 14y ago
How is Apple deliberately hampering performance for web apps? What evidence is there for this?
- mille562 14y ago
  http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/ http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-op... The discussion is about apps written natively vs apps written in HTML (not web pages viewed in safari). The only method available to develop an iOS app with HTML is to use UIWebView, which is crippled compared to Safari.
- MaxGabriel 14y ago
  He's referring to web apps that are embedded inside a native wrapper. UIWebViews don't use the more performant Nitro JS engine.
- girvo 14y ago
  Due to security concerns, JIT (also known as "Nitro" in iOS parlance) is disabled for UIWebViews, but is enabled in the browser itself. I assume that is where this is coming from.
- woadwarrior01 14y ago
  I guess he's talking about javascript JIT being enabled in Mobile Safari, while not being enabled for apps using UIWebView.
- deleted 14y ago
  [deleted]
- monsterix 14y ago
  There is some evidence for sure. For example, iPad Safari doesn't allow full-screen mode, nor implements fullscreen API as per standards. Another browser on the iPad (Dolphin) supports it interestingly. Support for ordinary CSS properties like z-index, position:fixed and iframe is pathetic. Some of the things that I can recall now. UIWebView takes it to another level of pain altogether.
corresation 14y ago
Of course web apps aren't ever going to be as fast as a native application They can be pretty close because web apps are ultimately just duct tape over native code. Further I doubt Apple's lack of JIT for app-contained webviews has any material effect: JavaScript performance is grossly overconsidered, when most of the performance issues are DOM/layout problems (e.g. scrolling long lists). LinkedIn to this day remain the perfect example of how to build a straight-up HTML5 mobile app that performs beautifully. After making a big show about their web-based mobile app, LinkedIn started recanting and replacing major components of their app with native code, so they aren't the best example. But ultimately a lot of the people who cheerlead these sorts of discussions don't realize how little it has to do with what they do, because these people are talking about optimizing those final few percentages. Anecdote time, but I was involved with a team of 6 devs making some basic fund reporting tools when a breathless product manager started talking about how we should build iOS and Android apps because someone had told them about LinkedIn's pronouncement that their "power users" preferred their native rebuild. A tiny, grossly underequipped team that nonetheless managed to make a pretty kick-ass web app that actually worked great on pretty much any device people could have (including rich graphics)...yeah, fire up the iOS team to divert resources on a native app... It is nonsense. If you have a software group large enough that you can start optimizing for those edge cases (e.g. scroll a massive list of contacts) where the web apps suffer, then of course you should do it. But for the vast majority of teams simply making a cross-platform web app gets you 98% of the way there.
pjmlp 14y ago
HTML is for documents, period. People trying to force it to work otherwise is just the 21st century version of VT100 terminals. Every time I have the possibility to choose between a native and a web application on my consulting projects, I take the native approach. I get a rich experience, better integration with the operating system and overall user experience. Sadly many MBA's try to cram desktop expectations into what is a document format.
- andybak 14y ago
  That ceased to be strictly true when the FORM element was added. And it became less true when scripting was introduced. > I get a rich experience, better integration with the operating system and overall user experience. I won't argue with this point but, as with anything, there is a cost-benefit calculation that everyone has to do for themselves.
- corresation 14y ago
  HTML is for documents, period. Wow, people are still saying this garbage?
  - WayneDB 14y ago
    It's a valid complaint. At the very least, you can say that many of the problems associated with using HTML for apps stem from the fact that it was originally designed for documents, not apps.
    - corresation 14y ago
      It isn't a valid complaint: It's discardable noise. I'm sorry if that sounds overly aggressive, but whenever I read people saying nonsense like that all I can picture is someone who has spent the last 15 years shaking their fist at the inevitable ("Get off my grass! Computers are a fad! JavaScript isn't real programming!"), and of course they are drawn like moths to a flame to things they think confirms their ridiculous notions. Millions of examples to the contrary ignored. Ignoring that we've been evolving this thing for two decades now, HTML was designed for content layout. It turns out that one of the primary issues with applications is content layout (I was building "web apps" that were largely collections of ActiveX controls 15 years ago, as the simple layout rudiments of the platform absolutely blew away anything that was available in any other platform). Indeed, we've seen other "native" platforms borrow much more from HTML than the inverse.
coldtea 14y ago
>especially on iOS because Apple deliberately hampers performance for web apps They do nothing of the sort. This is total BS. On the contrary they have had (and still have) the speediest and more feature complete web engine. And for many years the Android built-in browser was a total joke compared to Mobile Safari. Chrome for mobile (on Android) is better than the Android browser (Browser?), but nothing to write home about compared to Mobile Safari.
- monsterix 14y ago
  It's not entirely BS. Yes iDevices do have the best in the breed browser but it is still far from expected level. Especially when you're comparing HTML5 websites with natively installed applications. I totally agree that Android browsers are a joke even today.
  - iSnow 14y ago
    Firefox on Android is in some ways leaps and bounds better than mobile Safari. And surely not slower. So there...
    - monsterix 14y ago
      Firefox is, and I prefer it that way, an exception certainly.
- daleharvey 14y ago
  Whether the intention is 'deliberate' or not, its still very true, UI Webviews / bookmarkarked webapps dont get Nitro. And Mobile safari is not the most feature complete web engine, its one of the least, missing very basic things like indexeddb and spotty CSS support. Chrome / Firefox and Opera all have far more modern support but only for android.
rimantas 14y ago
> A HTML5 web app might take a little while longer to > develop, but it'll work out cheaper than building an iOS > application Why would you think so? With HTML5 app you will have to reinvent/reimplement a lot of stuff that Cocoa Touch/Core Data/Whatever gives you out of the box.

fjarlq 14y ago

How is Apple deliberately hampering performance for web apps? What evidence is there for this?

mille562 14y ago
http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/ http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-op... The discussion is about apps written natively vs apps written in HTML (not web pages viewed in safari). The only method available to develop an iOS app with HTML is to use UIWebView, which is crippled compared to Safari.
MaxGabriel 14y ago
He's referring to web apps that are embedded inside a native wrapper. UIWebViews don't use the more performant Nitro JS engine.
girvo 14y ago
Due to security concerns, JIT (also known as "Nitro" in iOS parlance) is disabled for UIWebViews, but is enabled in the browser itself. I assume that is where this is coming from.
woadwarrior01 14y ago
I guess he's talking about javascript JIT being enabled in Mobile Safari, while not being enabled for apps using UIWebView.
deleted 14y ago
[deleted]
monsterix 14y ago
There is some evidence for sure. For example, iPad Safari doesn't allow full-screen mode, nor implements fullscreen API as per standards. Another browser on the iPad (Dolphin) supports it interestingly. Support for ordinary CSS properties like z-index, position:fixed and iframe is pathetic. Some of the things that I can recall now. UIWebView takes it to another level of pain altogether.

corresation 14y ago

Of course web apps aren't ever going to be as fast as a native application They can be pretty close because web apps are ultimately just duct tape over native code. Further I doubt Apple's lack of JIT for app-contained webviews has any material effect: JavaScript performance is grossly overconsidered, when most of the performance issues are DOM/layout problems (e.g. scrolling long lists). LinkedIn to this day remain the perfect example of how to build a straight-up HTML5 mobile app that performs beautifully. After making a big show about their web-based mobile app, LinkedIn started recanting and replacing major components of their app with native code, so they aren't the best example. But ultimately a lot of the people who cheerlead these sorts of discussions don't realize how little it has to do with what they do, because these people are talking about optimizing those final few percentages. Anecdote time, but I was involved with a team of 6 devs making some basic fund reporting tools when a breathless product manager started talking about how we should build iOS and Android apps because someone had told them about LinkedIn's pronouncement that their "power users" preferred their native rebuild. A tiny, grossly underequipped team that nonetheless managed to make a pretty kick-ass web app that actually worked great on pretty much any device people could have (including rich graphics)...yeah, fire up the iOS team to divert resources on a native app... It is nonsense. If you have a software group large enough that you can start optimizing for those edge cases (e.g. scroll a massive list of contacts) where the web apps suffer, then of course you should do it. But for the vast majority of teams simply making a cross-platform web app gets you 98% of the way there.

pjmlp 14y ago

HTML is for documents, period. People trying to force it to work otherwise is just the 21st century version of VT100 terminals. Every time I have the possibility to choose between a native and a web application on my consulting projects, I take the native approach. I get a rich experience, better integration with the operating system and overall user experience. Sadly many MBA's try to cram desktop expectations into what is a document format.

andybak 14y ago
That ceased to be strictly true when the FORM element was added. And it became less true when scripting was introduced. > I get a rich experience, better integration with the operating system and overall user experience. I won't argue with this point but, as with anything, there is a cost-benefit calculation that everyone has to do for themselves.
corresation 14y ago
HTML is for documents, period. Wow, people are still saying this garbage?
- WayneDB 14y ago
  It's a valid complaint. At the very least, you can say that many of the problems associated with using HTML for apps stem from the fact that it was originally designed for documents, not apps.
  - corresation 14y ago
    It isn't a valid complaint: It's discardable noise. I'm sorry if that sounds overly aggressive, but whenever I read people saying nonsense like that all I can picture is someone who has spent the last 15 years shaking their fist at the inevitable ("Get off my grass! Computers are a fad! JavaScript isn't real programming!"), and of course they are drawn like moths to a flame to things they think confirms their ridiculous notions. Millions of examples to the contrary ignored. Ignoring that we've been evolving this thing for two decades now, HTML was designed for content layout. It turns out that one of the primary issues with applications is content layout (I was building "web apps" that were largely collections of ActiveX controls 15 years ago, as the simple layout rudiments of the platform absolutely blew away anything that was available in any other platform). Indeed, we've seen other "native" platforms borrow much more from HTML than the inverse.

coldtea 14y ago

>especially on iOS because Apple deliberately hampers performance for web apps They do nothing of the sort. This is total BS. On the contrary they have had (and still have) the speediest and more feature complete web engine. And for many years the Android built-in browser was a total joke compared to Mobile Safari. Chrome for mobile (on Android) is better than the Android browser (Browser?), but nothing to write home about compared to Mobile Safari.

monsterix 14y ago
It's not entirely BS. Yes iDevices do have the best in the breed browser but it is still far from expected level. Especially when you're comparing HTML5 websites with natively installed applications. I totally agree that Android browsers are a joke even today.
- iSnow 14y ago
  Firefox on Android is in some ways leaps and bounds better than mobile Safari. And surely not slower. So there...
  - monsterix 14y ago
    Firefox is, and I prefer it that way, an exception certainly.
daleharvey 14y ago
Whether the intention is 'deliberate' or not, its still very true, UI Webviews / bookmarkarked webapps dont get Nitro. And Mobile safari is not the most feature complete web engine, its one of the least, missing very basic things like indexeddb and spotty CSS support. Chrome / Firefox and Opera all have far more modern support but only for android.

rimantas 14y ago

> A HTML5 web app might take a little while longer to > develop, but it'll work out cheaper than building an iOS > application Why would you think so? With HTML5 app you will have to reinvent/reimplement a lot of stuff that Cocoa Touch/Core Data/Whatever gives you out of the box.