
Myth debunking: WebViews suck, everything should be native - gvb
https://m.signalvnoise.com/debunking-android-myths-webviews-suck-so-make-everything-native-cea5f8a8db87?source=latest
======
maxsilver
> Does every single screen need to have 60 fps animations, with activities
> that launch from where my finger touches the screen? Does fidelity matter on
> an admin screen?

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.

~~~
joeyspn
_> janky, animations aren't fluid, UI doesn't accurately respond directly to
their input, screens "flash funny"..._

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://www.youtube.com/watch?v=hlykw4Z73sA)

[https://play.google.com/store/apps/details?id=com.bitpay.che...](https://play.google.com/store/apps/details?id=com.bitpay.checkout&hl=en)

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.

~~~
galistoca
Using "WebView" doesn't just mean performance issues. It's a matter of
choosing the very stack itself. You're starting out with browser as your base.
There are many things that come with that decision.

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.

~~~
joeyspn
_> You're starting out with browser as your base. There are many things that
come with that decision. [...] why not just learn react native instead of
boasting about how still using web browser is good enough? _

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.

------
Razengan
_Speaking as a desktop user,_ I despise webview apps.

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.

~~~
gaius
The battery thing is huge. I'm not a professional GUI developer but I've done
quite a bit of GUI work as part of my real job, Motif, Tcl/Tk, PowerPlant,
MFC, a range of different technologies over the years. Something that wouldn't
have even moved the load average needle on a SPARC 20, 20 years ago, shouldn't
be pegging a cpu core on a modern machine and making the fan spin like an
aircraft taking off.

~~~
tluyben2
This cannot be said enough. I do not like talking about the past a lot as that
is useless but yes: I did make a lot of complex apps natively on unix and
windows machines many years ago and recently for fun or symbos: if you make
similar apps on current system with web tech the cpu gets a massive hit for
things that should not even be moving the needle. And on native tech it
doesn't: but on tcl/tk it does not either which is not native.

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.

------
galistoca
WebViews do suck on mobile and it's not a myth. People talk about how it's
catching up but that's the problem: it will be a perpetual "catching up" game,
forever. Devices are built with proprietary technologies and they will forever
keep adding new features. HTML is a standard which can only progress through a
long process of debate and agreement. They will probably end up implementing
only those features that are at the intersection of Android and iOS feature
sets.

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".

------
Koromix
"Does every single screen need to have 60 fps animations, with activities that
launch from the exact x/y coordinate where my finger touches the screen?"

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?

~~~
iamleppert
Why do you think its so bad? Javascript and HTML are plenty fast, and if need
something faster you have access to a raw GL context and associated APIs.

~~~
Koromix
They are not plenty fast. You know you don't have a fast platform when the
best you can do is scroll + a couple animations at the same time.

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](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.

------
mwfunk
All of the listed reasons relate to the experience of software development,
not the user experience. Of course it's harder to maintain native apps plus a
web front end to a service. Users don't know or care how many developers were
involved or how much money it cost or how much of a pain it was to keep
everything consistent across multiple code bases. They just want the least
terrible experience possible.

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.

------
datashovel
Just a side note, somewhat related. I'm very interested to see where this
argument (webview vs native) ends up. Say in 10 years. It seems to me that
every time there's a "proprietary" vs "open" argument, for a short while the
proprietary side wins the battles, but long term it seems the "open" side of
the argument always wins the war.

~~~
joeyspn
All the UX Research we've done with our customers shows that _100%_ of them
CAN'T differentiate Native mobile apps from _2015 /2016 Hybrid apps_.

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.

~~~
ryanwaggoner
Yeah, I don't believe this. You're clearly not an unbiased observer here,
which is fine, but I'm skeptical of your "research".

~~~
joeyspn
It's ok to be skeptical. I don't trust everything I read in forums. So I
invite you to ask to your customers what works for them and what doesn't.

------
alayne
Most of these arguments boil down to things that benefit the developers, but
not the user.

~~~
pbreit
Except benefitting the developer can have an even larger benefit on the user.

------
tormeh
Modern web browsers are VMs. They are for GUIs what the JVM is for server
software. I don't blame developers for moving towards using VMs everywhere.

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.

------
hidro
As a mobile developer, I do appreciate WebView. Using it in the right place
for the right situation works great, and proves to be a much cheaper solution
than any other things.

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.

------
bdavisx
Webview vs. native arguments aside, the work culture at Basecamp sounds like a
great one.

~~~
rpgmaker
It really does. The article also offers a nice perspective on how to balance
native vs webview UX design.

------
kendallpark
All my mobile dev friends cry, native, native, native!

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.

~~~
bjterry
I regularly have issues with Slack's desktop app using a tremendous amount of
CPU and memory given the functionality it's offering.

~~~
dham
My coworker has a Mac Pro with 64GB of ram and regular posts screenshots of
Slack and Spotify using 20GB + of ram. Granted he never closes those app ever,
until they become a problem.

------
Zigurd
There is a place for hybrid apps but it is a specialized place: If you have so
much content that changes so fast and that needs so many variations in
rendering that you end up building something browser-ish to render it, as in a
large e-commerce site with dozens of product categories, each with specialized
presentation requirements, use a WebView in the parts of the app that display
that content.

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.

------
nailer
Ever seen instagram fail? You'll see the app without CSS. One of the best
known UXs and its mostly webview.

------
0xcde4c3db
> The reason people feel that way is because we’ve been conditioned to think
> the “right way” to build apps is by making everything a native screen.

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.

------
mxuribe
Decent article, though I guess from the title I was expecting a deeper tech
dive - maybe a tech comparison - as to when using webviews is sufficient vs
going native. (I say this as my not being an android/mobile dev. so it could
merely be my naivete.)

------
LoSboccacc
WebWiews ain't a bad per se, it's very convenient to leverage html
responsivness. It's the heterogeneus mess that is device support, only partly
solved by crosswalk, where the problem starts

------
Razengan
After reading all the comments here I think developers and users should arrive
at a compromise; we (the users) will accept WebView apps and put up with their
clunkiness, but developers should pledge to make native versions as soon as
they can if their thing becomes popular.

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.

------
HillaryBriss
Controlling sound playback in a WebView can be quite frustrating at times.

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.

------
mschuster91
I like to develop with Ionic. It abstracts so much pain from a developer,
especially given that you need one developer to put together an app that works
on Android, iOS, desktop and (hopefully soon) Windows Phone, versus at least
four different developers.

------
iofj
Ever since google decided that webviews shall not have adblocking I hate it
when apps use them. They sort of do on ios but not on android. After
adblocking got started web ads have gotten so much worse, and I have zero
tolerance for it now. Ads everywhere. Distractions. Empty spaces. Blinking. So
open a link in a webview and you run a pretty serious risk I uninstall your
app then and there.

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

Same reason I use firefox on android over chrome.

------
gliechtenstein
Maybe you guys should check out Jason www.jsonclient.org which I posted
yesterday :)

