Happy New Year, and v1 roadmap

[zserge]

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.

[zserge]

Related: Boscop/web-view#114

[zserge]

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).

[nothingismagick]

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

[ChristoPy]

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

[zserge]

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.

[khionu]

The goals of webview.exe are very much aligned with Tauri. It could be in both projects' best interests to work in tandem.

[kayabaNerve]

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.

[zserge]

@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.

[nothingismagick]

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...

[vitalyster]

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.

1. MSHTML is still and always will be supported unlike EdgeHTML
2. It have rock-solid API compatible with all Windows versions, "hard to maintain" = ???
3. "Modern web developer" is able to automatically transpile his code for IE11 with babel/corejs/etc.

[nothingismagick]

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.

[inlife]

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?

[shannah]

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.

[Ciantic]

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.

[zserge]

I am going to merge webview-x into master on March, 1st.

[erlend-sh]

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.

[zserge]

@erlend-sh My initial plan was to go in two steps:

1. Merge and go forward to v1.0.0 with stable API
2. Create an org and promote webview and related bindings.

The reason was because these serve two different goals:

1. 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.
2. 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.

[Ciantic]

The webview org is clearly controlled by the @xionglun judging from the commits in here: https://github.com/WebView/webview

[xionglun]

@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

[erlend-sh]

@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

[nothingismagick]

Any news here? I just saw that the https://github.com/WebView org still has the same logo, but no public repos anymore:

[zserge]

@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.

[khionu]

Is @xionglun still a member? If so, they should be able to promote you.

[xionglun]

@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!

[khionu]

Thank you very much @xionglun!!

[nothingismagick]

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

[zserge]

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)

[khionu]

It's not a closed channel, the invite simply expired. This is our primary permanent invite, though yes, proprietary platform. https://discord.gg/SpmNs4S

There hasn't really been any conversation worth recapping so far. I would suggest a Meta repo be started on the Webview Org, and a starter issue to mull over initial directions. I'd be happy to help setup an RFC process, as well.

[nothingismagick]

Hey everybody. Just wanted to give a heads up that we had a little "constitutional" meeting for the org on Saturday. There is now a Discord server, you are welcome to join us:

Meeting Notes from May 16, 2020:

• Started drafting out readme for webview org
• Decided to create a "meta" repo where we can start putting our thoughts down on paper
• Created a webview discord server
  https://discord.gg/24KMecn
• We had a longish discussion about the scope of the org, and came to the conclusion that for the time being there will be a focus on the zserge headers, bindings using these headers, associated "helpers" (like tray), documentation and testing.
• Discussed testing mechanisms for CI/CD - and how utterly important it will be to have some mechanism for doing integration tests with visual regressions - because the current approach is manual and prone to operator laziness.
• Discussed mobile support for webview as an important factor sooner rather than later - at one point in the past there was even a webview integration for android - this can be "revived"
• @zserge and @nothingismagick are the two admins for the org

Action Item:
Please reach out to the bindings devs you are in contact with and notify them that the org is ramping up and that everyone is welcome to stop by the Discord server and get involved in planning how to move forward.

[baxrob]

Some notes on distilling @zserge's vision of this: https://github.com/baxrob/webview/wiki/foo_2

[Ciantic]

@zserge what is the policy on these smaller language based repos? Should they be using C bindings in the main repo https://github.com/webview/webview eventually?

I think for instance https://github.com/webview/webview_deno does not use the C bindings provided in the main repo. Which is a bit confusing, because I would have thought that is the idea, if they don't use same bindings it will mean all the language specific efforts work a bit differently. For instance right now I'm wondering why Deno version of webview does not use Webview2 ( webview/webview_deno#37 ) even though these C bindings clearly provide a support for it.

[nothingismagick]

Hey @Ciantic - you are right, the deno lib WILL transition to consuming the new rust bindings. This is all very much a work in progress, so your feedback (and contributions) are apprecitated!

[Ciantic]

Hey that's great to hear! I think it would be a good idea to make some policy, that language specific bindings should eventually somehow rely on the C bindings. I understand that this is a slow process and will take time.

I'm not sure is that policy wanted, it probably needs to be discussed. But IMO it would make sense, so that we can have a solid support coming from C based bindings, and language specific repos add features on top of it.

[nothingismagick]

You are absolutely right about the policy, do you think we need some better wording here?

