But this is the exact "myth" you claimed to "debunk". This is why people claim WebViews suck.

If you want to trade user experience away to reduce development work, that's fine. Lots of people make that compromise. But your claiming this is a "myth", and then admitting it's true.

Users may not always articulate this fully, but users do notice when apps are "janky" -- when animations aren't fluid, or when UI doesn't accurately respond directly to their input, or when screens "flash funny" because your switching between native activities and webviews.

You may not care about the experience that has been lost. And perhaps your particular customers don't mind that loss of care for the details. That's not inherently bad in any way. But it's not a "myth" either, you have lost a part of the experience you could have offered.

> Webviews give us the flexibility and freedom to choose what screens to level up as native views, instead of being forced to make everything native.

For the umpteenth time, the Basecamp team has leveraged their resources and skills to ship an entire product at a remarkable pace. Had they embraced the myth that "WebViews suck" and anything but native is acceptable, they would have taken twice the time to ship.

Those were problems in 2013 and 2014. It's not the current state of things. Our users can't tell the difference from Native apps and we have conducted quite a bit of research... Nowadays those problems simply signal that "you're a mediocre dev" (probably in all platforms).

> If you want to trade user experience away to reduce development work, that's fine.

This is the reason why some people help to perpetuate "the myth". UX, if you know how to build an app properly, is not affected anymore. Don't believe it? Check apps like this one...

https://www.youtube.com/watch?v=hlykw4Z73sA

https://play.google.com/store/apps/details?id=com.bitpay.che...

Arguably the best UX for bitcoin payments. Not a single complain about flashiness, clunkiness, etc... And the impact in the battery is orders of magnitude smaller than native apps like facebook. It uses cordova like many great bitcoin apps...

PS: I'm not affiliated with Bitpay in any way, just very thankful and impressed with their cordova projects.

Also that Bitcoin app is a bad example because it's a very simple app.

To be clear, I have programmed in both native ios, ionic and native android. I'm primarily a iOS developer so had no idea how Android worked when I first tried building an android app, so when I first tried my "cross platform" app on an android phone I was shocked to find out there are so many details that make it feel NOT native. iOS and Android have very different UI and you need to build for those experiences if you want to really optimize for user experience. It's not just a matter of performance. That's why I learned java to build natively.

Lastly, in this and age, why not just learn react native instead of boasting about how still using web browser is good enough? You really have no excuse here if your reasoning is that you want to use web technology to build native apps.

Because for instance I can use native HTML APIs like WebRTC without 3rd party libraries and I can reuse many great JS libs, which I'm familiar with.

> Also that Bitcoin app is a bad example because it's a very simple app.

It's the perfect example because it reflects that it all depends on the use case, and that are use cases that will better fit your company stack. In bitpay's case, they're heavily invested in JS/Node. So it just makes sense (like in many other cases/companies).

A good lead (tech, manager, etc) will always pick the proper tool for the task, taking into account many aspects of the project: business decisions, UX, costs, current work force, current stack, available libs, etc...

What I'm trying to say is that Hybrid has it's place. It's not all hybrid or all native. It depends.

It's a fine app if you don't care deeply about UX, but certainly not indistinguishable.

Not going to discuss why picking a random app from a listing doesn't make all the apps built with a similar technology equally bad.

Next time, before shouting "nonsense" try something built with Angular2/Ionic2.

http://ionicframework.com/docs/v2/components/

I did the same thing with Ionic; the top app on their showcase page is ChefSteps. It's definitely better, but sorry, not indistinguishable. Not even close.

I stand by my claim that saying that "2016 hybrid" apps look and feel 100% native is nonsense. It's fine to use those technologies, but be honest about your reasons.

That's not a good way to sell a platform if you have to be a really good developer to use it.

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.

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.

The title of this post is a lie. What the OP is saying is "It sucks but what are we gonna do? Hire more native developers for all platforms?". I don't know how that's a "myth debunking" for "webviews suck".

This makes it sound like smoothly animating a few rectangles is hard. The only reason it is true is because the web stack is, for lack of a better word, complete crap. It was fine for rendering static text and a couple images with no graphics acceleration, I guess.

Today, AAA games can redraw complete frames of 3D worlds inside of 16.66ms (along with processing physics / gameplay / networking / input) and I'm supposed to accept slow and janky GUIs on my desktop?

I just can't. I tried Atom, and even though it's usable, it's not exactly snappy. The complete waste of my hardware's resources makes me too sad to enjoy any good feature it might have. The web is stuck with this, that's "fine" but could we keep the desktop out of it?

And even then, HTML+JS apps often cannot do that without lag. Not saying that native apps are necessarily better (especially on Android), I die a little inside each time I unlock my phone and the unlock screen fails to keep up with my finger.

We had smooth scrolling in the late eighties on the Amiga 2000 (7 Mhz and 1MB of RAM) with CygnusEd: https://www.youtube.com/watch?v=L41oIvre9K0

The fact that we barely manage to do that with HTML+JS on what amounts to supercomputers (relative to the time) should not make anyone proud.

I don't think there was ever a myth that needed to be debunked that everything should be native, both approaches have their pros and cons. All that really matters is how aware you are of what those pros and cons are, and how you weight the ones that you are aware of given your context. Collectively that determines if you need a native app or not. Most likely neither approach will be ideal (i.e., pros == 1.0 and cons == 0.0), so the real question is what heuristics do you use when choosing your poison for your project and for your team.

Towards the end it seems like that's the point that was being made (i.e., "nothing's perfect but here's why this was the best approach for us in this particular case"). That's the opposite of what was promised up front though.

I'd say 2015 represented the turning point and from now it will only get better with things like web workers (UI decoupling), WASM, and upcoming HTML5 APIs.

It's really a huge loss for the JVM that it couldn't do what browsers did. I guess the server-money kept rolling in and they local-optimized themselves themselves into bad security (for running untrusted code) and a hopeless end user experience. It really shows the strength of open standards with competing implementations.

But I would disagree with using it as the main building block for an app. There are many gray area I'm not sure if WebView can handle well enough, e.g. offline mode, screen orientation change/state restoration, first time rendering without delay etc.

On the desktop, I use both Slack and Atom on the regular and haven't had any issues. (Or at least, not since since they did some optimization of Atom.)

I'm curious how React Native's "learn once, write twice" philosophy will play out in this ongoing native vs webview argument.

But if you app has a less challenging kind of content to present, use a native app. If you don't, you are not being very nice to your user. In addition to not presenting the nicest UI, you're using up the user's battery and crowding other apps out of memory.

This is exactly the issue, isn't it? People weren't told to hate webviews, but conditioned. They've been conditioned by years of experience with webviews and webview-based apps being vaguely shitty. They might not even be able to tell you precisely why. It can manifest as a vague sense that something's not quite right, like working in an office with crappy lighting or the first hints of unexpected fatigue as an infection works its way into your system. You can't debunk that kind of association; you have to create new experiences and new conditioning.

Acknowledge the WebView versions as a beta, because that's what it is; a less than optimal experience for the users.

Treat WebViews as a prototyping tool and please don't sugarcoat it as "indistinguishable" from native apps because they aren't.

I have struggled just to turn off the sound generated by an HTML5 game being displayed through a WebView. The sound would simply not stop on certain device/SDK combinations.

Of course, you can load a blank url into the WebView. But that's a big hammer. And you lose game state.

The twitter and facebook webviews to open links are just plain evil.

Same reason I use firefox on android over chrome.