9 ms·

Myth debunking: WebViews suck, everything should be native

89 points by gvb 10y ago

Koromix 10y ago
"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 10y ago
  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 10y ago
    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.
  - wrl 10y ago
    If your plan for speeding up a slow user HTML/JS interface is to rewrite parts using WebGL, you're severely underestimating the amount of support code you'd need in order to make that happen. Coming from somebody who has developed and maintains OpenGL user interfaces, you're better off just writing the native app.
hidro 10y ago
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.
mwfunk 10y ago
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.
LoSboccacc 10y ago
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
iofj 10y ago
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.
Razengan 10y ago
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.
- Razengan 10y ago
  In fact, it may be just me but the whole WebView/Electron/whatnot thing feels like a tool that may have been intended for internal prototyping but got sneaked into a user-facing release, and now everyone is pretending they meant for that to happen..
- gaius 10y ago
  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 10y ago
    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.
bdavisx 10y ago
Webview vs. native arguments aside, the work culture at Basecamp sounds like a great one.
- rpgmaker 10y ago
  It really does. The article also offers a nice perspective on how to balance native vs webview UX design.
kendallpark 10y ago
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.
- jonhohle 10y ago
  Atom was notorious for not being able to open moderately sized files earlier in its life: https://github.com/atom/atom/issues/307 https://github.com/atom/atom/issues/307
- wyager 10y ago
  Atom is horrendously slow. The only reason I use it over sublime is that it has better plugins.
- bjterry 10y ago
  I regularly have issues with Slack's desktop app using a tremendous amount of CPU and memory given the functionality it's offering.
  - ch4s3 10y ago
    Same. I regularly notice it using upwards of 1.5GB of ram.
  - dham 10y ago
    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.
datashovel 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
- jack9 10y ago
  In 2010 we said "wait and see, but use native for now unless you really can do with an interactive webpage". Not much has changed.
mxuribe 10y ago
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.)
nailer 10y ago
Ever seen instagram fail? You'll see the app without CSS. One of the best known UXs and its mostly webview.
mschuster91 10y ago
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.
tormeh 10y ago
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.
alayne 10y ago
Most of these arguments boil down to things that benefit the developers, but not the user.
- pbreit 10y ago
  Except benefitting the developer can have an even larger benefit on the user.
galistoca 10y ago
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".
gliechtenstein 10y ago
Maybe you guys should check out Jason www.jsonclient.org which I posted yesterday :)
maxsilver 10y ago
> 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 10y ago
  > 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.checkout&hl=en 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.
  - galistoca 10y ago
    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.
HillaryBriss 10y ago
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.
0xcde4c3db 10y ago
> 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.
Zigurd 10y ago
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.
Razengan 10y ago
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.

89 points by gvb 10y ago

"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 10y ago
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 10y ago
  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.
- wrl 10y ago
  If your plan for speeding up a slow user HTML/JS interface is to rewrite parts using WebGL, you're severely underestimating the amount of support code you'd need in order to make that happen. Coming from somebody who has developed and maintains OpenGL user interfaces, you're better off just writing the native app.

hidro 10y ago

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.

mwfunk 10y ago

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.

LoSboccacc 10y ago

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

iofj 10y ago

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.

Razengan 10y ago

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.

Razengan 10y ago
In fact, it may be just me but the whole WebView/Electron/whatnot thing feels like a tool that may have been intended for internal prototyping but got sneaked into a user-facing release, and now everyone is pretending they meant for that to happen..
gaius 10y ago
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 10y ago
  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.

bdavisx 10y ago

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

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

kendallpark 10y ago

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.

jonhohle 10y ago
Atom was notorious for not being able to open moderately sized files earlier in its life: https://github.com/atom/atom/issues/307 https://github.com/atom/atom/issues/307
wyager 10y ago
Atom is horrendously slow. The only reason I use it over sublime is that it has better plugins.
bjterry 10y ago
I regularly have issues with Slack's desktop app using a tremendous amount of CPU and memory given the functionality it's offering.
- ch4s3 10y ago
  Same. I regularly notice it using upwards of 1.5GB of ram.
- dham 10y ago
  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.

datashovel 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.
jack9 10y ago
In 2010 we said "wait and see, but use native for now unless you really can do with an interactive webpage". Not much has changed.

mxuribe 10y ago

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

nailer 10y ago

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

mschuster91 10y ago

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.

tormeh 10y ago

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.

alayne 10y ago

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

pbreit 10y ago
Except benefitting the developer can have an even larger benefit on the user.

galistoca 10y ago

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

gliechtenstein 10y ago

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

maxsilver 10y ago

> 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 10y ago
> 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.checkout&hl=en 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.
- galistoca 10y ago
  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.

HillaryBriss 10y ago

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.

0xcde4c3db 10y ago

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

Zigurd 10y ago

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.

Razengan 10y ago

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.