What's the webview tag good for?


#1

I’m been looking at the tag, and it looks like a good way to open web pages.

Other than that what could a person do with it? For example how does atom use the electron webview tag?


#2

Yes. Please note that WebView originates from Android’s WebView class.

The overview in Android’s doc page summarizes it quite nicely.
(source: http://developer.android.com/reference/android/webkit/WebView.html)

A View that displays web pages. This class is the basis upon which you can roll your own web browser or simply display some online content within your Activity. It uses the WebKit rendering engine to display web pages and includes methods to navigate forward and backward through a history, zoom in and out, perform text searches and more.

For Electron’s case, it is very similar to Chrome’s tag.
(source: https://developer.chrome.com/apps/tags/webview)

Use the webview tag to actively load live content from the web over the network and embed it in your Chrome App. Your app can control the appearance of the webview and interact with the web content, initiate navigations in an embedded web page, react to error events that happen within it, and more (see Usage).

I’ve only used Atom for a few hours, so I wouldn’t be a good candidate to answer your “where is it used in Atom” question.


#3

Cool. But in electron a person can enable node modules in webview. I’m also aware that there is some sort of asynchronous communication between the main renderer, and the webview.

I’m also wondering if it is a good idea to use the webview as a part of an app, and not a browser? I’ve been considering my options when it comes to partitioning parts of the application view.


#4

Yes. Using webview as an part of the app is perfectly fine.
Partitioning parts of the view is definitely something webview would be a good fit for in Electron.


#5

Thanks. I’m hoping for more opinions though.

There’s the other way which is just using DOM elements to divide up a program into it’s visual parts, but there’s got to be situations when a webview would be better, and others when DOM is more fitting.

For starters I’m thinking that a webview is a good way to create a sandbox to protect the environment. DOM on the other hand is more seamless with the current context of the program. A webview might also be better for just viewing straight files.

One good example I can think of right now is a preview for a markdown editor. I haven’t looked at the source of the Atom plugin, but I assume that the markdown preview plugin might use a webview.


#6

I’m using webviews to partition my application just as you’re intending. The app itself uses these webviews, we call them plugins, as separate but dependent parts. The webview structure makes plugin development very similar to web development which is convenient. This app is several months down the line in development and it hadn’t proven too difficult or cumbersome yet.

Though the obstacle I’m facing now that’s hard to deal with is implementing tests. I’m using WebdriverIO (basically Selenium wrapped in JS) to run tests and although I can do everything as intended with the general DOM, it’s super hard (or impossible, I’m still figuring it out) to get variable/DOM-element values from the webviews within tests.

Basically, with testing these plugins, they’re blackboxed to Selenium. Even more extreme than being black-boxed, I can’t read them at all.


#7

Yeah. It looks like the only good way to communicate with a webview is through ipc messaging. There’s another con to using webviews though it might also be a pro for security. Even so the host process should have easy access to children in my opinion. I don’t think there’s an easy way to do that. For atom plugins I noticed they offer pubsub, but I’m not sure how they’re doing that.


#8

Oh I see now. After looking at the docs some more I see the atom object is a global one. Now it’s starting to make sense though I don’t see that helping with webview communication.