When it comes to accessing internet content, we typically use a browser like Chrome, Firefox, Safari, Internet Explorer, and Edge. You are probably using one of those browsers right now to read this article! While browsers are pretty popular for the whole task of accessing internet content, they have some serious competition that we probably never paid much attention to. This competition comes in the form of something known as a WebView. This article will explain all about what this mysterious WebView is and why it is sorta kinda cool.
This was an interesting article but as a user is there anything that I can do to make use of it? I hope you have follow on articles that will explain this to an average user like myself.
As a user, there isnât much for you to do. You will just see it as part of your regular interactions with many apps.
As a developer, there is a ton. The amount of programmatic capabilities WebViews expose is enough to help you build a browser around one if you so choose. Talking about the developer story strays a bit too far from web technologies, so I may not take that route for some time.
When I have developed Visual FoxPro applications for the desktop in the past, I have used the Web Browser control to employ Internet Explorer under the covers to incorporate web content into the desktop app.
Your article brings back fond memories as well as makes me think about the possibilities in the Internet of Things.
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.
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
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.
