Why LinkedIn dumped HTML5 and went native for its mobile apps | Hacker News Reader

Why LinkedIn dumped HTML5 and went native for its mobile apps

venturebeat.com

121 pointsiand100 comments

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

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

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

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

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.

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

my pleasure!

Do you have an idea for why both Facebook and Linked in, the two poster children of HTML5 apps, moved away from them? It can't be that they have a grudge against HTML or something...

Yes, actually, I know exactly why Facebook's moved away from it: the beginnings of their HTML5 mobile strategy actually pre-dated the original iPhone, and as such they were using a strategy that didn't really make sense in the post iPhone world. Namely, the app was pulling down the mobile version of their website from the server on every request, which as you might imagine meant things were generally pretty sluggish. So it was really no different than just hitting the mobile version of Facebook with mobile Safari. Contrast this to using a javascript app that runs off the phone's file system and just makes requests to the server for JSON data, caching that data in localStorage along the way (which is what we do). That strategy is really no different than what fully-native apps do except that you're presenting and managing the data in a webView rather than a UITableView. It's much more performant with the benefit of using HTML/CSS for (cross-platform) layouts.

LinkedIn's move away from HTML5 I can't explain as well, although they do mention issues with memory management and a lack of good development tools out there. We haven't run into any issues like that but every use case is different. I do know that LinkedIn, instead of using Phonegap, wrote their own native bridge using websockets and a mini web server that would run natively that they themselves admitted wasn't the best approach. I think there's a lot of pressure, especially in large companies, to move to fully native apps these days because of all the negative press about HTML5, so instead of doubling down engineering efforts to solve problems that arise teams are much more likely to take the nuclear option and just rewrite everything in native code (twice!).

So no, it's not that they have a "grudge against HTML or something", it's that they ran into limitations due to specific circumstances unique to their products and strategies and took the safe path of going fully native to guarantee optimal performance at the cost of productivity (IMHO). If there was no native app option, they would figure out clever solutions to their problems from which the entire web community would benefit.

Thanks. How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness.

My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either. Native is more predictable. Your experience is valuable in that it proves the existence of a solution. Would you say your team is extraordinary in its capacity to wrangle with HTML, or is something like this available to your average YC startup, or to most startups out there?

> How is local storage in your experience? Last I talked to people about this, everyone was cursing it for lack of capacity and general quirkiness.

We've had no issues with it so far and I heard the same criticisms you did. If you make sure not to store too much stuff in localStorage (there is a limit for UIWebViews) you should be fine.

> My concern with HTML is that if FB and LinkedIn were unable to muster the required resources to overcome the engineering challenges of HTML, chances are I won't have those resources either

I get that, but it does overestimate the capabilities and resources of FB and LinkedIn. In the end, they are just developers like any other developers solving the same problems everyone else is, and simply throwing more money at the problem doesn't usually fix things. Keep in mind that there's a lot more pressure on FB and LinkedIn to deliver perfection so they are going to be less likely to "stick it out".

> Native is more predictable.

I agree, and there are lots of other benefits to native as well. They must be weighed against the detriments: having to write the same app multiple times for multiple platforms, having to play by Apple's rules, not being able to update apps for customers immediately (that's a huge problem IMO), working with painful layout tools, etc. As always, it's important to weight the pros and cons before choosing a strategy.

> Would you say your team is extraordinary in its capacity to wrangle with HTML, or is something like this available to your average YC startup, or to most startups out there?

I assure you we are not extraordinary. Anybody with a very basic level of native programming experience and who is competent with HTML5/CSS3 and the latest javascript frameworks (backbone, ember, angular, knockout, etc) can replicate what we did. I think the reason it seems extraordinary is because you only ever see articles about big, trendy companies ditching HTML5. "Small unknown team builds great HTML5 mobile app" just doesn't have the same punch. I also believe there is a bit of religious war going on between web developers and native developers so there's always a frenzy whenever there's a drop or two of blood in the water. Ignore all that crap and just choose the solution that suits both your app's requirements and your skills best.

> using websockets and a mini web server

