Live data from Hacker News

Why LinkedIn dumped HTML5 and went native for its mobile apps

venturebeat.com

91–100 of 105 posts

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#91

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 t…

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.

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#92
post #48

"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 perfor…

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

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#93
post #38

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

> 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 th…

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.

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#94
post #78

Earlier quoted context omitted.

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

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

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#95
post #43
post #22

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 si…

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.

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.

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#96
post #44

Earlier quoted context omitted.

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.

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

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#97
post #43

Earlier quoted context omitted.

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.

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

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?

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#98
post #94

Earlier quoted context omitted.

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

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

my pleasure!

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#99
post #47

Earlier quoted context omitted.

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.

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.

Re: Why LinkedIn dumped HTML5 and went native for its mobile apps

#100
post #92
post #48

Earlier quoted context omitted.

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
Post reply on HN