How LinkedIn built its new iPad app
venturebeat.com
venturebeat.com
From their dev. site (http://engineering.linkedin.com/mobile/linkedin-ipad-using-l...)
"...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.
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..., java.lang.String)
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.
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.
Is it possible also that node.js is providing faster response times on the same number of servers?
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.
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.
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." ]
Using node on the server side is irrelevant.
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)/
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.
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.
The article might make him a disservice though; I'd like to hear him elaborate in his own words about it.
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.
"Yes, only one screen in the entire LinkedIn iPad app is actually native."
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.
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.
http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-1...
They also have a Github fork of the excellent Dust template engine, so I presume they use that as well.
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.