Whoa! That sounds super convoluted.

Yeah, I'm reading it as: "We were too lazy to help develop the tools we were missing." - The community overall could have benefited from it.

There's nothing wrong with that, of course. I love native app development. I'm just sad to see stout believers in a great technology suddenly roll over and play dead.

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.

I'd like to know why this comment was downvoted, as I've had similar experiences.

> I'd like to know why this comment was downvoted, as I've had similar experiences.

Because claiming that it stinks on Android, while true, might be interpreted as a passive-aggressive way of implying that it does not stink on iOS, which would be far from the truth. iOS's browser is archaic compared to recent and not-so-recent Android browsers.

Current and third-party browsers are good, but 40% of users are on 2.3 or older, where the stock browser (which, let's face it, 99% of users are) really is sub-par.

"iOS's browser is archaic compared to recent and not-so-recent Android browsers" - is untrue in my opinion and irrelevant.

Disclaimer: I love Chrome on Android, and have multiple Nexus devices. Our service (for businesses) has 10 times as many users on iOS devices than on Android devices, and our customers ask about iPad support not Android tablet support.

1. Yes Safari on iOS has its problems.

2. Android stinks because of fragmentation (especially on phones). The majority of users are not using Mobile Chrome. Some Android users are using Firefox Fennec and Mobile Opera (major browser differences from WebKit).

3. Mobile Chrome is approximately equivalent to Mobile Safari in my experience. Both browsers have significant bugs. However I do spend 10x more effort on iOS than Android because we have 10x the users. Currently we have about 40x more iOS users than Mobile Chrome users.

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.

Pinch to zoom isn't that applicable on mobile-optimised webapps. If you have a fixed header on the top of the page what would pinch to zoom do? Make the header bigger? Or would it ignore the header and just zoom in on the body content?

This is tangential to the pinch-to-zoom discussion, but I'd say if you have a fixed element anywhere, you don't have a mobile-optmised webapp. There are plenty of Android devices with 640x480 or 320x240 out there; a fixed header in one of them looks like a big waste of screen space.

Huh? Do you regard the title bar at the top of native Android apps to also be wasted space?

I think he point is that the title shouldn't be fixed but dynamic to the device.

Ah, well, I meant fixed in the CSS sense rather than the "exact size" sense.

Depending on the application and the space available, yes. That's why some aren't fixed, and some are hidden once you scroll after a certain point.

You are not too far from carving your header in a JPEG file there. Some may remember good ol' times when most web sites did so. It was the same reason: someone decided the size must be fixed for the header to be following a fixed grid or corporate design paper, or something the like.

You couldn't select the text, it was heavy, ugly, hackish, crawling against the grain of HTML, which is elastic. Now we know better, and let content flow, adjust itself, at the will of the users (on the desktop).

This was the Dark Ages of the Web, why do we need to go through the same lows on mobile?

In some browsers, removing the ability to zoom removes the 300ms delay that the click event has before it fires.

You can use 'touchend,' but in certain cases this causes another set of bugs because the click event follows anyway.

To fix this in a cross-browser way, you need to write some extra logic. There are several implementations floating around of various quality.

Thank you! The worst is when pinch-to-zoom is disabled on an image viewing/sharing page. I believe Twitter is guilty of this. It's idiotic.

I've also heard many arguments that responsive design makes pinch-to-zoom unnecessary. A page should automagically adjust so that it's optimal for a 27" monitor, a 2" mobile display, or anything in between. It's a great idea in theory, but I've yet to see it executed well in practice. I guess it's exceedingly difficult to design an effective UI that can automatically and seamlessly scale between a large-format screen and a small-format screen.

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

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

Actually, users don't give a shit either at how it looks or even if it works smoothly. They just care positively about content and entertainment, look at Wikipedia, Minecraft, early Google.

But they also care negatively if something is getting in their way. That's why headers carved into gif images and flash for text and any other mean to force text size upon user are less and less used on the desktop.

So why should it be current on my phone?

"HTML is for marking up structure of the document" - exactly. The trouble starts when you start trying to use it for app's GUI.

I too hate the disabling of pinch-to-zoom on websites. Chrome on my Android phone has the wonderful feature (in accessibility settings) that allows you to always pinch-to-zoom (overriding the sites viewport declaration).

Until recently I too disabled pinch-to-zoom because it introduces so many bugs on every mobile browser I have tried - see my comments here: http://stackoverflow.com/a/10747648/436776

And on an iPhone or Android app, you can't pinch-to-zoom.

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

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();`

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.

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.

This is my pet peeve lately. I get e-mails from LinkedIn about my friend's new job or an article someone posted in a discussion group that looks interesting. I click the link in my Mail app, and it switches over to my browser, which takes me to a 20-second splash page, which then prompts me to type my e-mail address and password to log in, and then I'm asked if I want to "get the app," which I already have. Since the web app is terrible, I close my browser and then go open the native app and try to find the thing I clicked on in my e-mail, if I still care enough at that point.

They need to do something to fix this experience, which is quite broken.

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

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

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.

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.

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.

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

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

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

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

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

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

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.

I typed in my comment pretty quickly, and thus ignored the point you make, but I concur with it completely. It's all about tradeoffs, and for a small team/startup, you're going to have to look at them more carefully than a big company that can just throw money at things.

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

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)

That they can spend the time and effort to optimize each platform should surprise absolutely no one.

The first point is that you're doing this anyway with an app that has any complexity. Each mobile browser and device has its own quirks. If you're going to spend optimization time for each device you might as well go native and make the most of that time.

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

Our first mobile app was native iOS and built by 3 of us in about 8 weeks. One of the team had some iOS experience at the time. I prototyped the Android version in a weekend and we had a releasable version ~6 weeks later with 2 of us working on it. Neither of us had any prior Android experience and that other guy had never done Java.

My point is that iOS/Android apps are not hard to build natively. That time spent means you can get the best the device can offer. Of course if you're only showing a simple web page opposed to an app then html5 may make more sense, but the discussion here is about apps.

The first point is that you're doing this anyway with an app that has any complexity.

Enormously complex application with widgets, dynamic graphs, etc. Close to nothing had to be customized for those targets because it used standardization and shims where possible, and already was built to work across the major desktop platforms. I read this "you'll have to dramatically rewrite anyways" claim a lot and it simply doesn't ring true.

My point is that iOS/Android apps are not hard to build natively. That time spent means you can get the best the device can offer.

Is it possible for you to point to the app? I've done a significant amount of Android development (no iOS dev to this point) and my natural assumption is that a short effort app by people new to the platform would generally be terrible (which is sadly the case for most apps on the platform).

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.

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

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

Because LinkedIn are spamming scum.

that's quite an accusation.

I assume you mean they're emailing you things, and you have an account there.

They seem to continuously invent new things to mail you about, as often as possible, which you then continuously have to uncheck on the site.

We can argue about definitions but in my mind LinkedIn are definitely spammers, that are now only tolerated because the site is too popular for jobs (especially if you're a contractor).

They didn't use to be like this, but they now have the questionable distinction of being the nr.1. deliverer of junk in my mailbox.

We may also send you messages with promotional information directly or on behalf of our partners, unless you have opted out of receiving promotional information.

You can change your e-mail and contact preferences at any time by logging into your account and changing your settings related to your email notification choices. If you wish, you can also opt-out of receiving promotional emails by sending a request to LinkedIn customer service through our customer service site.

http://www.linkedin.com/legal/privacy-policy

I'm rabidly anti-spam, to the extent of hosting and running my own mail server just so I have more control over my MX, and even I don't think that!

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.

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

What you describe I would describe as spam. Obviously there are wildly different informal definitions of "spam" in use. By my definition, Linkedin is definitely a spammer; I get frequent email from them and I don't have, and plan to never, get an account.

Settings > Email Preferences > 1) Select the types of messages you're willing to receive 2) Set the frequency of emails

One man's spam is another man's industry-standard email marketing.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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)

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

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

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.

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

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

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

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.

I smell the uncomfortable truth.

Reply on news.ycombinator.com