Facebook dropper iPhone-app bygget i HTML5 - den er alt for langsom

"Applications that are predominantly HTML5 render most of the components of an app as a Web page, pulling images and content from the Web directly into the application. Objective-C takes the opposite approach, taking full advantage of the hardware in the iPhone and then building most of the functionality directly into the application so it has to collect less information from the Web."

Hvis forskellen er, at de sparer nogle HTTP forespørgsler ved at lave en app, hvorfor cachede de så ikke bare de samme forespørgsler i deres HTML5 app?

"Problemet er, at dette kan begrænse reaktionstiderne voldsomt, fordi den indbyggede browser i apps ikke er specielt hurtig."

Nu har jeg ikke en iPhone, men er det ikke bare en Mobile Safari de benytter uden chrome? Så er der vel ingen forskel i hastighed på normal browsning på iPhone eller når apps bare åbner den samme browser uden chrome...?

Hilsen,

Frederik

De bruger en WebKit render til deres HTML5. Den samme render som den mobile version af Safari anvender. Den rigtige problem stilling er vel også at "HTML5 er langsommere end Cocoa" ikke at "HTML5 er langsomt".

En væsentlig speedup ligger i hvert fald i forskellen på at skulle hente en masse markup samt data ved en HTML5 app, kontra at kun skulle hente data ved en native app.

Hej,

Hvis man bruger Ajax kald med JSON formatteret data burde det ikke gøre nogen forskel IMHO.

Hilsen,

Frederik

Problemstillingen ligger i at det Objective-C komponent man bruger til at rendere HTML(5) i (også kaldet et WebView) ikke anvender den samme JavaScript motor som Apple Mobile Safari.

Hvorfor at javascript tung HTML(5) køre meget langsommere i en app end gennem Mobile Safari.

Dette tolkes at mange som Apples forsøg på at minimere brugen af HTML som kode i Native Apps, men kun som en mulighed til begrænset funktionalitet.

Så det har ikke noget at gøre med antallet at kald eller mængde af dataen som skal transporteres.
Facebook appen er f.eks. lige langsom om man er på Wifi eller 3G.

Håber det kan bringe lidt klarhed over problemstillingen.

Det er nemlig én af forskellen der har indflydelse på en webapps performance. Men uanset om app'en benyttede Nitro javascript engine eller ej så vil en native app stadigvæk performe mange gange bedre end HTML. Der er stor forskel på at skulle render HTML og på en native kompileret app der direkte kan udnytte hardwarens ressourcer.
Vi taler om forskel i performance med alt fra hvordan app'en reagere når du trykker på en knap til scroll i lister, animationer, rendering af billeder og video osv.

HTML5 er ganske enkelt ikke den magiske løsning på cross-platform apps som mange forsøger at gøre dem til. De har fortsat store begrænsninger og netop dette gør at en native app, i de fleste tilfælde, vil være en langt bedre løsning. Facebook er langt fra den første applikation der er startet som en HTML5 app som efterfølgende skifter til native netop pga. de mange problemer der følger med HTML5 apps.

HTML5 er IKKE den magiske løsning på cross-platform apps... I hvertfald ikke endnu!

Nyheden fra Facebook kommer, efter LinkedIn for nylig lancerede en ny iPad-app, hvor 95 procent af funktionaliteten er bygget i HTML5.

Som jeg tidligere har sagt så må man stille kraftige spørgsmålstegn ved Linkedin's påstand om 95% HTML. Et nærmere kig på IPA filen bag applikationen afslører en størrer mængde XIB filer m.m. Netop XIB filer er native interface filer(med tilhørende controllers) og indikere at app'en består af en hel del mere end 5% native kode.
At dømme ud fra filnavne m.m. så tyder det også på at en hel del af de native elementer netop er mange af de ting som giver performance problemer i HTML5 apps - Tabeller/lister, views med mange elementer m.m.

Endelig skal det nok også med i overvejelserne, at hvis der trækkes færre data fra Facebook, belaster det på længere sigt sikkert deres egne servere mindre, så de kan spare penge den vej.

Der var faktisk et par rigtigt gode sessions på Google I/O om hvordan man optimerer den slags.
Fast UIs for the Cross-Device Web : http://www.youtube.com/watch?v=ie4I7B-umbA
Jank Busters: Building Performant Web Apps : http://www.youtube.com/watch?v=hAzhayTnhEI

Et trick der bliver nævnt mht. reaktionstid ved tryk er at bruge touchend i stedet for click events, da man på den måde undgår, at browseren venter 300ms på, om det skulle være et dobbelttap.
Teknikken er forklaret i detaljer her: https://developers.google.com/mobile/articles/fast_buttons

Det løser desværre ikke en lang række af de problemer der er, som er direkte relateret til forskellen mellem den tid en browser skal bruge på at render HTML og hvor hurtigt native kode kan render et tilsvarende interface.

Men tak for links - Det er altid interessant at suge mere info til sig :)

Hvad er det for en naturlov, som siger at et "native API" kan tegne en brugergrænseflade hurtigere end en "browser"? Dit "native" program opbygger ikke skærmbilledet pixel for pixel, men bruger i stedet et API til at beskrive layout. Det er ikke nødvendigvis spor mere effektivt end et andet API som er baseret på CSS og HTML.