

How LinkedIn built its new iPad app - nikunjk
http://venturebeat.com/2012/05/02/linkedin-ipad-app-engineering/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Venturebeat+%28VentureBeat%29#s:1-linkedin-ipad

======
fpp
This is basically a HTML5 app with a native wrapper for all the things you
need access rights to - security, storage, comm etc...

From their dev. site ([http://engineering.linkedin.com/mobile/linkedin-ipad-
using-l...](http://engineering.linkedin.com/mobile/linkedin-ipad-using-local-
storage-snappy-mobile-apps))

"...LinkedIn just released a brand new iPad app built using HTML5,
backbone.js, and underscore.js. The app includes a rich stream of information
which is a combination of network updates, group posts and news articles..."

Also interesting their code to create what they call a "container view
controller" is available under Apache at
<https://github.com/linkedin/LIExposeController>

Guess you can / you do build something similar when you create an app with
PhoneGap.

~~~
rogerbinns
Their method is also how I have built most of my Android apps. You use a
WebView for the user interface and then use the addJavascriptInterface[1]
method to allow calls from the Javascript code back through to chosen methods
in the Java code. You also need to use Java when you want native settings menu
and system search functionality.

Making calls from Java back into the Javascript is a bit more painful since
you don't get a response back directly, but is sufficiently useful to dispatch
events.

You can bundle your javascript, images, html etc in the app assets so it will
still work even if there is no networking. Depending on the app network
requirements it is also likely you'll want to do the networking from Java so
it can manage threads, connectivity, saving resumable state in SQLite
databases.

This approach is fairly easy to develop and test (you can do a lot of it in a
desktop environment). The drawbacks are that elements of your UI may not
appear "native" and that some events are a pain from Javascript, especially
dealing with swipes.

I must admit I thought a lot of mobile apps were developed this way, and hence
this article being a non-story.

[1]
[http://developer.android.com/reference/android/webkit/WebVie...](http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface\(java.lang.Object),
java.lang.String)

~~~
gurkendoktor
> The drawbacks are that elements of your UI may not appear "native" and that
> some events are a pain from Javascript, especially dealing with swipes.

Another drawback on iOS is that it can be hard to limit the memory that your
UIWebView consumes, and it will crash the whole app if it needs to much.

------
zerostar07
What's with that Node.js part? Even if it is part of the backend it has
nothing to do with the app, so i 'll go ahead and guess either the writer is
clueless, or they spit out random trendy jargon in their articles.

~~~
wavephorm
I don't think the author has any idea what anything in that article even
means.

~~~
mcantelon
She's been covering Node for a year or so and even judged a Node Knockout
competition.

<http://mashable.com/2011/03/10/node-js/>

<http://venturebeat.com/2012/01/30/dahl-out-mike-drop/>

<http://nodeknockout.com/judges>

Here's an interview she did last year with a Node dev in which she referenced
LinkedIn's work with Node for their mobile site.

<http://venturebeat.com/2011/12/09/node-js-rackspace/>

------
HardyLeung
A nitpick on the title, cuz it annoys me. Why would anyone say "You'll never
believe X"? The X in question (95% HTML) is actually not that unusual to begin
with.

But even if X is mind-blowing, the fact is that the article was written to
show readers this mind-blowing fact. And after reading said article, should I
still be in the "never believe" camp, making it an unconvincing article? Or
should I now believe it, thereby invalidating the premise that X is something
"I'll never believe"?

I know. Exaggeration sells. But still.

~~~
grogs
Argh, sensationalism is very annoying. As a web dev who's used PhoneGap, and
I'm glad to see it's becoming an accepted approach to mobile apps... But
PhoneGap has been around for years.

Regarding responsive design: the best mobile apps/sites will have a specially
crafted mobile design, but responsive design is a good solution if you lack
the resources/need for a great mobile app.

------
tbeseda
Unfortunately, a lot of this reads as "Node.js IN the mobile app", not
"Node.js backing the mobile app".

