Developers need to treat mobile computing more like 1980/90s micro computing.
You have limited resources with numerous environmental factors that need to be accounted for and respected (ex: bandwidth, latency, CPU, GPU, memory, UI/UX, async task handling, and most importantly BATTERY LIFE).
It is a different mindset when developing for mobile that needs to account for finite resources. If you're greedy, careless, or just don't really think through and test your app appropriately it makes for a horrible user experience.
Regarding the HTML5 vs. Native Apps:
HTML5/CSS/JS and frameworks that allow you to write once and convert to native apps (ex: Phone Gap) have their place. The core take away is that without developing native apps directly you’ll never get to maximize the phone’s hardware and performance will suffer. UIs will be sluggish and network IO suffers from high latency (wrappers).
HTML5/CSS/Javascript frameworks like Phone Gap cannot take full advantage of the hardware and SDK features like alarms, custom hardware access/config/acceleration, background services, and (taking advantage of) the standard UI controls (transitions, buttons, look ‘n feel).
If you’re focusing on content display/information consumption and your app doesn’t need to rely on high performance from hardware and the UI then HTML5 is most likely a good fit. If performance, high availability/background service, native look and feel and the such is critical to an app then native is a better route.
Very well said, in my experiences with building mobile apps that HAD to perform at close to native speeds with HTML/CSS/JS and Nitro/PhoneGap this is exactly how you need to treat the mobile web if you want things to perform.
You really cant blindly rely on any 3rd party code, or take first party code as a given without means testing it, you need to be able to build functionality from the ground up ensuring that performance is the number one priority, or extensively test and research each library before introducing it into your codebase to make sure it doesn't have any future gotcha's with performance - and more often then not, you will find multiple gotchas, till they start adding up and you end up with something like the old Facebook App.
There is no sandboxing in JavaScript, so one mistake can mean the difference between an app that performs and an app that lags, and hundreds of mistakes accumulating with no quality control at all, as seen in the old FB app, is just completely unacceptable.
I really can't understand why this is so difficult for Facebook to comprehend, did they not have any JavaScript specific developers assigned to the project? Did they assign a bunch of php developers to do this? What really caused this failure?
The fact they are using the technology as a scapegoat for their own incompetence is a pretty dishonest way of going about shifting the blame for their failures away from themselves, but I'm not one to believe in company wide conspiracies.
I think it is more likely that this whole thing probably got escalated by a bunch of "web" developers who were in over their head and decided to blame the technology stack and escalate that message to management, instead of the truth, which is that they messed up really really bad!
Don't blame the technology, blame the implementation!
edit: some minor edits to the phrasing of a few sentences.
Zuckerberg recently admitted on AllThingsD they burnt 2 years going done this path. That's not just a bunch of web developers, that's a clueless head of the mobile division.
2 years for that? Thats embarrassing as hell, I can see why he is lying through his teeth and deferring the blame.
It seems that every time Zuckerberg talks, he's just more and more full of shit, can't say thats surprising though! Its a trend that has been around since before FB was even in existence.
You have limited resources with numerous environmental factors that need to be accounted for and respected (ex: bandwidth, latency, CPU, GPU, memory, UI/UX, async task handling, and most importantly BATTERY LIFE).
It is a different mindset when developing for mobile that needs to account for finite resources. If you're greedy, careless, or just don't really think through and test your app appropriately it makes for a horrible user experience.
Regarding the HTML5 vs. Native Apps:
HTML5/CSS/JS and frameworks that allow you to write once and convert to native apps (ex: Phone Gap) have their place. The core take away is that without developing native apps directly you’ll never get to maximize the phone’s hardware and performance will suffer. UIs will be sluggish and network IO suffers from high latency (wrappers).
HTML5/CSS/Javascript frameworks like Phone Gap cannot take full advantage of the hardware and SDK features like alarms, custom hardware access/config/acceleration, background services, and (taking advantage of) the standard UI controls (transitions, buttons, look ‘n feel).
If you’re focusing on content display/information consumption and your app doesn’t need to rely on high performance from hardware and the UI then HTML5 is most likely a good fit. If performance, high availability/background service, native look and feel and the such is critical to an app then native is a better route.
My 2 cents.