
Why LinkedIn dumped HTML5 and went native for its mobile apps - iand
http://venturebeat.com/2013/04/17/linkedin-mobile-web-breakup/#ygWxXrYeFLq8hzfF.99
======
marknutter
Another one bites the dust. The app my team and I have been developing is an
HTML5/Native hybrid app, much like LinkedIn's was, and their decision to move
away from their HTML5 strategy is a bit baffling to me given how well things
have worked out for us.

Our app has a few native ui elements like the top bar, the bottom tabs bar, a
quick add control that slides in and out, and Facebook style drawers that
expose two other webviews. The rest, however, is done in pure HTML/JS/CSS.
Angular.js, in fact.

It runs well on old android devices with 2.2 installed, and runs really well
on newer Androids and iOS devices. We take full advantage of the benefits
HTML5 provides. Most of the user's important data is cached in localStorage so
the app loads very quickly. We use websockets to update the app in realtime
without the need to rely on long-polling or native push notifications (which
we do still have). We have _one_ stylesheet with _zero_ platform specific
hacks thanks to the fact that Android and iOS devices use webkit browsers. And
laying out our app's interface in CSS/HTML is much more efficient than doing
it _twice_ either programmatically or using nib/xml layouts.

We even use <http://www.tidesdk.org> for desktop native apps and of course
that version runs fantastically. We didn't start out using Angular.js on our
main web app, but we are slowly starting to transition our mobile app codebase
over to our main web app codebase. At some point we will have the largely the
same code running across all major offerings of our product.

Every time one of these splashy articles about a well known company moving
away from HTML5 comes out I smile knowing that the FUD it will inevitably
create will allow those of us who are benefiting immensely from using HTML5
for mobile to continue to enjoy our productivity advantage.

For those who are curious, our product is <http://kona.com> and the mobile
apps are both available in the store. I'd be interested to hear any feedback
about how well the apps perform (my email address is in my profile).

~~~
litek
Do you use phonegap for the mobile versions, or something custom with a
webview?

~~~
marknutter
Phonegap, but we do a lot of custom native stuff beyond that.

~~~
aerique
Could you expand on what you mean with "custom native stuff"?

~~~
marknutter
The top and bottom bars are completely native. So when you tap on a tab, your
interacting with a native interface laid out in a nib and a message is passed
to the javascript app inside the main web view telling it which tab has been
selected. The sliding drawers (popularized by Path and Facebook) area also
completely native, but they house two other webviews that also are simply
running javascript apps in them. Finally, we have a slide out "quick add" menu
that we determined needed to be native both because the performance when it
was implemented in HTML5/CSS3 on older Android devices wasn't acceptable and
also because it needed to overlap other native elements.

The main reason we need to have some native UI components is because fixed
elements are not well supported on older iOS and Android devices. That means
that in the webview sandwiched inbetween our top and bottom bars we cannot
have _any_ fixed ui elements. This ensures that the scrolling stays smooth on
all devices because it's really just utilizing the native webview scroller.
Newer versions of iOS and Android _do_ support native-style momentum scrolling
within a DIV, but the performance isn't quite there on all but the most
powerful devices (for reference, Sencha Touch's <http://fb.html5isready.com>
uses these native scrolling divs, and quite impressively too).

There are also other features that need to be native under the hood like push
notifications support, camera/photo-library support, and contacts support,
etc. Thankfully Phonegap makes most of that available to us and for anything
that isn't available as a Phonegap plugin we simply wrote ourselves.

The way I see it, this "hybrid" approach is a necessary stopgap for us HTML5
mobile developers while we wait for more devices to reach the capability of
the fastest phones available right now (iPhone 5, Galaxy S3, etc). Eventually
we should be able to do almost everything in pure HTML5 like Sencha Touch's
demo linked above and ditch the native UI elements completely. There will,
however, always need to be some sort of bridge between HTML5 apps on Android
and iOS devices and the native APIs that are not made available to those
devices' mobile web browsers (contacts, camera, files, push notifications, in-
app purchases, etc).

I hope that explains it in better detail. Hit me up if you have more
questions, my email is in my profile.

~~~
aerique
Yes, that explains it. Thanks for taking the time to write that reply.

~~~
marknutter
my pleasure!

------
robocat
HTML5 stinks on Android (due to bugs and fragmentation) and HTML5 stinks on
Win8 tablets (due to IE10 bugs, implementation differences, also supporting
mouse and touch together is hard to get right due to event models). So it
regularly doesn't make any sense to try and build a cross platform HTML5
solution.

