Tiny cross-platform webview library

Tiny cross-platform webview library(github.com)

53 points by xearl 5 years ago | 8 comments

I think there's a gap in the market for a tool like Electron/NW.js, but using the system webview, bundled resources, and just a few choice polyfills for desktop-specifics (e.g. reading the command line). Libraries like this are interesting as they look like they cover the webview piece of the puzzle, but with bundled resources and a couple of extra capabilities, you could actually start distributing lightweight standalone web apps for desktop. There's no need to distribute a full browser engine, it shares the system browser engine keeping memory usage down, and it auto-updates - fixing several common criticisms of Electron/NW.js apps. Maybe an opportunity for an enterprising developer...

Per_Bothner 5 years ago | |

As an example, the DomTerm (https://domterm.org) terminal emulator supports multiple front-ends, including a webview wrapper, an Electron wrapper, a QtWebEngine wrapper, starting Chrome in --app mode, or just using your browser. The webview wrapper works pretty well, but it is not as polished as the Electron or Qt wrappers. One issue is it relies on a JavaScript library (https://github.com/PerBothner/jsMenus) for menus, which works reasonably well, but has some downsides, including not integrating with the Mac menu bar.

An alternative to WebView is WxWidgets, which also uses the "system" browser engine, but also has a menu API, which webview (currently) doesn't.

WebView development seems to go in spurts. Recently there has been a mini-spurt, after quiet for half a year. It could definitely do with more love.

oscargrouch 5 years ago | |

If you can bundle a static or shared library that have a common api where you can link and build your platform over, where the dev will know what composition HTML, CSS, JS works without having to resort to a common denominator in contradiction to your point of view, i don't think is the best approach.

It will give more burden to the platform developer and to the developer, having to work with less features and unable to follow more experimental technologies.

> it shares the system browser engine keeping memory usage down

The problem with high memory pressure have nothing to do with sharing a DSO or not, as this is a per process issue, the problem is that with the multi-process architecture, each renderer process have its own WebKit and V8+Node heap instances that need to deal with tons of javascript, resources and the bloat that comes with modern platforms like React, compiling Typescript on the fly or loading big WASM binaries.

I mean, the web standard is too complicated now, and theres a need for companies who can afford thousands (expensive) man-hour just to keep up.

Which leads to the reality of most browsers engines not being able to follow and becoming outdated in the near future.

Which means that shipping a "killer app" in such platform, like Visual Studio, will be harder than platforms like Electron, that giving its direct use of V8 can also have a "batteries included" platform by shipping together with NodeJs.

d--b 5 years ago | |

How about https://tauri.studio/ ?

Jyaif 5 years ago |

Offering your app as a pure http server seems superior to opening a webview, not to mention simpler.

aewens 5 years ago |

Are there any performance metrics for this against using something like Electron instead?

diggan 5 years ago | |

Performance characteristics of what precisely? It's using webkit on both macOS (via Cocoa) and linux (via gtk), Edge on Windows, so I would assume the performance is similar to any other wrapper using those runtimes.

slmjkdbtl 5 years ago |

Can this be used as an embedded browser and expect the standard web browsing experience?