9 ms·
Why LinkedIn dumped HTML5 and went native for its mobile apps
- arocks 14y ago> 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 14y agoThis 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 14y agoI 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 14y agoHonestly 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.
- kyllo 14y agoThis 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.
- deleted 14y ago[deleted]
- Sarkie 14y ago"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?
- colemorrison 14y agoWas 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 14y agoit depends. personnaly , i prefer the mobile websites when available.
- theguycalledtom 14y ago> We always have to support HTML5 because so much of our traffic comes from email Because LinkedIn are spamming scum.
- mh- 14y agothat's quite an accusation. I assume you mean they're emailing you things, and you have an account there.
- gcp 14y agoThey 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.
- mh- 14y agoWe 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 http://www.linkedin.com/legal/privacy-policy
- jrabone 14y agoI'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!
- goyalpulkit 14y agoTheir 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.
- sorenbs 14y agoFrankly, 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.
- monsterix 14y agoHonestly, 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!).
- nashequilibrium 14y agoIt 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!
- namespace 14y agoWith Firefox and Tizen OS the dream of web first should move closer to reality. Count on Mozilla to move the web forward!
- threeseed 14y agoReally Apple hasn't given enough support for web standards ? Because I wonder where the world would be today without WebKit.
- jordn 14y agoAre 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 14y agoif 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 14y agoNo 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 14y agoI 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
- digitalengineer 14y ago"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 14y agoThe 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 14y agoYou 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/remote-debugging https://developers.google.com/chrome-developer-tools/docs/re...
- robmcm 14y agoYou 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 14y agoBecause they're big, and have the money to sink into something that's still a bit better at the margin?
- corresation 14y agoThis 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.
- davidw 14y agoI 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.
- akalia 14y ago> 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.
- deleted 14y ago[deleted]
- leoedin 14y agoA touch of hyperbole perhaps? Losing control of your online identity is bad, but it's not HIV bad.
- pointyhatuk 14y agoIt depends. Look at DongleGate...
- dirkdk 14y agointeresting, 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)
- robocat 14y agoHTML5 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.
- kalleboo 14y agoI'd like to know why this comment was downvoted, as I've had similar experiences.
- _pmf_ 14y ago> 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.
- mbesto 14y ago> 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 14y ago> 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 14y agoWhoa! > 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.
- goyalpulkit 14y agoI 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.
- marknutter 14y agoAnother 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 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 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 14y agoDo you use phonegap for the mobile versions, or something custom with a webview?
- marknutter 14y agoPhonegap, but we do a lot of custom native stuff beyond that.
- mddw 14y agoI would be really curious to know the app vs website usage stats of LinkedIn.
- radiusq 14y ago>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?
- pmarsh 14y agoWhile 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.
- programminggeek 14y agoHTML5 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 14y agoAnd 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 14y agoJust 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.
- datadiver 14y agoToo 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 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/ 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 http://github.com/urbien/urbini
- Zigurd 14y agoThe 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.
- Koder2013 13y agoI smell the uncomfortable truth.
- Koder2013 13y agoYou 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.