It'd be better framed as a triumph for well composed and efficient Javascript
in a web view. (In fact, Javascript isn't even mentioned once.) Perhaps, it's
just not a publication I should be reading.

The takeaway should be as Prasad was quoted, "As long as we can make the
experience fast enough, nobody can tell the difference. It still feels right."

[ Fully expecting my next client to ask for Node.js in their iPhone app
because "LinkedIn did it." ]

------
lucian1900
I don't get what's so unbelievable, this is exactly what I'd have expected. At
least Ars Technica have done this before, Facebook too.

Using node on the server side is irrelevant.

------
jashkenas
By lucky coincidence, I just updated the LinkedIn Mobile example on
backbonejs.org this morning, with the new iPad app:

<http://backbonejs.org/#examples-linkedin>

------
paperwork
Not being an ios dev, I didn't understand the tech they actually are using. Is
the article saying that the linked in app is basically some sort of web
container (webkit?) and everything on the screen is actually html/javascript
being interpreted by the web container?

Didn't google put out a "gmail app" recently, which was basically a web
container with all content in html? I remember there being a backlash because
it wasn't a true native app. Did that app have a different problem?

Is it feasible to create nice, usable iphone/ipad apps using mostly html/js
(but have them look like native apps)/

~~~
alaskamiller
Apple's App Store app is mostly HTML too. This is a trend piece pointing out
how web techonlogies is seeing more real world uses by big name corporations,
though not a particularly new trend.

~~~
potatolicious
The App Store app is also aggravatingly slow, just like every other heavily-
webview'ed app (Facebook, and now LinkedIn I guess).

Note that desktop apps that try to do this fare little better - iTunes is
widely hated by its own users for being bloated and slow, particularly the
store component, which is entirely webviews.

In the mobile space right now, these webview'ed apps seem to be heavily
sacrificing user experience for developer experience, which is something I
cannot agree with.

~~~
marknutter
you've just described every website, ever, yet they have managed to become
quite popular despite the superior performance of native applications.

~~~
potatolicious
Right-o, except these webview-driven apps have all the weaknesses of websites
and none of the advantages. A website, from the perspective of the user, has
the advantage of being entirely frictionless - anyone with a browser can use
any website anywhere without downloading, installing, or configuring anything,
and it's always up to date. A webview-driven app still gets out of date, and
still presents the significant friction of making the user install
something... all the while enjoying _none_ of the usability benefits of going
native.

It should also be noted that the performance gap between web and native on
desktops is at least two orders of magnitude less than it is on mobile. The
difference between a website vs. a connected native app on desktop can be
something on the order of milliseconds - below user-perceptible time.

The difference between, say, the iOS browser vs. a connected native app, is on
the order of seconds, if not tens of seconds.

On a desktop with a broadband connection, the difference between a highly
optimized 1KB JSON call vs. a 500KB full HTML-CSS-JS content blob is really a
rounding error - below user-perceptible time. On a mobile that translates into
seconds where the user is entirely non-interactive - and this is before we
even get into the performance difference in rendering and input. Hell, part of
the reason why apps have taken off in mobile (where they haven't on desktop)
_is_ because of this crucial difference. People hate using websites on
mobiles, even mobile-optimized ones. The browser is such a poor experience on
most mobiles that people _will_ actively seek out the Store/Market,
authenticate, and download huge binaries just to get the better UX.

------
dguido
Nope, I believe it. I bet they also didn't use SSL at all, just like they
didn't in the iPhone app.

------
marcusf
I don't believe what he's saying about responsive design at the bottom of the
article, and certainly the motivation about context and device seems trite.
It's entirely unobvious to me that my intent is correlated with my device.
Often as not, I slouch around on the couch or on a long trip with my iphone
because I'm either too lazy or unable to use my laptop.

The article might make him a disservice though; I'd like to hear him elaborate
in his own words about it.

~~~
andycroll
No-one is advocating 'responsive design for apps' so I'm not exactly sure what
he's talking about.

It is true that a responsive design for the LinkedIn website might be a
tricky-ish project given the current (surprising?) complexity of the 'main'
site.

------
sosuke
So they used HTML5/JavaScript in a UIWebView with Node.js on the backend?
Pretty sweet, I was just remarking to a co-worker how much I enjoyed the
Updates section.

~~~
SpiderX
Their engineering blog is chocked full of information on how they built and
improved upon their site. It is an interesting read.

~~~
tantalor
For example, [http://engineering.linkedin.com/nodejs/blazing-fast-
nodejs-1...](http://engineering.linkedin.com/nodejs/blazing-fast-
nodejs-10-performance-tips-linkedin-mobile)

------
ricksta
Maybe I'm picky, but in my iPad the side to side animation is still jerky.

~~~
gurkendoktor
Same here on iPad 1. And the scrolling "bounce" feels odd too in some views.

------
waratuman
Nope, nope, I can totally believe it.

------
K2h
How do you calculated 95% of the app is remote? I am hard pressed to come up
with an equation to even start with. local code size vs total code size
required to run (where the remainder comes from HTML5 download?)

~~~
rickmode
Sounds like it was calculated by page count:

"Yes, only one screen in the entire LinkedIn iPad app is actually native."

------
vco
Let's not forget that building a quality HTML 5 interface takes as much effort
as building a quality native interface - and you have to specifically build it
for a specific platform.

I suppose the biggest advantage is that there's a lot more common code that
can be shared between platforms which potentially could cut down development
time for developing for multiple platforms.

------
st3fan
I'm just going to say it: i don't like it that much.

Don't get me wrong it looks nice and it is a functional app but I instantly
feel this is not a native app. The interactions are wrong. The scroll bounce
is not correct. There are noticable delays. The back button does a fade
instead of popping a viewcontroller. Little things like that.

------
mrchess
Anyone know the technology used for the client? Sencha? Perhaps another
library?

~~~
tylerlh
Pretty sure it was backbone and underscore. LinkedIn likes them pretty well.

~~~
mrchess
I'm curious if they integrated Sencha touch with it too. Personally I use
Backbone to layout structure, but still integrate it with Ext for specific
components.

~~~
karlshea
I poked around in their iPhone app source while I was learning Backbone and
didn't see any Sencha classes.

------
neovive
Does anyone know if LI used any specific Node modules? I'm evaluating Node.js
for a project and am trying to get a handle on the thousands of modules
available in npm.

~~~
tlack
They mention using SASS, Express, Step for async coordination, underscore.js,
and some others.

[http://engineering.linkedin.com/nodejs/blazing-fast-
nodejs-1...](http://engineering.linkedin.com/nodejs/blazing-fast-
nodejs-10-performance-tips-linkedin-mobile)

They also have a Github fork of the excellent Dust template engine, so I
presume they use that as well.

------
Cloven
"Today, however, Prasad no longer feels the need for the security blanket. “In
the tablet version of the server, we’re still using Node, but now the clients
are talking directly from the load balancers to Node, there’s no nginx.”"

I thought the headline was just another SEO attention grab, but it's actually
factually correct; there's no response to this sort of thing other than
bemused incredulity.

~~~
mcmire
I noticed that too. Sounds kinda weird and also kind of risky to me, but hey,
whatever.

