8 ms·

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

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.

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.