7 ms·

The limit we've run into with iOS is not getting a good looking UI. Rather it's the performance of Javascript in Safari. We have a fairly large one page webapp

The limit we've run into with iOS is not getting a good looking UI. Rather it's the performance of Javascript in Safari. We have a fairly large one page webapp that looks great on iOS however the performance is an order of magnitude slower on an iPad than Chrome on an old laptop.

Touche 13y ago
Tried React?
stevekinney 13y ago
My understanding is that only Safari gets access to Nitro (Nitro : Apple :: V8 : Google). Web Views inside native apps don't get access to Nitro. Even web apps that you save to your home screen don't get access to the faster rendering engine. This is apparently for security reasons. I think it's one of the biggest barriers to web apps being competitive on iOS. (The other is that there really isn't a good installation story.)
- Touche 13y ago
  They made poor initial design decisions which effectively put a speed limit on JavaScript apps. Currently they are not motivated to do the probably very difficult work it would take to fix the problem, that's why it's so important that the Chrome team gets its shit together and makes the speed of Chrome Android awesome (which, to their credit, is a goal for this year). Unfortunately the lack of competition on mobile makes innovation very slow, there's no motivation to make rapid improvements.
  - x1024 13y ago
    It's really easy to "fix the problem". There have been fixes on Jailbroken devices for years.
    - maxmcd 13y ago
      I'm not going to make an assumptions about how hard it is for apple to solve the problem, but I'm sure people writing solutions for jailbroken devices have a much greater degree of flexibility when it comes to making changes to the OS.
      - deleted 13y ago
        [deleted]
- mikemoka 13y ago
  "security reasons" (= http://bit.ly/1d7p5Tq http://bit.ly/1d7p5Tq) it would be interesting if they elaborate on those...
  - wildpeaks 13y ago
    More like "job security" reasons as they have less control over webapps than apps.
    - streptomycin 13y ago
      Same reason I think they're dragging their feet on various parts of HTML5 that everyone else has already implemented, such as IndexedDB.
      - rimantas 13y ago
        You forgot to mention the part where Apple was first to implement features that later become known as HTML5. Also, the story of Web SQL and IndexedDB is not so simple.
        streptomycin 13y ago
        Can you tell the story that explains why Apple has done nothing with IndexedDB for years while every browser vendor implemented it a while ago? Because the story as I see it is very clear: Apple embraced the web when they had very small market share, and they're doing the opposite now that they have a good chunk of the market. Walled gardens generally aren't very profitable if you have only a tiny fraction of the market. Of course, it'll be hard for you to tell a convincing story because (AFAIK) Apple hasn't even commented on IndexedDB. Strange, for such a well-established open standard. Even MS has supported it for years!
  - robmcm 13y ago
    My understanding was that Safari used JIT which is prone to security issues with how it executes that code. As to why it's safer to do so in Safar that in a webview must be because the only API to safar is from the JS/HTML/CSS but with a webview you have a C/ObjectiveC API from the other side, which may be harder to protect against. [EDIT] - More information on the topic from Gruber http://daringfireball.net/2011/03/nitro_ios_43 http://daringfireball.net/2011/03/nitro_ios_43 although there is no reason given as to why a UIWebView is more at risk from exploits than Safari.
- deleted 13y ago
  [deleted]
- dirtyaura 13y ago
  Nitro, to my knowledge, only optimises Javascript performance, but JS performance is not the only bottleneck. We noticed that DOM manipulation together with style and layout calculations play a big part, see http://blog.mikie.iki.fi/2014/02/some-numbers-on-mobile-safari-rendering.html http://blog.mikie.iki.fi/2014/02/some-numbers-on-mobile-safa... It's very tough to make a quality app using HTML5 if you use gestures and animations. Coding it in native Cocoa/Objective-C is much easier at the moment than trying to polish that last 10-20% of your HTML5 app performance.
odonnellryan 13y ago
Can I see it?
- forgotAgain 13y ago
  Sorry but we're limiting public access while we work out some issues. There will definitely be a Show HN when its ready for public viewing.
marknutter 13y ago
My take on this is that phones are only getting faster and people upgrade their phones far more frequently than they do their laptops/desktops. Compare what you're able to do with HTML5 apps today on modern phones to what you could do even 2 years ago and it's astonishing how fast things are progressing.
- tluyben2 13y ago
  In the end HTML5 will work fine on phones. That'll take a few years yet though; currently it's shit. It's ok on an iPad, but compared to native, not so much. I like nice responsive HTML5 or HTML5 apps for stuff I use sometimes; like booking tickets, hotels, checking what's on TV and such. For stuff I click in all day long, like bugtrackers, PM systems, CRM, etc, HTML5 on mobile or desktop, is just wasting time. It's just not very nice to work with productively. This is improving fast on the desktop by building in provisions for being (temporarily) offline, easy drag & drop, offering small native plugins to interact with it, but it's not there yet. On phones it's far from being a nice and productive experience; you can see that well when you 'quickly' check a task and end up trying to swipe something 10 times because it lags and swearing profusely. Which happens with all badly 'cross platform' written apps which are mostly HTML5.
  - mike_hearn 13y ago
    HTML5 was supposed to be the answer when the iPhone 1 was first announced. It still sucks many years later. Draw your own conclusions ....
- forgotAgain 13y ago
  That's analogous to the advance of desktops. The hardware kept getting faster ("what Intel gives") but at the same time the software became more complex ("Microsoft takes away"). If you deliver software based on it performing better on future revs of hardware, you're going to get a reputation for delivering pokey software.
umsm 13y ago
I don't know the details of your app, but I have a feeling that there are many places where you can optimize it. You can't just take a desktop app and stick it on the phone. It will perform poorly. But you have to design mobile (web) apps from the ground up relying on the strengths of the mobile platform. One idea is to limit the functionality of the mobile app. Tasks which are very UI heavy should probably be simplified or removed.

Touche 13y ago

Tried React?

stevekinney 13y ago

My understanding is that only Safari gets access to Nitro (Nitro : Apple :: V8 : Google). Web Views inside native apps don't get access to Nitro. Even web apps that you save to your home screen don't get access to the faster rendering engine. This is apparently for security reasons. I think it's one of the biggest barriers to web apps being competitive on iOS. (The other is that there really isn't a good installation story.)

