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).
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.
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...
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.
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.
> 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 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.
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();`
> 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?
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.
"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
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 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.
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.
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.
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)
[+] [-] marknutter|13 years ago|reply
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).
[+] [-] kalms|13 years ago|reply
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.
[+] [-] litek|13 years ago|reply
[+] [-] DenisM|13 years ago|reply
[+] [-] robocat|13 years ago|reply
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|13 years ago|reply
Html is elastic by nature, and html 5 will win over native apps because it is elastic.
[+] [-] kalleboo|13 years ago|reply
[+] [-] NewAccnt|13 years ago|reply
[deleted]
[+] [-] arocks|13 years ago|reply
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.
[+] [-] kyllo|13 years ago|reply
They need to do something to fix this experience, which is quite broken.
[+] [-] namespace|13 years ago|reply
[+] [-] mbesto|13 years ago|reply
> 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|13 years ago|reply
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?
[+] [-] sorenbs|13 years ago|reply
[+] [-] colemorrison|13 years ago|reply
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|13 years ago|reply
[+] [-] digitalengineer|13 years ago|reply
"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|13 years ago|reply
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
[+] [-] davidw|13 years ago|reply
[+] [-] corresation|13 years ago|reply
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.
[+] [-] goyalpulkit|13 years ago|reply
[+] [-] Sarkie|13 years ago|reply
Give it back then?
[+] [-] theguycalledtom|13 years ago|reply
Because LinkedIn are spamming scum.
[+] [-] dawson|13 years ago|reply
[+] [-] jrabone|13 years ago|reply
[+] [-] goyalpulkit|13 years ago|reply
[+] [-] mh-|13 years ago|reply
I assume you mean they're emailing you things, and you have an account there.
[+] [-] hkarthik|13 years ago|reply
[+] [-] datadiver|13 years ago|reply
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|13 years ago|reply
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|13 years ago|reply
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|13 years ago|reply
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.
[+] [-] Zigurd|13 years ago|reply
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|13 years ago|reply
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|13 years ago|reply
The web platform can't exist without native platforms after all, since browsers are native applications.
[+] [-] billions|13 years ago|reply
[+] [-] dirkdk|13 years ago|reply
[+] [-] mddw|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] leoedin|13 years ago|reply