Hacker News Reader

Comment by kevincennis | Hacker News Reader

Facebook's current app isn't slow because it's written predominantly in HTML5. It's slow because it takes forever to retrieve assets from their servers.

There's nothing magical about Objective-C that's going make the HTTP requests quicker.

The whole "native vs web view" performance debate is about things like animations and scrolling and rendering, not about the speed of retrieving assets from a remote server. And that's what's terrible about the current iOS app.

View on HN

User perceptions play into performance more than you'd think. If the HTML app can't scroll or transition smoothly, or it's spinning up new WebViews and you have to wait (there is an inherent delay in loading any content in a new UIWebView), then users will say it's slow. Not to mention memory usage of HTML elements, and managing that whole mess (the "rococo pandemonium" of HTML CSS and JavaScript, as Tim Bray put it) of objects in (usually) one giant container...

I've never found a situation where a WebView-based app is better than native.

Download LinkedIn's iPad app. It's a situation where a WebView-based app is as good as native.

Sorry, but I'd disagree. The transitions aren't very smooth and often times you're faced with a blank screen while waiting for assets to load.

I was actually very hopeful that the app would feel as good as native after I'd read about it, but I was disappointed.

It may have to do with the hardware. On my iPad 3 it feels exactly as good as native.

That hasn't been my experience. "It's as good as native" seems more driven from hope than reality, or more generously, ignorance of the differences that would stick out like a sore thumb to someone intimately familiar with the native platform.

I note that you're a web developer. Full disclosure, I work in the native mobile development space.

I do native development as well as web development. It's easier to get a performant native app than an HTML5 app, no question. But you can create a native feeling HTML5 app that really only the trained eye of a developer would be able to notice the difference of. Most people don't even know the difference between a native and an html5 app. Devices will continue to get faster, and just like on the desktop native applications will be relegated to hardcore apps like 3d games and content creation programs like iMovie, etc.

Completely agreed that a well-optimized native app will outperform a well-written HTML5 app every time. I do think, though, that the difference is getting smaller - especially for apps like Facebook, which are almost entirely content-driven. Things like games are obviously a totally different story. Even five or ten years out, it's hard to imagine HTML5 games with WebGL or whatever seriously competing with native apps.

I completely agree with that - but I'd argue that the overwhelming majority of "slowness" felt with Facebook's iOS app revolves around lengthy requests, not a lack or responsiveness on user interactions.

Personally, it's both. The application stutters for me constantly. I use my thumb to scroll, and the application does not respond for a second, then quickly catches up to what I did. That I assume will be fixed by going native.

I'd imagine that the average, non-HackerNews-reading user is far more sensitive to "this takes FOREVER to load" than "this scrolling is choppy".

And yet Apple spent a ridiculous amount of time and money to make sure scrolling would be glassy smooth.

I imagine both bother them about equally, but that they don't distinguish between them. They're both just the app being "slow." To be clear, the scrolling isn't just a little choppy. It's a delay of a full second sometimes.

Can't native apps be smarter about caching assets than UIWebViews?

You can override the default caching when you're using a UIWebView as well.

Yes however for users Interface speed = speed. Native apps have more leeway in faking the feeling of speed because even if you're waiting for a request you can still fill out the rest of the interface and start using it. HTML5 can feel sluggish because even a 100ms delay is noticeable to the user.

But again: the latency is coming from downloading the assets... you are not going to get a 100ms latency from using a web view unless you are doing something wrong. I use web views in my app, and the views that can be built from local or cached content are honestly native performance (if you feel spinning up a webview itself takes a while: just keep a pool of them, it really isn't that hard), but the things that require talking to a server are considered slow (to which I respond "duh").

This is one thing I've wondered wrt the current FB Apple app. I wonder if they pool/cache their UIWebViews or if they're instantiated each time.

I agree. Sometimes it's fun to think of the limiting case: all data on the device locally and displayed in the simplest viewController. Then step towards the real app and you most likely come to your conclusion. Only corner case I can think of is the previous engineers went overboard on the networking code on the device. In theory the facebook apis are plenty fast but the networking code on the device is a c or c++ mess and the current engineers are using higher level objective-c libraries.

Reply on news.ycombinator.com