If you are producing a content app or business app, you might get away with
it... Or if the app only needs a simple HTML UI that is OK.

The main problems I have encountered are: \- good performance is very hard to
achieve \- making it reliable is difficult \- HTML5 data input is hard if you
want to do anything more than the standard controls (e.g. a searchable combo
like searching for a contact, e.g. a typable time entry field that defaults to
a numeric keyboard that you can also type a colon into). \- pinch-zoom should
be disabled (many many nasty bugs in iOS, Android, and IE10. Especially if
also trying to use fixed position). \- position:fixed is broken (e.g. on iOS,
when an input gets focus and the input is scrolled to screen centre the fixed
div is not placed properly. Android and IE10 have other problems). \- all
scrolling solutions have downsides.

~~~
gbog
Why on earth would you disable pinch zoom on mobile web? It is the most useful
feature, it allows the reader to adjust the amount and size of text displayed.
I use it all the time and despise those web apps blocking it.

Html is elastic by nature, and html 5 will win over native apps because it is
elastic.

~~~
rimantas

      > Html is elastic by nature, and html 5 will win over
      > native apps because it is elastic.
    

HTML won't win anything, first and foremost because it is not fighting
anything. And HTML is neither elastic or inelastic. Calling HTML elastic is
like calling an idea "green and wet". HTML is for marking up _structure_ of
the document (I am ignoring a couple of presentational attributes in HTML, but
they should be ignored). CSS tells the browser is something is elastic or not.

But all that has nothing to do with winning or loosing. Users don't give a
shit if it is elastic or rigid. Does it work smoothly? Great. Does it look
great? Superb. Was it coded with HTML/CSS/JS? Who cares… unless it impacts the
first two.

~~~
chc
> _HTML won't win anything, first and foremost because it is not fighting
> anything. And HTML is neither elastic or inelastic. Calling HTML elastic is
> like calling an idea "green and wet". HTML is for marking up structure of
> the document (I am ignoring a couple of presentational attributes in HTML,
> but they should be ignored). CSS tells the browser is something is elastic
> or not._

I think everybody here understands that, and the parent was using it as a
shorthand for "the set of technologies commonly used in hypertext documents on
the Web." It is not productive to issue a correction every time you encounter
synecdoche.

------
arocks
> We always have to support HTML5 because so much of our traffic comes from
> email. When we were [serving] a smaller group [of users], we were hoping we
> could duplicate all that mobile web work to make our clients faster in terms
> of code deploys.

This has been my experience as well. When you click on a link in an email, the
LinkedIn site would take you to the login screen. This screen is so heavy that
it takes an inordinate time to even render!

Clearly, they have tried to cramp in too much into their mobile experience.
They should not duplicate the entire functionality but rather simplify it
considering the smaller form factor. Building a much lighter version of their
site would be the right direction for them, rather than building native apps.

~~~
namespace
This approach is the key to get things right on mobile. Because of its roots,
common web development focuses on desktop first and mobile second. This
usually means that we do: `loadContent(); if mobile: loadMobileContent();`.
Instead we should build for mobile first and load desktop content when we
encounter one: `loadContent(); if desktop: loadDesktopContent();`

~~~
iaskwhy
I think a lot of use cases would actually benefit from having a branch
(desktop and mobile) instead of an add-on (mobile and then desktop or vice-
versa) just because the experience is completely different. If we consider
generic websites and blogs, the experience is so similar using responsive
design is the best approach. But if we consider web apps, like those that can
improve the experience using geo data, branching can be a better fit.
Responsive doesn't seem like a silver bullet.

~~~
nissimk
Honestly sometimes when I'm on my phone and I get a linked in email I won't
click the link because the experience is so bad. I'm petty sure it starts with
more than 2 possibly 4 redirects and then it shows you that spinner for a long
time while it loads data. Are the ajax calls returning a lot of days that is
never rendered? Are the ajax calls too slow? Why does it have to redirect so
many times? Maybe if they had a mobile debugger they could figure it out.

An application like linked in should not require a native app. The website
should just work well in a mobile browser.

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

Those are both performance issues...

> _It’s not that HTML5 isn’t ready; it’s that the ecosystem doesn’t support
> it. … There are tools, but they’re at the beginning._

So, he's calling his team incompetent, or better yet HTML5 _isn't_ ready.

Sounds like a whole lot of sour grapes. I'm glad Prasad and team originally
pushed for HTML5, as their transparent push to strategically use HTML5 makes
the ecosystem work harder. However, you're dealing with a walled garden that
has very little incentive to play nice. If the experience is the same in HTML5
as the App Store, then Apple loses. At least in Google's case (with Android
and Chrome) they are incentivized slightly different (by search).

