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?
These things are required to make an attractive app. If HTML5 can't hack it and native apps can, then HTML5 is a failure.
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.
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.
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.
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.
Because I wonder where the world would be today without WebKit.
In other words, a lot of the web kept using standards (and not IE proprietary stuff) since they wanted to work in Mozilla browsers. And all of this content tended to also work well in webkit as well. This made Safari useful and viable. So, its at least somewhat reasonable to say that Mozilla and Firefox are perhaps primarily responsible for keeping the desktop browser market open for non-IE products. Their existence and marketshare allowed the newer browsers to compete on the basis features and performance and not be hobbled by poor website compatibility.
> 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
> This discussion is meant specifically for browsers supplied on
> iPad/Android tablets
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.
Mark his words, 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. 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 or enough support for web standards on their stack.
We're actually back into 1995, I think, with every other for-profit firm talking about its own "experience" and "standards" these days.
Edit: This discussion is meant specifically for browsers supplied on iPad/Android tablets. Not the desktop browsers which are not only good but also in an extremely competitive space (Thanks to Firefox!).