webview
Happy New Year, and v1 roadmap
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.
UPD: Bindings now work with C/C++ (input and output are both JSON strings, parsing must be done manually, but webview has a helpful utility function for that), and for Go (parsing and type conversion is done automatically, like in Lorca).
This sounds really, really great. Thanks for linking it back to boscop's repo (otherwise I would have probably missed it). I am glad to help with the setup of the organization in any way I can - and I think that an overarching org within which the bindings can live (like boscop/web-view) would probably be the absolute best solution all around. This would bring a lot of the disparate contributions back upstream.
LGTM!
@erlend-sh @Boscop @zxey @lucasfernog @tensor-programming @nklayman @jbolda
I stumbled with this project a few days ago and by seeing this issue makes me so happy, i trully believe this can be so helpfull to people
As time goes, I will be cleaning up issues and PRs not related to the new webview-x approach.
If there is anything that in your opinion should seriously keep webview-x branch from merging into master - speak now, or forever hold your peace.
The goals of webview.exe are very much aligned with Tauri. It could be in both projects' best interests to work in tandem.
Very interested to track this since I use WebView with my project.
I'm disappointed to hear only W10 will be supported in the future, but I understand the decision given W8's low market share and the fact that W7 is now EOL.
I was also thinking about the two project's alignment. In order to find out if the project's should work together or not, would you mind commenting what Tauri does/doesn't do that you would like WebView.exe to do/to not do? If the two projects have the same goals and the same functionality, there's no advantage to splitting resources.
@kayabaNerve In theory, only in theory, Windows 7/8 might work with Edge/Chromium (as it is now available for older versions of Windows as well). The reason I state Windows 7/8 are not supported is because I personally got not time to test it, and would rather focus on the most widely used version. If you are interested in Windows 7/8 support - feel free to give it a try, and let us know how it goes.
It is probably a good idea to look into some of the things that are different in the boscop/web-view version of webview that is shipping there. There are some interesting PRs going on with multiwin, menus and transparency. All critical issues for practical usage if you ask me.
Also NOT having one monolithic file for all platforms can reduce the ultimate bundle size - which is something I care about deeply. We've gotten our binaries to around 600KB at tauri - but I know that there is more that can be done for the ultimate golf...
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.
Please, don't.
- MSHTML is still and always will be supported unlike EdgeHTML
- It have rock-solid API compatible with all Windows versions, "hard to maintain" = ???
- "Modern web developer" is able to automatically transpile his code for IE11 with babel/corejs/etc.
Totally agree with @vitalyster, especially regarding 3. Regarding "hard to maintain" - I think the community is bigger than you think, and having an org will leverage this - because the project enters the commons.
Honestly, looking at the mess in the code that MSHTML implementation is, and requirements and hacks that are needed to support it, I feel like @zserge has a point. Especially how painful it is to actually use MSHTML with modern js libraries, even with a transpiler with the most "hardcore" settings.
However, both points made by @vitalyster and @nothingismagick are valid as well. I feel like there can be a compromise: what if there would be let's say a webview_ie.h just for sake of the comfort of working with the general header. That would be easy to maintain (for those who are interested), not getting in the way, and for the DLL compilation, it can always be auto-included, and compiled alongside the webview.h impl.
How does that sound?
Basically @zserge is saying he doesn't want to support MSHTML. I don't blame him. I've recently spent more time than I would like banging my head against master branch to try to add "onLoad" event support (was easy in every platform except Windows), before switching to the webview-x branch. If someone has the skill set to step up and implement the webview-x branch's API using MSHTML, then I'm sure it would be a different story. The surface area of the API is small, so having a "deprecated" MSHTML fallback probably wouldn't be too much of a hindrance to the rest of the project.
Hard to imaganie anyone wanting to deal with MSHTML either because modern web development tools wont work with, only corporate could make use of it. Is @vitalyster or @nothingismagick in corporate environment? In a year WebView2 should be widely available in Windows 10 by default, if this is forward looking roadmap, it should be the focus, not the past.
Could we get an org setup before then? Would be good to have the web-view rust bindings repo as part of the org by the time the webview-x merge happens, as the merge will attract attention that benefits all.
@erlend-sh My initial plan was to go in two steps:
- Merge and go forward to v1.0.0 with stable API
- Create an org and promote webview and related bindings.
The reason was because these serve two different goals:
- Prevents users from reporting issues with older webview that have been fixed in webview-x, and let users post more new issues related to webview-x. This would pretty much affect only loyal users who follow the repo without waiting for "stable" releases.
- Will be a more-or-less stable and feature-full version of webview that is recommended for all users, at this point an org with all known and solid bingdings is a must.
If we combine the two steps - we might end up with a storm of unhappy users who lost the features they have been using in existing webview. So I would like to make it as gradual as possible, in smaller steps.
Speaking of the org, I wrote to github support about https://github.com/webview - they responded the account is in use (private repos mostly), but if we can create a good convincing message to the account owners - github will send it on our behalf.
So if somebody has good written English skills - feel free to propose the official appeal! Otherwise - we would have to look for a different org name.
The webview org is clearly controlled by the @xionglun judging from the commits in here: https://github.com/WebView/webview
@zserge indeed, I created this org many years ago, and it is useless to me. So, yes, i'm glad to contribute this org to this awesome project. If you can contact the github office, ask them give me a new org name such as webviewx, and then transfer this org name to you.
Sincerely
@zserge did you hear anything yet from GitHub about the org name transfer?
I’m gonna propose again to create an org sooner rather than later. There is nothing really blocking it; even if the webview org name is released days later, renaming to that will be painless:
https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-an-organization
Having the org set up would unblock a lot of effort that could be happening right now to suss out co-ownership and maintenance of the web-view repo.
We don’t even need webview in there to begin with, just web-view, the rust bindings. Meanwhile you can continue with your 1.0 release plan as outlined, undisturbed by ownership changes
Any news here? I just saw that the https://github.com/WebView org still has the same logo, but no public repos anymore:
@nothingismagick Well, I was invited to the webview org, and I joined it, but I only have regular member rights there, so obviously I can not rename it to make another webview org, also I honestly find it a bit too risky to move this repo to the org where I don't have enough privieges.
@zserge invitation always starts as regular member, I have promoted you as owner just now. I'm ready to quit and you will take over it. So, you SHOULD NOT worry about that, it's all yours now!
That's really awesome. In anticipation of this, over at Tauri we have started preparing the move away from Boscop's bindings in order to stick with this, the canonical upstream source (and make our own bindings to it). We've already made Tauri's fork from this repo - can't wait to point the fork at / source from the official one!
In case you're interested, here's a link to our RFC where we discussed moving back "home": https://github.com/tauri-apps/rfcs/blob/master/texts/0001-webview_bindings.md
Shall we perhaps create an open chat like gitter/discourse/... to centrally communicate and maybe help people with questions (there's too many issues that are questions)
We make heavy use of discord. Discourse is good for long-lasting discussions, but not a replacement for realtime help.
Well, this issue story looks more like a chat, so any real chat would probably be better.
if you want to join our discord server, see if you like it - i'm sure we can help you set up a "webview org" one pretty quickly.
https://discord.gg/WJM9dX
The problem with gitter (IMHO) is that it is really single threaded.