~~~
rimantas

      > If the experience is the same in HTML5 as the App Store,
      > then Apple loses
    

What exactly Apple loses? It was the free app anyway, who cares? I don't get
where this stupid notion of Apple being anti-web comes from. Their goal is to
sell as much devices as possible, and provide the best user experience
possible on them, that's it. They don't firewall your web apps, do they?
Neither "native" devs care about killing the web, but for some reason
uninformed webdevs cannot stand native apps and declare wars, battles and
winning. Why? Makes yourself a favour, learn any of the native SDK just enough
to make a semi-trivial app and you will clearly see what native provides and
what webtech solutions severely lack and will be lacking, because the
technology was not created with apps in mind.

Why it is so important to kill native in favour of web? How about learning
(not really learning, just stopping to ignore) which is best for that and use
accordingly? You need a website? Great, there is your HTML and CSS. You need
performant app? Great, there is your SDK. You want a mix of both? Cool, take a
good close look and choose wisely. Maybe mix of both.

I don't see a call to replace native desktop apps with HTML and JavaScript,
why are people so hell-bent about all or nothing on mobile?

~~~
mbesto
Whoa!

> _Why? Makes yourself a favour, learn any of the native SDK just enough to
> make a semi-trivial app and you will clearly see what native provides and
> what webtech solutions severely lack and will be lacking, because the
> technology was not created with apps in mind._

First off, I ran a iOS native app dev team for 1.5 years and am a huge
proponent of native apps. Attacking me personally is something frowned upon
here.

> _I don't get where this stupid notion of Apple being anti-web comes from._

It's simple. The iPhone experience is only valid when good apps are made.
Imagine you're Lotus123 back in the 90s and Microsoft is trying to compete
with you. Microsoft creates a product that can read/write Lotus123 files, but
has superior functionality. This is the same with HTML/CSS on mobile. It's
called backwards compatibility. It can be the greatest and weakest barrier to
entry for any company in today's technology.

------
sorenbs
Frankly, the linkedin mobile site sucked from a usability perspective. Login
takes forever, and navigation is slow even on top end phones. About time they
decided to do something about it. The most commen use case for me is I get a
mail from linkedin on my phone, click the link. And now it takes more than a
minute before I get to the content, including login, redirect and all. A
mobile app is not going to solve this use case.

------
colemorrison
Was anyone else heavily on the HTML5 crew only to be rudely awakened to all
these inconveniences? It seems like there's a constant, persistent migration
away from HTML5 for mobile style devices...and while every dev group says
something like "performance, debug tools, etc." However, I'd say that the
ultimate reason to do so is because of user behavior - opening up safari
mobile or chrome is not a "pleasant" experience when compared with a native
app.

Is anyone else moving away from html5 to native? What I find odd about this is
Paul Graham's whole "web software" is the future - and yet if "Mobile" future
and mobile users favor "native software" ............. then it seems that
native would be the future.

Of course, one can just say "yes, but native is becoming hybrid with web." And
that's definitely true, but it still makes things very dependent upon the
client and not as "platform agnostic" as a full web movement would be.

~~~
camus
it depends. personnaly , i prefer the mobile websites when available.

------
digitalengineer
"There are a few things that are critically missing. One is tooling support —
having a debugger that actually works, performance tools that tell you where
the memory is running out."

"The second big chunk we are struggling with is operability, runtime
diagnostics information. ...there aren’t as many great tools to support that,
as well."

Could be me but looks like there is an oppertunity for professional HTML5
performance and bug-tracking tools.

~~~
robmcm
The problem is it's dependent on the runtime. A debugging tool for Chrome,
wouldn't necessarily work in Safari or IE.

You need the runtime vendors to provide them. Chrome has been really good at
this, but are there tools for mobile Safari, Android browser, IE10 or mobile
Chrome etc

~~~
desas
You use the chrome developer tools from your desktop browser and hook them up
to your device plugged in via USB. The same goes for mobile safari.

[https://developers.google.com/chrome-developer-
tools/docs/re...](https://developers.google.com/chrome-developer-
tools/docs/remote-debugging)

~~~
robmcm
You can, but what about android browser (pre chrome), or webview instances
inside an application (phonegap), or people using Amazon Silk on a kindle etc
etc

------
davidw
Because they're big, and have the money to sink into something that's still a
bit better at the margin?

