Native+Web: The New LinkedIn Apps come with Backbone, Node, and more
Posted by Dion Almaer about a year ago on mobile native web
Kiran Prasad runs mobile development at LinkedIn. He is top notch, and I have had the pleasure to chat with him in the past about mobile.
I was really excited to see that his team had shipped new LinkedIn Mobile apps across iOS, Android, and the mobile Web site.
Here they talk about their approach to building hybrid applications:
“There’s this battle between HTML5 web apps and native apps. But we’ve interspersed HTML5 in the native app, where web-based content excels. The things that are hard to do in HTML5 are a scrolling infinite list, so we went native with that.”
The reuse of HTML5 code across all three applications (mobile web, iOS and Android) will speed up iterations of the app, too. “We can grow our feature set more quickly without having to do a whole new client build,” Prasad said.
In addition to HTML5, the team also used a handful of lesser-known free and open-source tools, such as Backbone and Underscore, in developing the apps.
“The way our mobile web app works is it’s all rendered on the browser side. The value of that is you send less data back and forth, so it’s much faster.”
Also, the app is insanely lightweight. “If you take our entire app and you combine all the framework pieces and zip it, it’s under 50K,” said Prasad.
“We don’t use the browser’s caching system, so once you’ve brought the app down, unless we’ve changed something in the app, the most you have to download is 1K. So especially for international users, it’ really important to not make a bunch of extra traffic.”
To speed up performance on the mobile web app, Prasad told us, “Connections are all stored locally, also for speed and so if you’re offline, you can still access them.”
This is the same approach that we have at Walmart Labs, and we have a very similar stack.
On the client we have a lean framework that consists of: Backbone + Zepto + Underscore + Handlebars + Stylus. A special build system is able to spit out optimized resources for the various platforms, which keeps payloads as small as possible. This is why we have contributed code back such as Kevin Decker’s handlebars code that adds support for precompilation which brings massive speed improvements.
On the server, we are doing exciting work scaling out node + socket.io (WebSockets) + redis + mongo that allows us to deliver content to the devices as soon as physically possible.
In fact, if you are interested in working on modern client stacks that reach millions of people, or flushing out next generation node services at scale. Please reach out to join our small team of smart folks who are having a great time working on this.
Anyway, sorry for the aside, back to LinkedIn. I think that they have done a great job at:
- Unifying the look and feel across the platforms, but making them feel correct on those platforms
- each platform has a native shell and components
- the header is very custom, and keeps the same “linkedin brand” throughout the various apps
- The app feels fast (especially for the web pieces)
- they cache as much info as possible
- a good use of space
- when you tap on search, the screen transitions to show a search box on top so suggestions can make use of the screen
- when you tap on the touch app you will notice that the Mobile Safari chrome is hidden (scrolled off)
The native applications use the Web too. As you flick around the native apps you will actually be viewing Web content most of the time, all within a native frame. Something of interest here is the custom header. You will notice that as you transition between screens the header title will change via a transition. This isn’t a typical iOS view on the stack push transition, so it looks to be a custom component.
It is exciting to see other teams use this native+web architecture. It allows you to make many changes on the server and not have to go through the app store process, including A/B testing of your products.
I have also been rethinking some of my thoughts on how far to push things for certain mobile Web apps that users access through the mobile browser. Some applications are very content heavy. Take the scenario where someone emails me a tweet, and I tap on the link on my phone. I do not actually want to go to a site that: a) loads the app, b) puts a spinner in place, and c) finally shows me the tweet. I would actually prefer the application to show me the content as fast as possible, and then load in the app chrome even. Node can shine here.