Live data from Hacker News

Why LinkedIn dumped HTML5 and went native for its mobile apps

venturebeat.com

81–90 of 105 posts

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

#81
post #79

Earlier quoted context omitted.

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…

That they can spend the time and effort to optimize each platform should surprise absolutely no one. The first point is that you're doing this anyway with an app that has any complexity. Each mobile browser and device has its own quirks. If you're going to spend optimization time for each device you might as well go native and make the most of that time. That this tiny team of six developers that apparently needed to…

The first point is that you're doing this anyway with an app that has any complexity.

Enormously complex application with widgets, dynamic graphs, etc. Close to nothing had to be customized for those targets because it used standardization and shims where possible, and already was built to work across the major desktop platforms. I read this "you'll have to dramatically rewrite anyways" claim a lot and it simply doesn't ring true.

My point is that iOS/Android apps are not hard to build natively. That time spent means you can get the best the device can offer.

Is it possible for you to point to the app? I've done a significant amount of Android development (no iOS dev to this point) and my natural assumption is that a short effort app by people new to the platform would generally be terrible (which is sadly the case for most apps on the platform).

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

#82
post #72

Earlier quoted context omitted.

Do you have an idea for why both Facebook and Linked in, the two poster children of HTML5 apps, moved away from them? It can't be that they have a grudge against HTML or something...

Yes, actually, I know exactly why Facebook's moved away from it: the beginnings of their HTML5 mobile strategy actually pre-dated the original iPhone, and as such they were using a strategy that didn't really make sense in the post iPhone world. Namely, the app was pulling down the mobile version of their website from the server on every request , which as you might imagine meant things were generally pretty sluggish…

Thanks. How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness.

My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either. Native is more predictable. Your experience is valuable in that it proves the existence of a solution. Would you say your team is extraordinary in its capacity to wrangle with HTML, or is something like this available to your average YC startup, or to most startups out there?

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

#83
post #43
post #22

HTML5 stinks on Android (due to bugs and fragmentation) and HTML5 stinks on Win8 tablets (due to IE10 bugs, implementation differences, also supporting mouse and touch together is hard to get right due to event models). So it regularly doesn't make any sense to try and build a cross platform HTML5 solution. If you are producing a content app or business app, you might get away with it... Or if the app only needs a si…

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.

  > Html is elastic by nature, and html 5 will win over
  > native apps because it is elastic.
HTML won't win anything, first and foremost because it is not fighting anything. And HTML is neither elastic or inelastic. Calling HTML elastic is like calling an idea "green and wet". HTML is for marking up structure of the document (I am ignoring a couple of presentational attributes in HTML, but they should be ignored). CSS tells the browser is something is elastic or not.

But all that has nothing to do with winning or loosing. Users don't give a shit if it is elastic or rigid. Does it work smoothly? Great. Does it look great? Superb. Was it coded with HTML/CSS/JS? Who cares… unless it impacts the first two.

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

#84

Honestly, it is kind of sad, rather disastrous, that a leading site such as Linkedin is unable to stir things up a bit and come out with the exact truth. When he says "... we’re seeing that more and more people are spending more time in the app, and the app is running out of memory ..." what he means here is that memory allocation to the browser on iPad (for example) is too little to handle the volume of user interes…

  > users ARE interested to see the wild wild web through
  > their browsers, even porn, but it is the vendors of these
  > closed gardens that have made it difficult for everyone
They can do. Fire away mobile safari and browse whatever you want.

  > This discussion is meant specifically for browsers supplied on
  > iPad/Android tablets
Then this is so wrong. Take a look where the first appearance of , hardware accelerated CSS transforms and animations took place.

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

#85
The rise of mobile platforms that have highly capable native runtime environments is going to call into question whether a cross-platform implementation strategy will really be viable for high-value apps.

Web apps are optimal when you need to access them from multiple OSs and develop them only once. That last part "develop them only once" is important. If you want to go beyond what a Web app can do, you have now made your Web app users second class citizens. And, if you avoid implementing platform-specific features or overall architectures, you make your app a second class citizen among apps on the native platform.

In other words, for anything that more than filling out forms and looking at data, it's worth doing the best job on every platform with a significant number of users, and that means platform-specific implementations.

Or look at it this way: What if LinkedIn morphed into a kind of "people dashboard" for enterprise users, with an architecture inspired by Facebook Home, but for CRM, not for your Farmville buddies. Could that even be contemplated in a cross-platform HTML5 implementation?

Tl;dr: Operating systems still matter because they look, work, and interact differently, and they impart their advantages and restrictions to apps.

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

#86
post #44

Earlier quoted context omitted.

I'd like to know why this comment was downvoted, as I've had similar experiences.

> I'd like to know why this comment was downvoted, as I've had similar experiences. Because claiming that it stinks on Android, while true, might be interpreted as a passive-aggressive way of implying that it does not stink on iOS, which would be far from the truth. iOS's browser is archaic compared to recent and not-so-recent Android browsers.

