Hacker News Reader

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

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

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.

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.

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

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.

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

It is very frustrating, mobile web is being held back to allow the walled Gardens to prosper. They expect the web to die and apps to rule the world but this is a fallacy since we will loose so much freedom and info if this had to happen. Also we are seeing the bad side of apps which are "redundancy" and a lot of pointless apps that should actually just be web apps. These apps don't use any of the device capabilities. Also apps decay really quick, if you have an older device you find that you end up updating the app and it runs really bad whereas on the web you can still use a Pentium 2 and browse the web. At some point i am hoping that the market moves towards providing the browsers access to the device api's, until then we have to crank out the objective C and Java!

With Firefox and Tizen OS the dream of web first should move closer to reality. Count on Mozilla to move the web forward!

Really Apple hasn't given enough support for web standards ?

Because I wonder where the world would be today without WebKit.

In the same place ... the webkit revolution started with V8 when we saw how fast web stuff and javascript can be. As long as there was any kind of layout engine for google to stitch their VM to the revolution would have happened.

Apple deserves a lot of credit for their support for WebKit, particularly in its early days. But even old time apple webkit devs will readily admit that the existence of Mozilla made WebKit much more viable back in the day. Mac's had practically no marketshare during those days. The fact that Mozilla existed and had a reasonable amount of marketshare across platforms made it possible for Apple to ship anything other than IE as a default browser on Mac. Mozilla maintained the incentive for webdevs to support non-IE browsers, and use standards-compliant CSS. Desktop Safari as a default browser would not have been a viable product if so many webdevs had not already worked to make their sites work well with Gecko/Firefox. Webkit sends "like Gecko" in its user-agent string for a very good reason.

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.

Just fine. It wasn't WebKit that helped prop up web standards. It was Mozilla.

  > 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

They can do. Fire away mobile safari and browse whatever you want.

  > This discussion is meant specifically for browsers supplied on
  > iPad/Android tablets

Then this is so wrong. Take a look where the first appearance of <canvas>, hardware accelerated CSS transforms and animations took place.