Live data from Hacker News

Why LinkedIn dumped HTML5 and went native for its mobile apps

venturebeat.com

41–50 of 105 posts

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

#41
post #2

> We always have to support HTML5 because so much of our traffic comes from email. When we were [serving] a smaller group [of users], we were hoping we could duplicate all that mobile web work to make our clients faster in terms of code deploys. This has been my experience as well. When you click on a link in an email, the LinkedIn site would take you to the login screen. This screen is so heavy that it takes an inor…

This is my pet peeve lately. I get e-mails from LinkedIn about my friend's new job or an article someone posted in a discussion group that looks interesting. I click the link in my Mail app, and it switches over to my browser, which takes me to a 20-second splash page, which then prompts me to type my e-mail address and password to log in, and then I'm asked if I want to "get the app," which I already have. Since the web app is terrible, I close my browser and then go open the native app and try to find the thing I clicked on in my e-mail, if I still care enough at that point.

They need to do something to fix this experience, which is quite broken.

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

#42
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…

HTML5 only stinks less on a powerful workstation. Even spiffy designer demos done to show off its features turn my i7 into a space-heater. You don't build a standard with input from economic interests, you build it with technically sound planning.

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

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

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

#44
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…

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.

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

#45
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 the app worked brilliantly not only on the desktop, but on the iPad, iPhone, Android devices, and so on. There were small edge issues, but overall it was simply brilliant, and for an investor on the go they could easily get an up to date snapshot of their portfolio with dynamic graphics, etc. It was a complete win for the web.

Yet even there a narrative erupted where some people pushed hard for native apps. That this tiny team of six developers that apparently needed to fracture to start building iOS, Android, etc, clients. 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").

Sure, if you have the resources of LinkedIn and Facebook, feel confident making those decisions. For the rest of us, HTML5 is pretty fracken amazing.

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

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

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?

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

#47

Earlier quoted context omitted.

> 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 interest. He's probably saying that the entire app is a single html page, and all the content is loaded using ajax and created programatically. This process na…

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

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

#48

"There are a few things that are critically missing. One is tooling support — having a debugger that actually works, performance tools that tell you where the memory is running out." "The second big chunk we are struggling with is operability, runtime diagnostics information. ...there aren’t as many great tools to support that, as well." Could be me but looks like there is an oppertunity for professional HTML5 perfor…

The problem is it's dependent on the runtime. A debugging tool for Chrome, wouldn't necessarily work in Safari or IE.

You need the runtime vendors to provide them. Chrome has been really good at this, but are there tools for mobile Safari, Android browser, IE10 or mobile Chrome etc

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

#49

Earlier quoted context omitted.

> 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 interest. He's probably saying that the entire app is a single html page, and all the content is loaded using ajax and created programatically. This process na…

> I don't think theres any walled-garden conspiracy going on here - I honestly think this is the fault of the linkedin devs (or more likely project managers). What does a linkedin app need to do? Mostly they just need to do is display profile text and a few images inline. A mobile browser can display text and images perfectly fine - thats its bread and butter functionality. If you're having problems there, you done f…

Sorry, I think I worded that confusingly. By 'what does the app do?' I meant more along the lines of 'how much would a front-end client tax the technical limitations of a smart phone?', so that is the hypothetical question I was answering. I'm not insinuating that linkedin is a simple service in terms of what info people might want to store on a database about each other.

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

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

In some browsers, removing the ability to zoom removes the 300ms delay that the click event has before it fires.

You can use 'touchend,' but in certain cases this causes another set of bugs because the click event follows anyway.

To fix this in a cross-browser way, you need to write some extra logic. There are several implementations floating around of various quality.

Post reply on HN