Touche 13y ago
They made poor initial design decisions which effectively put a speed limit on JavaScript apps. Currently they are not motivated to do the probably very difficult work it would take to fix the problem, that's why it's so important that the Chrome team gets its shit together and makes the speed of Chrome Android awesome (which, to their credit, is a goal for this year). Unfortunately the lack of competition on mobile makes innovation very slow, there's no motivation to make rapid improvements.
- x1024 13y ago
  It's really easy to "fix the problem". There have been fixes on Jailbroken devices for years.
  - maxmcd 13y ago
    I'm not going to make an assumptions about how hard it is for apple to solve the problem, but I'm sure people writing solutions for jailbroken devices have a much greater degree of flexibility when it comes to making changes to the OS.
    - deleted 13y ago
      [deleted]
mikemoka 13y ago
"security reasons" (= http://bit.ly/1d7p5Tq http://bit.ly/1d7p5Tq) it would be interesting if they elaborate on those...
- wildpeaks 13y ago
  More like "job security" reasons as they have less control over webapps than apps.
  - streptomycin 13y ago
    Same reason I think they're dragging their feet on various parts of HTML5 that everyone else has already implemented, such as IndexedDB.
    - rimantas 13y ago
      You forgot to mention the part where Apple was first to implement features that later become known as HTML5. Also, the story of Web SQL and IndexedDB is not so simple.
      - streptomycin 13y ago
        Can you tell the story that explains why Apple has done nothing with IndexedDB for years while every browser vendor implemented it a while ago? Because the story as I see it is very clear: Apple embraced the web when they had very small market share, and they're doing the opposite now that they have a good chunk of the market. Walled gardens generally aren't very profitable if you have only a tiny fraction of the market. Of course, it'll be hard for you to tell a convincing story because (AFAIK) Apple hasn't even commented on IndexedDB. Strange, for such a well-established open standard. Even MS has supported it for years!
- robmcm 13y ago
  My understanding was that Safari used JIT which is prone to security issues with how it executes that code. As to why it's safer to do so in Safar that in a webview must be because the only API to safar is from the JS/HTML/CSS but with a webview you have a C/ObjectiveC API from the other side, which may be harder to protect against. [EDIT] - More information on the topic from Gruber http://daringfireball.net/2011/03/nitro_ios_43 http://daringfireball.net/2011/03/nitro_ios_43 although there is no reason given as to why a UIWebView is more at risk from exploits than Safari.
deleted 13y ago
[deleted]
dirtyaura 13y ago
Nitro, to my knowledge, only optimises Javascript performance, but JS performance is not the only bottleneck. We noticed that DOM manipulation together with style and layout calculations play a big part, see http://blog.mikie.iki.fi/2014/02/some-numbers-on-mobile-safari-rendering.html http://blog.mikie.iki.fi/2014/02/some-numbers-on-mobile-safa... It's very tough to make a quality app using HTML5 if you use gestures and animations. Coding it in native Cocoa/Objective-C is much easier at the moment than trying to polish that last 10-20% of your HTML5 app performance.

odonnellryan 13y ago

Can I see it?

forgotAgain 13y ago
Sorry but we're limiting public access while we work out some issues. There will definitely be a Show HN when its ready for public viewing.

marknutter 13y ago

My take on this is that phones are only getting faster and people upgrade their phones far more frequently than they do their laptops/desktops. Compare what you're able to do with HTML5 apps today on modern phones to what you could do even 2 years ago and it's astonishing how fast things are progressing.

tluyben2 13y ago
In the end HTML5 will work fine on phones. That'll take a few years yet though; currently it's shit. It's ok on an iPad, but compared to native, not so much. I like nice responsive HTML5 or HTML5 apps for stuff I use sometimes; like booking tickets, hotels, checking what's on TV and such. For stuff I click in all day long, like bugtrackers, PM systems, CRM, etc, HTML5 on mobile or desktop, is just wasting time. It's just not very nice to work with productively. This is improving fast on the desktop by building in provisions for being (temporarily) offline, easy drag & drop, offering small native plugins to interact with it, but it's not there yet. On phones it's far from being a nice and productive experience; you can see that well when you 'quickly' check a task and end up trying to swipe something 10 times because it lags and swearing profusely. Which happens with all badly 'cross platform' written apps which are mostly HTML5.
- mike_hearn 13y ago
  HTML5 was supposed to be the answer when the iPhone 1 was first announced. It still sucks many years later. Draw your own conclusions ....
forgotAgain 13y ago
That's analogous to the advance of desktops. The hardware kept getting faster ("what Intel gives") but at the same time the software became more complex ("Microsoft takes away"). If you deliver software based on it performing better on future revs of hardware, you're going to get a reputation for delivering pokey software.

umsm 13y ago

I don't know the details of your app, but I have a feeling that there are many places where you can optimize it. You can't just take a desktop app and stick it on the phone. It will perform poorly. But you have to design mobile (web) apps from the ground up relying on the strengths of the mobile platform. One idea is to limit the functionality of the mobile app. Tasks which are very UI heavy should probably be simplified or removed.