Current and third-party browsers are good, but 40% of users are on 2.3 or older, where the stock browser (which, let's face it, 99% of users are) really is sub-par.

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

#87
post #38

> It’s not performance issues, like speed or rendering, but it’s still a big problem. > The second reason we’ve gone native is trying to get some of the animations — the spinners and the way they work — getting that smoothness, we felt like we needed native to really do that well. Those are both performance issues... > It’s not that HTML5 isn’t ready; it’s that the ecosystem doesn’t support it. … There are tools, but…

  > If the experience is the same in HTML5 as the App Store,
  > then Apple loses
What exactly Apple loses? It was the free app anyway, who cares? I don't get where this stupid notion of Apple being anti-web comes from. Their goal is to sell as much devices as possible, and provide the best user experience possible on them, that's it. They don't firewall your web apps, do they? Neither "native" devs care about killing the web, but for some reason uninformed webdevs cannot stand native apps and declare wars, battles and winning. Why? Makes yourself a favour, learn any of the native SDK just enough to make a semi-trivial app and you will clearly see what native provides and what webtech solutions severely lack and will be lacking, because the technology was not created with apps in mind.

Why it is so important to kill native in favour of web? How about learning (not really learning, just stopping to ignore) which is best for that and use accordingly? You need a website? Great, there is your HTML and CSS. You need performant app? Great, there is your SDK. You want a mix of both? Cool, take a good close look and choose wisely. Maybe mix of both.

I don't see a call to replace native desktop apps with HTML and JavaScript, why are people so hell-bent about all or nothing on mobile?

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

#88
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.

> Html is elastic by nature, and html 5 will win over > native apps because it is elastic. HTML won't win anything, first and foremost because it is not fighting anything. And HTML is neither elastic or inelastic. Calling HTML elastic is like calling an idea "green and wet". HTML is for marking up structure of the document (I am ignoring a couple of presentational attributes in HTML, but they should be ignored). CSS…

> HTML won't win anything, first and foremost because it is not fighting anything. And HTML is neither elastic or inelastic. Calling HTML elastic is like calling an idea "green and wet". HTML is for marking up structure of the document (I am ignoring a couple of presentational attributes in HTML, but they should be ignored). CSS tells the browser is something is elastic or not.

I think everybody here understands that, and the parent was using it as a shorthand for "the set of technologies commonly used in hypertext documents on the Web." It is not productive to issue a correction every time you encounter synecdoche.

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

#89
post #82

Earlier quoted context omitted.

Yes, actually, I know exactly why Facebook's moved away from it: the beginnings of their HTML5 mobile strategy actually pre-dated the original iPhone, and as such they were using a strategy that didn't really make sense in the post iPhone world. Namely, the app was pulling down the mobile version of their website from the server on every request , which as you might imagine meant things were generally pretty sluggish…

Thanks. How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness. My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either. Native is more predictable. Your experience is valuable in that it proves th…

> How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness.

We've had no issues with it so far and I heard the same criticisms you did. If you make sure not to store too much stuff in localStorage (there is a limit for UIWebViews) you should be fine.

> My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either

I get that, but it does overestimate the capabilities and resources of FB and LinkedIn. In the end, they are just developers like any other developers solving the same problems everyone else is, and simply throwing more money at the problem doesn't usually fix things. Keep in mind that there's a lot more pressure on FB and LinkedIn to deliver perfection so they are going to be less likely to "stick it out".

> Native is more predictable.

I agree, and there are lots of other benefits to native as well. They must be weighed against the detriments: having to write the same app multiple times for multiple platforms, having to play by Apple's rules, not being able to update apps for customers immediately (that's a huge problem IMO), working with painful layout tools, etc. As always, it's important to weight the pros and cons before choosing a strategy.

> Would you say your team is extraordinary in its capacity to wrangle with HTML, or is something like this available to your average YC startup, or to most startups out there?

I assure you we are not extraordinary. Anybody with a very basic level of native programming experience and who is competent with HTML5/CSS3 and the latest javascript frameworks (backbone, ember, angular, knockout, etc) can replicate what we did. I think the reason it seems extraordinary is because you only ever see articles about big, trendy companies ditching HTML5. "Small unknown team builds great HTML5 mobile app" just doesn't have the same punch. I also believe there is a bit of religious war going on between web developers and native developers so there's always a frenzy whenever there's a drop or two of blood in the water. Ignore all that crap and just choose the solution that suits both your app's requirements and your skills best.

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

#90
post #78

Earlier quoted context omitted.

Phonegap, but we do a lot of custom native stuff beyond that.

Could you expand on what you mean with "custom native stuff"?

The top and bottom bars are completely native. So when you tap on a tab, your interacting with a native interface laid out in a nib and a message is passed to the javascript app inside the main web view telling it which tab has been selected. The sliding drawers (popularized by Path and Facebook) area also completely native, but they house two other webviews that also are simply running javascript apps in them. Finally, we have a slide out "quick add" menu that we determined needed to be native both because the performance when it was implemented in HTML5/CSS3 on older Android devices wasn't acceptable and also because it needed to overlap other native elements.

The main reason we need to have some native UI components is because fixed elements are not well supported on older iOS and Android devices. That means that in the webview sandwiched inbetween our top and bottom bars we cannot have any fixed ui elements. This ensures that the scrolling stays smooth on all devices because it's really just utilizing the native webview scroller. Newer versions of iOS and Android do support native-style momentum scrolling within a DIV, but the performance isn't quite there on all but the most powerful devices (for reference, Sencha Touch's http://fb.html5isready.com uses these native scrolling divs, and quite impressively too).

There are also other features that need to be native under the hood like push notifications support, camera/photo-library support, and contacts support, etc. Thankfully Phonegap makes most of that available to us and for anything that isn't available as a Phonegap plugin we simply wrote ourselves.

The way I see it, this "hybrid" approach is a necessary stopgap for us HTML5 mobile developers while we wait for more devices to reach the capability of the fastest phones available right now (iPhone 5, Galaxy S3, etc). Eventually we should be able to do almost everything in pure HTML5 like Sencha Touch's demo linked above and ditch the native UI elements completely. There will, however, always need to be some sort of bridge between HTML5 apps on Android and iOS devices and the native APIs that are not made available to those devices' mobile web browsers (contacts, camera, files, push notifications, in-app purchases, etc).

I hope that explains it in better detail. Hit me up if you have more questions, my email is in my profile.

Post reply on HN