I know this is the future, but with my job in which I do a lot of embedded software and mobile software next to web stuff, the web stuff really seems to be the cpu and memory killer which in turn drain the battery very fast.
Not sure if there is a solution if the biggest companies in the world cannot prevent their applications from doing that though.
[1]: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
Now, if such engineer faces a game or a camera/gps intensive app, she would probably choose native.
In any case, the good engineer never generalizes the solutions. Context is crucial.
"Why is my phone running so hot and always in need of charging halfway through the day?" Well, 5% CPU here, a battery-draining busy loop there... But the solutions solved the minimal target; so suck it up, end-user.
If those were the limits of the requirements, then yes. Your job is to fill the requirements while minimizing dev costs. Sometimes that means some compromises in latency, or other aspects of UI polish.
As a dev, that's understandable. As a user, it's annoying, and I'm going to look for any option that lets me do the same thing while avoiding the annoyance. The software has to provide an overwhelming benefit to make it worth my while (e.g. my laggy banking app that lets me remotely deposit a check).
Honestly, I don't know much about UX and customer engagement or how much it hurts a company if a customer waits to get to their PC to use a service, but it seems like a concern that's often downplayed when the requirements list is being written.
Before you go off on "lock in", note that native apps have a distinct advantage over any web app using javascript. I hate having 20% cpu use for a stupid chat app on a modern i7 system. Most of that "app" is spinning around chasing its own tail making the cpu fetch memory incessantly and blow through cpu cache/tlb. I don't see that happening with native apps nearly as bad.
Furthermore, you're still running the code on the Javascript VM/interpreter, so it's unlikely to give much of a speed boost. The motivation behind WASM and ASM.js both is to cross-compile code from other non-JS languages (generally, C/C++) into code usable from JS.
Just throwing out a technology doesn't invalidate my point that javascript likely has a lower bound on energy and cpu/cache impact.
Until WebViews or web apps can offer the same buttery smooth scrolling and responsiveness as native apps, until they don't immediately look and feel out of place from the rest of my environment, until they not drain my CPU and battery, until they can offer standard menus and seamlessly interface with all the features of my operating system, like notifications, a unique icon in the Dock/Taskbar/app switcher, and OS X services and the like, native is the way to go.
Most of the purported advantages of web views in these arguments read like the excuses of lazy developers (or small teams with limited time), unwilling to acquire expertise in each of the major OS platforms and [re]learn all their APIs and GUIs and their quirks. It's understandable, but it definitely results in a diluted experience for the user.