~~~
corresation
This is ultimately it. LinkedIn is now a large business, with a very large
technology team. That they can spend the time and effort to optimize each
platform should surprise absolutely no one.

But does it apply to you and me? In most cases, not even remotely.

I was recently involved with a team building a pretty amazing, full-featured
web app (in the investor information space). Out of the pure magic of HTML,
most of the app worked brilliantly not only on the desktop, but on the iPad,
iPhone, Android devices, and so on. There were small edge issues, but overall
it was simply brilliant, and for an investor on the go they could easily get
an up to date snapshot of their portfolio with dynamic graphics, etc. It was a
complete win for the web.

Yet even there a narrative erupted where some people pushed hard for native
apps. That this tiny team of six developers that apparently needed to fracture
to start building iOS, Android, etc, clients. It was utter insanity, and of
course LinkedIn and Facebook both appeared as if they were the benchmarks we
should follow ("See, they abandoned HTML! So should we").

Sure, if you have the resources of LinkedIn and Facebook, feel confident
making those decisions. For the rest of us, HTML5 is pretty fracken amazing.

~~~
akalia
> It was utter insanity, and of course LinkedIn and Facebook both appeared as
> if they were the benchmarks we should follow ("See, they abandoned HTML! So
> should we").

This story amused me to no end. About 18 months ago, I worked on a team that
made the (not unanimous) decision to build a hybrid app, and those who pushed
for that technology pointed to LinkedIn and Facebook as the benchmark we
should follow ("See, they use web code in an app! So should we!")

It's easy to say this with hindsight, but we really should have just picked
the best technology for our team and product, instead of assuming that larger
companies knew something special or magic that we didn't.

~~~
corresation
Indeed, that was an earlier iteration of the internal argument (the appeal to
authority of Facebook and LinkedIn and their well known embracing of HTML).
What you say is absolutely true, and the truth is that these shops are staffed
with often pretty standard technology guys, but because they're big everything
they say and do gets more technically credibility than it perhaps should.
Recall when the startup world was rushing to listen to Digg's profound
statements on databases (most of which we quickly debunked)

------
goyalpulkit
I don't understand the basis behind most of the comments blaming Linkedin for
making a move towards native. I think that development time and code
maintainability are some of the things in favor of HTML5 apps as opposed to
native ones and if even this becomes difficult with HTML5, I don't see any
harm in switching to Native apps given that they will almost always be better
(or at least equal) in terms of performance.

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

Give it back then?

------
theguycalledtom
> We always have to support HTML5 because so much of our traffic comes from
> email

Because LinkedIn are spamming scum.

~~~
goyalpulkit
Their marketing is quite aggressive (I have been receiving "Last month to get
Linkedin Premium for free" weekly for about an year!) but I wouldn't call them
spammers.

~~~
nwh
I've never even set foot on the website, and I get piles of emails from them.
They're even worse than Facebook.

------
datadiver
Too bad, as Linkedin did an amazing job optimizing their HTML5 app. See my
discussion with their project lead on Hackernews:
<https://news.ycombinator.com/item?id=5552634>

There is a ton of tricks LinkedIn employed to optimize their webapp. Check out
their blog for a ton of ideas: <http://engineering.linkedin.com/mobile/> What
I think they failed at, is not releasing their code open source. Then the
community would have helped them find the memory leaks and other edge cases.

So I consider it a call to arms, let's build an amazing mobile web client that
employs all those tricks, things that only big companies like LinkedIn could
afford to make, and better. We could turn this into a distro for
JavaScript/HTML5 apps. I and my friends have started this work. Join us on
github at <http://github.com/urbien/urbini>

------
pmarsh
While HTML might have caused struggles for them with large amounts of users I
wanted to just offer up that we have found it to be quite useful in a
small/medium business for enterprise apps on smaller subsets of devices. So we
do not have to worry about supporting every device and OS flavor under the
sun.

We are a small dev team and being able to use a web stack prevents us from
being spread too thin across too many different technologies.

Is it as "smooth" as native? No, but it gets the information and
functionality, the most important parts, to the people who need it and allows
us to quickly turn around projects.

And not being native allows us to customize UI to fit each group's particular
needs more easily. At least it seems that way.

------
jordn
Are HTML5 web apps still viewed as wise first move into mobile app
development?

We're seeing companies consistently move from web to native... but generally
only after hitting some performance barrier. Switching to native then seems to
be like any other optimisation. So even if the web performance barely
improves, does developing for web first still make sense (platform
independence, rapid iterations etc) or should we be thinking native first?

I'd be interested in hearing whether LinkedIn and co regret going HTML5 in the
first place.

~~~
camus
if one builds an "app" , since it uses a "webview" inside a native application
, it is always "native" ( except for firefox and likes os where the browser is
the "os" ). Phonegap and likes use native code so one can bundle html+js into
a native app.

I tell my clients , instead of using a wrapper , to build a webapp directly.
most of the LOB-apps require an internet connection anyway , and things like
camera can be accessed from the browser now , on most mobile os. And it is
easy to explain clients how to bookmark a webapp to the home screen.

packaged webapps are overrated imho , in most cases a webapp makes more sense.

~~~
jordn
No need for the patronising scare quotes.

I'm talking about whether to base your app on web technologies like HTML5 and
js (regardless of delivery method - web/native webview wrapper), or to use
native UI elements/memory management etc of the OS.

~~~
pspeter3
I don't think he is trying to be condescending. He has a point that the lack
of Nitro or V8 in a webview means you'll have a performance hit when you do a
wrapper. HTML5 provides most of the APIs you need anyway, especially if you
are on firefox OS

------
Zigurd
The rise of mobile platforms that have highly capable native runtime
environments is going to call into question whether a cross-platform
implementation strategy will really be viable for high-value apps.

Web apps are optimal when you need to access them from multiple OSs and
develop them only once. That last part "develop them only once" is important.
If you want to go beyond what a Web app can do, you have now made your Web app
users second class citizens. And, if you avoid implementing platform-specific
features or overall architectures, you make your app a second class citizen
among apps on the native platform.

In other words, for anything that more than filling out forms and looking at
data, it's worth doing the best job on every platform with a significant
number of users, and that means platform-specific implementations.

Or look at it this way: What if LinkedIn morphed into a kind of "people
dashboard" for enterprise users, with an architecture inspired by Facebook
Home, but for CRM, not for your Farmville buddies. Could that even be
contemplated in a cross-platform HTML5 implementation?

Tl;dr: Operating systems still matter because they look, work, and interact
differently, and they impart their advantages and restrictions to apps.

------
programminggeek
HTML5 is not going to replace native for things over time simply because it's
not the default way to do things on mobile platforms. The best chance of
HTML/JS everywhere was webOS, now FirefoxOS. Everything else thus far has been
a hack, even if a very pragmatic one.

HTML5 for iOS/Android is like Flash or Java applets are/were for the web.

I'm not sure why web geeks hate Flash or Java applets so much and are trying
to do the same thing for mobile apps.

~~~
NinjaWarrior
And the web highly relies on the native ecosystem. Since we have freedom of
the native development on PCs, a number of browsers have been created and
improving. However in mobile devices, that ecosystem is totally broken. When
you have trouble with browsers on restricted OSs (such as iOS and Firefox OS),
you can't do anything! I feel something like free riding is happening. This is
far from "open" movement.

The web platform can't exist without native platforms after all, since
browsers are native applications.

------
billions
Just as users will try a web-app before investing in downloading the native
app, companies will develop web apps before investing in native apps. Once a
company has the resources to go fully native, in exchange for 5-10% more user
engagement it makes sense.

------
dirkdk
interesting, it is not so much speed as lack of debuggers and diagnostic tools
that lead them to abandon HTML. I guess that in the end supporting two mature
platforms (iOS and Android) cost them less time than one not-so-mature
platform (mobile web)

------
mddw
I would be really curious to know the app vs website usage stats of LinkedIn.

------
monsterix
Honestly, it is kind of sad, rather disastrous, that a leading site such as
Linkedin is unable to stir things up a bit and come out with the exact truth.

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.

Mark his words, 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. 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 or enough support for web standards on their
stack.

We're actually back into 1995, I think, with every other for-profit firm
talking about its own "experience" and "standards" these days.

Edit: This discussion is meant specifically for browsers supplied on
iPad/Android tablets. Not the desktop browsers which are not only good but
also in an extremely competitive space (Thanks to Firefox!).

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

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

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

~~~
oftenwrong
FWIW, the mobile web version of Gmail works well.

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

------
radiusq
>The second reason we’ve gone native is trying to get some of the animations —
the spinners and the way they work

Why in the world does an app like linkedin's need animations that are
apparently too intensive for a browser? And they couldn't get a spinner to
spin smoothly?

------
Koder2013
You still need to infuse some idiomatic elements of the platform to give it a
coherent look and feel. So why not write some native apps? You can always just
use Mono for most of the non-view code.

------
Koder2013
I smell the uncomfortable truth.

