webview design proposal and roadmap

TLDR: modern C++ as a primary language, no IE, JSON RPC for native function bindings, prebuilt DLLs for Windows, plans for webview org.

The goal of the webview project is to create a common HTML5 UI abstraction layer for the most widely used platforms.

Platforms

Supported platforms must include, but not limited to:

• Currently supported Ubuntu LTS
• Currently supported macOS
• Currently supported Windows

Support for Android or iOS is still unclear, but might be possible and is highly desirable.

The library can be seen as a collection of three types of API:

• application (app process and main UI loop)
• native window (create/resize/set title/set color/...)
• browser engine (open URL, execute JS, call native code JS).

For the sake of simplicity and forward-compatibility with mobile platforms, only a single native window per app process is supported. For those, who have more complex use cases and the need of multiple windows there are two options: spawn a process per window and let them talk to each other via IPC, or create an external app loop on your own, then create as many native windows as you need and pass them into webview constructor. Passing a native window handle into webview constructor allows infinite customizations of the window without bloating an API. However, in this the developer is in charge of managing such native windows. The library will only provide an embedded webview widget.

With this in mind, the following window toolkits should be supported: GTK (Linux and maybe other platforms), Cocoa (macOS) and Win32 (Windows).

For each window toolkit there exists at least one corresponding browser engine. For GTK and Cocoa it's Webkit. For Win32 it's either MSHTML (aka IE), or EdgeHTML (since Windows 10), or Edge/Chromium (Windows 7/10, but needs to be installed separately as of now).

I suggest to drop the support of MSHTML, since it's not only hard to maintain, but also hard to use, as it does not match the expectations of a modern web developer.

Also, I suggest to be opinionated and provide a graceful fallback for the platforms with more than one supported browser engine. For Windows that would mean using Edge/Chromium (if available), or falling back to EdgeHTML on Windows 10. On Windows 7 an error message should be displayed.

If at some point Edge/Chromium becomes the default in Windows 10 - we will drop the support of EdgeHTML.

For Android and iOS it will be native webkit engine, but it's not clear yet about the implementation details.

languages

The core repo, as before, will support C/C++ and Go. For other languages bindings are always welcome! Bindings will remain in separate repos. Go is the only exception due to its weird nature and historical reasons.

The primary language is C++11. C wrapper is provided as well, and it's the one used in Go bindings (via cgo).

Webview remains a single-header, header-only library. For GTK/Cocoa it can be just included in your C/C++ code and compiled in a fairly simple manner. GCC, Clang and cl.exe are suppoted.

Go is very opinionanted in its choice of compilers for cgo. That's why on Windows it's safer to build webview as a DLL and link that. DLL will be stored in the repo and always available. This means, webview apps no longer can be distributed as a single executable on Windows. They must contain these additional DLLs. Fortunately, there are bundlers that can unpack executable and its dependencies on the fly, so if you really need this single-exe feature - you can get it, just not out of the box.

ci, build, tests

We must continiously ensure that webview can be built on all platforms and that its functionality is still there. Github actions is used for CI pipeline, replacing travis and appweyor.

No build system is provided. For Go no build system is needed, we expect the package to be go-gettable. For C and C++ we really need to compile and run a single file with tests. One can automate this on his own for each platform, if he wants to develop the webview core. For C/C++ users I expect them to copy webview.h into their source tree and use the existing build system. Required compiler and linker flags are documented in the source code.

If at some point we will need a proper build system - we will add it. But for now I'd prefer to now start this cmake vs make vs meson vs ... talk. A build system for a single file application can be bootstrapped within a minute.

Most of the tests are written in C++. C and Go tests exist, too, but only to ensure the compatibility. Functional tests are in C++. Also, linters and code formatters should be run during the CI.

On Linux and macOS a single shell script performs all the builds, runs the tests etc. In addition, once launch webview_test.cc and main.cc as shell scripts (i.e. sh webview_test.cc) - this will compile and run the binaries on-the-fly.

On Windows, a batch script is used instead. The script uses msbuild.exe to compile a DLL, and to build+run the tests.

webview.exe

It makes sense to provide a pre-compiled executable that can load arbitrary JS/HTML/CSS, load requested DLLs/.so and has some FFI to call native functions. In this way the whole desktop app can be written in JS plus any low-level landugage of preference, and bundled without any build steps or need to install any unrelated tools.

Something like love2d does should work well.

It's still a proposal, we need to estimate the complexity and the demand on this.

window API

• create window: should optionally enable debug console window, or receive a native window handle to reuse. This allows caller to prepare window on its own (use transparency, or control the app loop externally and let webview only manage browser engines inside the existing native windows).
• destroy window
• resize window
• set window title

Obviously, app main loop would include an infinite run() API and an API to dispatch(cb) a callback to be executed on the UI thread.

That's all for now. In future, we may think of adding color/transparency support and other customizations.

Support for dialogs, tray, menus is beyond the scope for now and most likely can be implemented as separate header files and separate Go subpackages after v1 is released.

webview API

• navigate(url) should open an URL in the webview. URL can be a regular http/https URL, or a data URI where HTML code is embedded in the URI itself.
• exec(js) should execute JS asynchonously in the webview.
• init(js) should add JS to be executed every time webview opens a new page.

Additionally, a native callback should be provided to be executed whenever JS calls window.external.invoke().

bi-directional communications

JSON RPC is used to build proper asynchronous bi-directional communications on top of exec(), init() and window.external.invoke(). Proper language-specific bindings can be built on top of that.

politics

Let's play democracy, although it's not a hot trend anymore. I suggest to:

• Finish v1.0.0 with the minimal viable set of features, but proving that it's posisble to have a common webview abstraction for desktop and maybe even mobile.
• Then, create an org.
• Everyone who makes at least 2 PRs is added as a maintainer to the org.
• Every 6 months I open an issue asking all maintainers to confirm their will to remain maintainers. It's absolutely voluntairly and nobody is forced to continue, if the interest in this project is lost.
• All 3rd-party bindings that webview maintainers consider high-quality are suggested to be moved into the org.
• For the first year since v1.0.0 I keep the right to single-headedly add/remove maintainers, accept/decline PRs etc. Democracy needs time to grow up.

To me, this sounds like a good plan for the project to go on, as long as the community finds it useful, without depending on a single grumpy opinionated developer, as it is now.

state of things

All core APIs seems to be done for all platforms (linux, macOS, Windows 10). Please, have a look.

I would be glad to hear any feedback about the branch webview-x, and if someone feels confident to become a maintainer at this point - please let me know.