[JackdawX]

> 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 naturally leaks memory unless you're very, very careful. Many ordinary websites have problems with leaks, but nobody notices until you're on a phone with limited RAM. Basically, this is the wrong way to write a mobile app or mobile website (or any website).

> This is certainly not the fault of HTML5/web developers, or lovers of open web, but only of the vendors who have not provided sufficient resources

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

I bet the app had a bunch of unnecessary css animations, js widgets replacing html components, custom layouts done in javascript, etc. Was the old app ever released? Did anyone have a chance to use it?

[kalleboo]

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

[robmcm]

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.

[oftenwrong]

FWIW, the mobile web version of Gmail works well.

[robmcm]

It works, but there is a lot it can't do, and a lot of things that actually make it slower on poor connection (full page refreshes etc).

It's also interesting to note that it's a different version of the app, as is the tablet and mobile version.

A lot of people would have you believe you should have one version that fits all, easy to do for a basic website, un-feasable even when your a company the size of Google.

[monsterix]

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.

[endersshadow]

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

The question you actually answered is, "What I do with LinkedIn?" LinkedIn has a lot of functionality many of its users use every day. Things like groups, statuses, endorsements, recommendations, etc, etc. It's not just a resume viewer. Sit down with a competent recruiter or sales exec and watch them use it. It's rather eye-opening.

[JackdawX]

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.

[potatolicious]

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