Live data from Hacker News

Why LinkedIn dumped HTML5 and went native for its mobile apps

venturebeat.com

51–60 of 105 posts

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#51
Another one bites the dust. The app my team and I have been developing is an HTML5/Native hybrid app, much like LinkedIn's was, and their decision to move away from their HTML5 strategy is a bit baffling to me given how well things have worked out for us.

Our app has a few native ui elements like the top bar, the bottom tabs bar, a quick add control that slides in and out, and Facebook style drawers that expose two other webviews. The rest, however, is done in pure HTML/JS/CSS. Angular.js, in fact.

It runs well on old android devices with 2.2 installed, and runs really well on newer Androids and iOS devices. We take full advantage of the benefits HTML5 provides. Most of the user's important data is cached in localStorage so the app loads very quickly. We use websockets to update the app in realtime without the need to rely on long-polling or native push notifications (which we do still have). We have one stylesheet with zero platform specific hacks thanks to the fact that Android and iOS devices use webkit browsers. And laying out our app's interface in CSS/HTML is much more efficient than doing it twice either programmatically or using nib/xml layouts.

We even use http://www.tidesdk.org for desktop native apps and of course that version runs fantastically. We didn't start out using Angular.js on our main web app, but we are slowly starting to transition our mobile app codebase over to our main web app codebase. At some point we will have the largely the same code running across all major offerings of our product.

Every time one of these splashy articles about a well known company moving away from HTML5 comes out I smile knowing that the FUD it will inevitably create will allow those of us who are benefiting immensely from using HTML5 for mobile to continue to enjoy our productivity advantage.

For those who are curious, our product is http://kona.com and the mobile apps are both available in the store. I'd be interested to hear any feedback about how well the apps perform (my email address is in my profile).

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#52
post #46
post #43

Earlier quoted context omitted.

Why on earth would you disable pinch zoom on mobile web? It is the most useful feature, it allows the reader to adjust the amount and size of text displayed. I use it all the time and despise those web apps blocking it. Html is elastic by nature, and html 5 will win over native apps because it is elastic.

Pinch to zoom isn't that applicable on mobile-optimised webapps. If you have a fixed header on the top of the page what would pinch to zoom do? Make the header bigger? Or would it ignore the header and just zoom in on the body content?

This is tangential to the pinch-to-zoom discussion, but I'd say if you have a fixed element anywhere, you don't have a mobile-optmised webapp. There are plenty of Android devices with 640x480 or 320x240 out there; a fixed header in one of them looks like a big waste of screen space.

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#53
post #47

Earlier quoted context omitted.

> I bet the app had a bunch of unnecessary css animations, js widgets replacing html components, custom layouts done in javascript, etc These things are required to make an attractive app. If HTML5 can't hack it and native apps can, then HTML5 is a failure.

Well said, there is a difference between website and web app. It's a hard line to find, but there is a big difference between Gmail and Hacker News.

FWIW, the mobile web version of Gmail works well.

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#54
post #46

Earlier quoted context omitted.

Pinch to zoom isn't that applicable on mobile-optimised webapps. If you have a fixed header on the top of the page what would pinch to zoom do? Make the header bigger? Or would it ignore the header and just zoom in on the body content?

This is tangential to the pinch-to-zoom discussion, but I'd say if you have a fixed element anywhere, you don't have a mobile-optmised webapp. There are plenty of Android devices with 640x480 or 320x240 out there; a fixed header in one of them looks like a big waste of screen space.

Huh? Do you regard the title bar at the top of native Android apps to also be wasted space?

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#55
post #13

Because they're big, and have the money to sink into something that's still a bit better at the margin?

This is ultimately it. LinkedIn is now a large business, with a very large technology team. That they can spend the time and effort to optimize each platform should surprise absolutely no one. But does it apply to you and me? In most cases, not even remotely. I was recently involved with a team building a pretty amazing, full-featured web app (in the investor information space). Out of the pure magic of HTML, most of…

I typed in my comment pretty quickly, and thus ignored the point you make, but I concur with it completely. It's all about tradeoffs, and for a small team/startup, you're going to have to look at them more carefully than a big company that can just throw money at things.

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#57
post #13

Because they're big, and have the money to sink into something that's still a bit better at the margin?

This is ultimately it. LinkedIn is now a large business, with a very large technology team. That they can spend the time and effort to optimize each platform should surprise absolutely no one. But does it apply to you and me? In most cases, not even remotely. I was recently involved with a team building a pretty amazing, full-featured web app (in the investor information space). Out of the pure magic of HTML, most of…

> It was utter insanity, and of course LinkedIn and Facebook both appeared as if they were the benchmarks we should follow ("See, they abandoned HTML! So should we").

This story amused me to no end. About 18 months ago, I worked on a team that made the (not unanimous) decision to build a hybrid app, and those who pushed for that technology pointed to LinkedIn and Facebook as the benchmark we should follow ("See, they use web code in an app! So should we!")

It's easy to say this with hindsight, but we really should have just picked the best technology for our team and product, instead of assuming that larger companies knew something special or magic that we didn't.

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#58
post #27
post #12

Earlier quoted context omitted.

if one builds an "app" , since it uses a "webview" inside a native application , it is always "native" ( except for firefox and likes os where the browser is the "os" ). Phonegap and likes use native code so one can bundle html+js into a native app. I tell my clients , instead of using a wrapper , to build a webapp directly. most of the LOB-apps require an internet connection anyway , and things like camera can be ac…

No need for the patronising scare quotes. I'm talking about whether to base your app on web technologies like HTML5 and js (regardless of delivery method - web/native webview wrapper), or to use native UI elements/memory management etc of the OS.

I don't think he is trying to be condescending. He has a point that the lack of Nitro or V8 in a webview means you'll have a performance hit when you do a wrapper. HTML5 provides most of the APIs you need anyway, especially if you are on firefox OS

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#59
>The second reason we’ve gone native is trying to get some of the animations — the spinners and the way they work

Why in the world does an app like linkedin's need animations that are apparently too intensive for a browser? And they couldn't get a spinner to spin smoothly?

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#60
post #54

Earlier quoted context omitted.

This is tangential to the pinch-to-zoom discussion, but I'd say if you have a fixed element anywhere, you don't have a mobile-optmised webapp. There are plenty of Android devices with 640x480 or 320x240 out there; a fixed header in one of them looks like a big waste of screen space.

Huh? Do you regard the title bar at the top of native Android apps to also be wasted space?

I think he point is that the title shouldn't be fixed but dynamic to the device.
Post reply on HN