Ooof :(  but we on the mobile web side need to squarely face the truth before we can move forward.

Wait, THIS is his reasoning?!

We have definitely shifted from HTML5 to native. The primary reason for that is, we’re seeing that more and more people are spending more time in the app, and the app is running out of memory. 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.

His app is a memory hog and he wants spinners to be smooth?!

Most mobile html5 apps today are single page apps and thus even a small memory leak accumulates over time. Most web pages accumulate memory, but as tabs are closed, memory is reclaimed. LinkenIn used webview wrapped in a native code, thus it is a standalone app that can potentially work for extended periods of time. LinkedIn team understood the memory management challenge, as evidenced by the talk they gave on html5 performance. In this video LinkedIn's HTML5 lead Trunal Bhanse shows how they used heap snapshots in Chrome Dev tools to find the leaks. In the same talk another LinkedIn engineer actually showed how they used Chrome Timeline dev tool to measure css spinners vs animated gifs to determine that gif was much easier on mobile cpu. So they are not ignorant fools, far from it. LinkedIn html5 team is actually quite amazing, they have developed techniques that no one else has done to such a degree, as far as I know. See my conversation with Trunal on Hacker News for more details.

Since my startup Urbien is creating a new html5 mobile platform, I can share a lot more, if anyone is interested. Or you can check out Urbini, our full stack mobile client on github. We are grateful to LinkedIn guys as we have learned a lot from them. The only mistake they actually made, in my opinion, is not releasing their breakthrough code open source. Then the community would have helped them plug the leaks, which they did not catch and further the concepts they pioneered. Building sophisticated html5 mobile apps that are on par with the native apps, is a major technological feat. But recently, with the advances in hardware and a renewed browser race on mobiles, it is becoming possible. It is just we need a community effort to get there.

Yes, why didn't they open source anything?

Closing tabs is important to memory management? You'd think browsers could be more proactive.

Re: closing tabs: Yes, closing the tab, deallocates memory taken by the page, even in the browsers like Firefox, which do not have a process-per-tab model. With Chrome, almost each tab is a process, so OS is doing the full clean up upon the tab closure. You can open Chrome task manager and see that each page nowadays takes several megabytes of RAM, sometimes dozens, and in rare cases even hundreds of megabytes.

Re: browsers not keeping tabs on memory used by tabs: like with any dynamic memory management system (html, javascript, java) memory can accumulate. In case of singe-page apps, the app may keep older pages in DOM so memory will continue to grow, and the dangling references to JavaScript objects may remain (e.g. with backbone views, as in an example in LinkedIn's talk), if you are not careful. And LinkedIn was not just careful, they had a system to it. So I would say whatever they have missed, would have been picked up by the thousands eyes of a community. Even if it was some weird cases of the browser bug with memory leaks, there usually is someone very clever on the web who comes up with a ridiculous, but practical workaround.

Re: open sourcing: LinkedIn used a very small number of open source JS libraries, like backbone.js for MVC and dust.js for templating, and open sourced their own alternative to require.js AMD loader, called inject.js . LinkedIn published detailed blogs with snippets of code and did a series of great talks, also showing some code, but did not open source the rest, although I recall they vaguely promised they would. Why? I would love to ask the same question to the interviewed guy, Kiran Prasad. I would also ask him deeper questions on the points he made, which do not match what LinkedIn team has published so far. How do we get him to do the Reddit AMA?

Him doing a Reddit AMA would be awesome. Then we'd learn why.

And thanks for the explanation of why some apps bring browsers to their knees.

SPINNY THINGS RULE MY WORLD.  Also: there are ads.  By coincidence.

Native apps are faster and it is easier to get the effects you want in a lot of cases.  And you can precisely control memory usage.  Sounds like they were using large libraries and having trouble managing the sprawl there, but it will always be slower.  Additionally, with WebGL lagging, you can't do competitive graphics yet either.  Add in WebGL, WebCL, and some optimization, and the next couple generations of devices, and HTML5 will be more competitive.

Stephen, LinkedIn used very small amount of well established libraries, no sprawl. Yes, native apps are faster, but at a certain speed it will stop to matter. Mobile Safari is very smooth already, even on iPhone 4s, and mobile Chrome is progressing fast, hopefully it will catch up in several months. Android stock browser is not terrible, but far behind Safari. Since it got stuck in limbo, and since Chrome is a default browser only on Jelly Bean, and many manufacturers are still pushing Ice Cream Sandwich Android even on the newest  phones, this could have been the real reason behind the LinkedIn's decision.

re: WebGL good point, but not relevant for the LinkedIn-type informational apps.