Now that web apps can be put on apps stores, is there much point in WebViews?
How many API’s are accessible only to native apps? It seems like most of these features are gradually being made available to the web.
How much slower is a hybrid app compared to a fully native app?
WebViews still play a role, and it depends greatly on the type of app you are building. You are right in stating that many native APIs are already available in the web layer, but many APIs - especially for custom device capabilities or ones that expose functionality from custom native components - will still require a way for web code to call into native code.
The performance gap between hybrid and fully native depends on the workload. In general, because hybrid apps involve one additional massive layer of abstraction (the web runtime) between what users see and the low-level hardware, you see a big hit in startup cost, memory used, and so on.
Thank you for this interesting article !
I consider hybrid applications with webviews as one of the most important applications on desktops too!
I use WebView from the JavaFX package unfortunately this has an old WebKit version as a base. It lacks a Chromium based WebView on the Desktop (Windows and Linux), so I would have to work with heavyweight Chromium Embedded Frameworks.
It would have a current WebViewer (by WebKit) for embedding in Deskstop applications are provided … someone knows a solution for this?
Friedhold
Would using Electron be an option? There isn’t a whole lot of investment to provide non-CEF solutions for cross-platform WebViews. This isn’t ideal for your case where you are using JavaFX as your app layer.
Nice article.
Still newbie to web technologies, as I m coming from traditional c++, java background.
I am still confused on the basic difference between webview and rendering engines like webkit or blink. Feel like their purpose is one and same. Can you shed some light on that?
Thanks in advance.
They are similar. The rendering engine is primarily interested in painting pixels based on whatever HTML/CSS/JS it is dealing with. The WebView is the frame surrounding the rendering engine, and it comes with its own APIs to allow whatever app container it is in (could be Electron, WPF, etc. app) to communicate with the rendering engine and other related components.
Do you have or know of a comprehensive list of these?
I don’t, but I would venture every major app framework in existence today will provide support for a webview. Even if it didn’t, you can roll your own webview with only some effort 
Riiiight. I was just curious if you knew of something cool that I didn’t already. 
Thanks for helping out on this.
Thanks for writing this article! In it, it seems like you use the term ‘WebViews’ very broadly, encompassing ‘traditional webviews’ and ‘integrated in-app browsers’. Would you be able to share some information about how you view the differences between these types of ‘webviews’? Are both types still available, or have IIAB types now the standard?
In-app browsers are just WebViews. Where a WebView contains no UI, the IIAB contains your typical address bar, buttons, and related UI that makes the WebView more usable as a browser. Does this help? 
Thanks for the reply… I thought the IIAB is preferred not only because of the built in browser UI but also because of security reasons. I don’t do any native mobile development, but when I was researching a little bit into this area I came across another article:
https://www.addthis.com/blog/2017/04/04/in-app-browsers-explained/ and the google android developer article:
https://developer.chrome.com/multidevice/android/customtabs
The takeaway I got from those had to do with user data is kept secure with an IIAB vs a webview, but I haven’t found much other contemporary literature about the topic of webviews.
You can customize the behavior of a WebView to be more secure by enforcing HTTPS only navigation, blocking cookies, etc. Many in-app browsers prepackage some of these customizations “for free”.
There are many reasons why platforms encourage in-app browsers over WebViews. For navigating to various URLs, the convenience is a big factor. You don’t have to recreate any new UI. A more cynical reason has to do with ensuring some of the OS/platform’s more proprietary “extensions” are run as part of the browsing experience. These are extensions that you may not enable with a raw WebView for various reasons.
Sorry to bother, but what “101” means? I burn with curiosity.
It’s a way of signifying that Kirupa’s going to cover the basics of webviews in that paragraph.
1 Like
Nice article 
.
But I am kinda confused on how webViews are integrated into sections native mobile applications or desktop applications. I know about full screen hybrid apps. I have used electron for creating dektop application. But I don’t know how to embed into a section of the native application like an advertisement.
Hi @Japan1 - welcome to the forums
Think of the WebView as an image element in your native UI. This image element is part of other things on the page like text elements, buttons, etc. The source of the image element would typically be an image file - which could be a part of the package or retrieved from a remote URL.
Now, replace the image element with a WebView. The source of the WebView could be some HTML content local in your package or some HTML content out in the larger internet.
Does this help clarify?
Very nicely explained Kirupa ! Awesome !
Thanks! Glad you liked it. It was one of my favorite articles to write 