Myth debunking: WebViews suck, everything should be native

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.

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.

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?

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.

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.