https://github.com/webview/meta/blob/master/README.md

[Ciantic]

First of all thanks, I haven't looked in to that meta repo before this. I was following this roadmap discussion. I think it could be stated in words too, that the goal is to depend on single main repo. Since we have a policy of sorts, this is a bit implicit:

webview_%language% - a binding to the core headers, where %language% is nim, rust, python etc.

I guess one can infer core headers means the webview/webview. However, I don't care about the wording, just that every language specific repo maintainer have the same goal: eventually depending on webview/webview.

[nothingismagick]

sure - would you mind making a PR there?

[Ciantic]

Okay I will try. Maybe this kind of discussions are better kept in that repo anyway.

[baxrob]

Hey @zserge or @nothingismagick -- Could this issue/thread be re-started/pinned since the org coordination is settled? I've been thinking about numerous details in the initial post, but it's rather way down on the page here for anyone to comment or discuss those

[Ciantic]

I think this Issue should be moved to https://github.com/webview/meta if this is not mainly about the code in this repo anymore.

[baxrob]

@Ciantic, I've been looking around this project and related things since February, and this issue is rather the central or only document about the proposed or current core concerns. So maybe better to consider moving it later. And my idea of re-starting the thread doesn't really seem useful -- there are several comments about the initial post, and it's not that long for a github issue.

Maybe this thread could function as a gathering point for reflection on the project history and roadmap? And for folks' sense of what this means to their work and what roles they might or could support? And then branch some topics off to issues in the meta repo?

For myself, I'm probably coming at this from a different perspective than many here. I've tried to summarize my sense of how it all fits together at https://github.com/baxrob/webview/wiki/foo_2, with demarcation of points I intend to work on in the near future. In brief, I only care about the previous c-only "webview-w" version currently and am focused on the smallest, most c89/99, unix-ey approaches and minimal vanilla es5 js/etc.

For the overall project, I've so far broken down the separation of concerns a bit differenty from the meta repo document, into 'core' and 'ancillary' at the top, and then 'extensions' gathering the main bulk of non-core things.

I think it's worth noting that it took around two years(?) to get to v0.1.1, and it seems reasonable to think it would take another two years to get to v1.0 as @zserge has proposed

[Ciantic]

Okay apologies for abusing this thread. But I just noticed something really out-of-step move by Microsoft:

In the future, your production application should include the installer.

Distributing the app

They want to make webview2 depended applications require an installer to package the application that uses webview:

When distributing your application, package your app with the WebView2 installer to ensure your application runs on client machines.

See installer document

What does this mean for this portable C code? This would effectively mean that this repository should include some packager for Windows. I think the Microsoft engineers don't understand that we don't want damned installers.

I opened a MicrosoftEdge/WebView2Feedback#341 here. If you want static executables, please make your voices heard. I for one, don't want to have installer with my webview applications.

[neontorrent]

Second that do not drop win 7/8 support. If IE is hard to maintain support, can we have an easy way to optionally bundle a chromium with the app?

[DBJDBJ]

2021 FEB 16

I dare to ask:

Are there any active devs on this repo?

[nicklasfrahm]

@DBJDBJ I have reached out to @zserge via email, because I really like the library and have some time for spare.

[erlend-sh]

An actively developed alternative is
https://github.com/tauri-apps/wry

[justjosias]

@nicklasfrahm Feel free to contribute. There are several active developers working to revive the project now, and we're planning on following zserge's suggestion to add active contributors as maintainers to the repo.

[nicklasfrahm]

I would triage issues and so on, but I am not a contributor. Ergo I can't close issues, etc. Would it make sense to set up a maintainers.md or something?

[dandeto]

Yes, maintainers.md is a good idea. Instead of being it's own file, I think it would be best to add that information directly to the readme at https://github.com/webview/meta. Maybe we can link to it from this repo.

[nicklasfrahm]

That sounds great, do you have a preliminary list? I'd submit a PR, but I don't have the necessary info.

[dandeto]

@nicklasfrahm I'm slowly adding the 'help wanted' label to some issues. Others are labeled with 'bug.' If you find any bugs yourself or see any issues that you like, start there. I personally have been working on features I think this library should have in addition to bug fixes. If you are working on a feature, please be sure to read posts from zserge (like this issue) about the direction he wants the library to head in.

[nicklasfrahm]

@dandeto I would also add labels, but I am not a collaborator.