Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why LinkedIn dumped HTML5 and went native for its mobile apps

venturebeat.com

Post reply on HN
Print view View original

61–70 of 105 posts

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

#61

Post by freyr »

gbog wrote: post #43
robocat wrote: 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.

Thank you! The worst is when pinch-to-zoom is disabled on an image viewing/sharing page. I believe Twitter is guilty of this. It's idiotic.

I've also heard many arguments that responsive design makes pinch-to-zoom unnecessary. A page should automagically adjust so that it's optimal for a 27" monitor, a 2" mobile display, or anything in between. It's a great idea in theory, but I've yet to see it executed well in practice. I guess it's exceedingly difficult to design an effective UI that can automatically and seamlessly scale between a large-format screen and a small-format screen.

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

#62

Post by litek »

marknutter wrote: post #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 o…

Do you use phonegap for the mobile versions, or something custom with a webview?

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

#63

Post by leephillips »

goyalpulkit wrote: post #18
theguycalledtom wrote: post #6

> We always have to support HTML5 because so much of our traffic comes from email Because LinkedIn are spamming scum.

Their marketing is quite aggressive (I have been receiving "Last month to get Linkedin Premium for free" weekly for about an year!) but I wouldn't call them spammers.

What you describe I would describe as spam. Obviously there are wildly different informal definitions of "spam" in use. By my definition, Linkedin is definitely a spammer; I get frequent email from them and I don't have, and plan to never, get an account.

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

#64

Post by gbog »

untog wrote: post #46
gbog wrote: 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?

You are not too far from carving your header in a JPEG file there. Some may remember good ol' times when most web sites did so. It was the same reason: someone decided the size must be fixed for the header to be following a fixed grid or corporate design paper, or something the like.

You couldn't select the text, it was heavy, ugly, hackish, crawling against the grain of HTML, which is elastic. Now we know better, and let content flow, adjust itself, at the will of the users (on the desktop).

This was the Dark Ages of the Web, why do we need to go through the same lows on mobile?

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

#65

Post by monsterix »

oftenwrong wrote: post #53
robmcm wrote: post #47

Earlier quoted context omitted.

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.

Mobile web version of Gmail is a very stripped down version actually. Thankfully so, but notice that even Google could not take its full-fledged Gmail app to the tablet browser (I don't expect it on a smartphone anyway).

In other words user don't get the fuller experience of web like they do on desktops. And that's exactly the point of this thread.

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

#66

Post by untog »

ArtB wrote: post #60
untog wrote: post #54

Earlier quoted context omitted.

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.

Ah, well, I meant fixed in the CSS sense rather than the "exact size" sense.

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

#67

Post by rubinelli »

untog wrote: post #54
rubinelli wrote: post #52

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?

Depending on the application and the space available, yes. That's why some aren't fixed, and some are hidden once you scroll after a certain point.

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

#68

Post by pmarsh »

While HTML might have caused struggles for them with large amounts of users I wanted to just offer up that we have found it to be quite useful in a small/medium business for enterprise apps on smaller subsets of devices. So we do not have to worry about supporting every device and OS flavor under the sun.

We are a small dev team and being able to use a web stack prevents us from being spread too thin across too many different technologies.

Is it as "smooth" as native? No, but it gets the information and functionality, the most important parts, to the people who need it and allows us to quickly turn around projects.

And not being native allows us to customize UI to fit each group's particular needs more easily. At least it seems that way.

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

#69

Post by potatolicious »

JackdawX wrote: post #29
monsterix wrote: post #8

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…

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

> "This process naturally leaks memory unless you're very, very careful."

Yes, and you can do this natively without ever leaking memory. You can refresh/delete/create new UI elements day in day out indefinitely without crashing once.

Having to tiptoe around memory leaks (that you don't even control since you don't control the runtime) for complex UIs makes a platform pretty darned unattractive.

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

LinkedIn is also a communication platform that also needs user engagement to survive. A mobile browser does not support push notifications, nor does it allow people to quickly bounce in, reply to a message, and bounce out (not without waiting for the entirety of the UI to load via browser).

There is an overabundance of apps that really should be websites - but LinkedIn is not one of them.

One of the chief problems with the mobile web is that you must load the UI every time, and there is a baseline performance impact (both network and client-side) regardless of how simple and optimized you make your app. You can launch a native app, do something, and be on your way before your browser can finish loading the UI, even assuming much of the UI is already cached (which for storage-constrained mobiles, is far from a safe assumption).

You can optimize a web app by a pretty wide margin, but the baseline means that there are a class of interactions that just aren't realistic.

> "Was the old app ever released? Did anyone have a chance to use it?"

Yes, and it was remarkably well done. At the time the canonical hybrid app was Facebook, which was crashy, slow, and awful in every single way. LinkedIn's app was at the time remarkably stable and not even awfully apparent that it was web-based.

Post reply on HN