Experimental new lightweight Windows wrapper

We're experimenting with a new way to export to Windows with a lightweight wrapper based on the Microsoft Edge WebView2 control. Similar to Cordova, it's basically a system webview that runs your project, but using a Windows system webview.

Try it out

This is now built in to Construct 3 r237+. Choose the "Windows wrapper (WebView2)" export option.

What is Microsoft Edge WebView2?

Microsoft Edge WebView2 is a Windows system WebView based on the modern Microsoft Edge, which is now based on the Chromium browser engine (the same one Google Chrome uses). This means native Windows apps can display web content using the WebView2 control. This experimental wrapper just creates a window with a WebView2 in it, and loads your project in it. You can think of it as working similarly to Cordova, which loads your project in a system webview. This allows for very lightweight exports, as your project is basically a standard HTML5 export, with a small wrapper app to load it.

Features

This wrapper is built with the philosophy that it should do as little as possible. Ideally WebView2 will do everything. If it cannot, or some feature needs a bit of extra code, then the goal is to use built-in features of Windows instead. This avoids bloating the wrapper app with libraries, frameworks and other code, since much of what Construct games need is already built in to Windows.

Having said that, the points of interest are:

• Uses a fully-featured modern Chromium-based browser engine - i.e. it can do everything that also works in Microsoft Edge/Google Chrome
• Tiny overhead (wrapper app is about 250kb compressed)
• Should work on Windows 7 and newer (note it's currently only been tested on Windows 10 - we're keen to hear from you how it works with earlier Windows versions)
• Supports DevTools - like in a browser, press F12 to open them
• Automatically approves permissions without prompting, e.g. camera
• Most features that require a user input event in browsers work unrestricted, e.g. starting audio playback immediately (but note requesting fullscreen seems inconsistent - see report)
• WebView2 automatically updates, so you don't need to distribute updates just to update the browser engine
• Links open in the default system browser
• Browser 'Close' action can exit the app
• Invoking downloads works, since it supports the download UI
• YouTube videos can play, since it supports full proprietary media codecs the same way Microsoft Edge does

Distribution

One caveat is that for it to work the system must have the WebView2 runtime installed, and not all systems have it pre-installed. However this could change as Microsoft's documentation states:

In the future, the Evergreen WebView2 Runtime plans to ship with future releases of Windows.

So in future it may be reliably built-in to Windows. In the mean time the wrapper app is capable of identifying if the WebView2 runtime is not installed, downloading the WebView2 runtime installer, running it, and then continuing to execute the app. So assuming the user is online and has permission to run the installer, it should be a fairly smooth and reliable way to automatically self-install the runtime. This only needs to be done once per system, and then it's available to all apps and auto-updates itself.

Comparison to NW.js

NW.js differs in a few key ways. Overall it can be characterised as a more heavyweight but also more feature-complete export option for Windows (at this time, anyway). Here are some of the key differences:

• With NW.js, you distribute a complete copy of the Chromium browser engine and the Node.js runtime, with your project. The WebView2 wrapper does not include either, relying on the system webview (and if necessary installing it for the user on startup). This makes the exported file size far smaller - an empty win64 NW.js export is around 80-90mb compressed, whereas WebView2 is about 250kb compressed.
• WebView2 auto-updates. With NW.js the app never updates the browser engine, unless you re-export with an updated version and publish that.
• NW.js includes Node.js, a JavaScript framework that provides lots of features not normally available in browsers. Currently the NW.js plugin relies on this, and so none of the NW.js plugin features will work in WebView2. However many now have web platform equivalents, e.g. accessing clipboard and files, so it could conceivably be ported to both browsers and WebView2, even without Node.js.
• For similar reasons, Steam integration with Greenworks is not supported in WebView2.
• WebView2 probably uses less memory, especially when using multiple apps, since they share a common browser engine instead of each using their own unique copy of a browser engine.

Future work

The provided download is not yet production-ready - there are several more key details to sort out before then, such as providing a configuration file. If this experiment proves successful, there are several options we could explore:

• Polish: finish some remaining features like a configuration file similar to NW.js's package.json; identify bugs and missing features and resolve them
• Support for Windows 32-bit and Windows ARM64
• Integrate with Construct 3 so you can directly export to WebView2 from the editor, similar to NW.js
• Supporting things like file system access in WebView2, perhaps with some new plugins
• Potential Steam integration with the official Steamworks SDK
• Potential development of a macOS equivalent wrapper, since macOS has a built-in system webview (WKWebView)

Please note as highlighted above, we cannot guarantee any of this will happen at this stage. This is just illustrating what ought to be possible.

Feedback

We're keen to hear your feedback on this. Try out the download above and see if it works for your project. Here are some questions we'd be interested to hear your answers to:

• Does it work well?
• Are there any bugs or important missing features?
• Does it work on Windows 7 and Windows 8?
• Would you consider exporting real projects with this? What kinds of situations would you use it for?
• Would you consider using this instead of NW.js? If not why not?
• Do you think this should be something we focus on?

Let us know your thoughts by replying to this thread! We won't accept bugs for this on the main issue tracker yet as it's still experimental - just let us know about any issues here (but as always if you can provide the same information as the bug report guidelines, we'll be much more likely to be able to help). But please do share your thoughts and feedback!

• Does it work well?
• Are there any bugs or important missing features?
• Does it work on Windows 7 and Windows 8?
• Would you consider exporting real projects with this? What kinds of situations would you use it for?
• Would you consider using this instead of NW.js? If not why not?
• Do you think this should be something we focus on?

• Yes
• Missing Fullscreen
• Na
• Yes, Steam(with sdk), Itch.io, Gamejolt( might

  CROS his sdk), less than a meg download for desktop? Yes please.

Nwjs is general purpose. This can be full on gamedev? None of the extra we don't need?

Yes, if its less buggy, less maintenance, than Nwjs, but gives us more possible integration, Android, cloud gaming etc.

Posted this on Twitter too but might repost here:

Maybe kind of a stupid question but since Edge is also available for Macs would it theoretically be possible that this would work for macOS one day as well? I‘m using Edge as a Chromium alternative these days for Construct too since Chrome on Mac is just horrible with the CPU usage.

Sorry, not super tech savvy here :D

EDIT: DUH! Just saw the last bulletpoint on your list... Nevermind. I'm all for that development too though! Then we would have a great lightweight wrapping solution for the two most dominant desktop platforms :D macOS will, i think, gain more marketshare with the advance of the Apple Silicon chips.

WebView2 automatically updates, so you don't need to distribute updates just to update the browser engine

This sounds an awful lot like: "being at the mercy of Microsoft", if any new major issues occur. I know that NWjs and Electron aren't perfect but with those bloated wrappers, developers can at least stay or up/downgrade the version at any time, to workaround any new major issues. WebView2 would pretty much require developers to tell their users to: "update or wait for future potential bugfix updates!".

I think Android's webview implementation, is already a prime example of webview not being the best option. There are already many topics on this subject, regarding a variety of issues caused by certain combinations of blacklisted hardware + webview. Sure this might not be a major problem on desktop, since most "blacklisted" desktop hardware would be able to brute force things but I felt like this was worth mentioning. (There are also already people out there that don't like updating their system at all. Good luck dealing with that.)

WebView2 feels more like an opportunity to improve Construct 3 Desktop to me. At least if it ends up supporting file execution. This way developers could preview in NWjs without remote preview. I assume most C3 desktop users only use it because it removes the file permission prompts and makes previewing easier.

Worth noting that me criticizing WebView2, doesn't mean that I hate the idea of it. As already mentioned, it's too early to tell how this will turn out to be but I appreciate Scirra trying out new things regardless! (Maybe this is also a great time to look into Electron as another option for desktop distribution but that goes a little off-topic.)

NW.js makes various modifications and doesn't go through that testing process (or not as thoroughly), resulting in a regular series of of NW.js-specific issues where things actually work fine in the unmodified browser but are broken in NW.js.

At least with NWjs, bugs by the browser engine tend to get a workarounds fairly quick. Meanwhile at Chromium it's up to chance, whether you get your bug fixed by next week or next year. I think this is one of those cases, where we both think that the grass looks greener on "our" side.

It's also possible to distribute WebView2 with a fixed browser engine, but you lose the size advantage, and have to go back to shipping your own updates.

This sounds good but it feels like a bare-bones version of NWjs to me. Sure this might change in the future but that's just my opinion at the moment.

People don't tend to write forum posts saying "everything worked fine", so you can get a skewed impression from the forum sometimes.

I agree but it doesn't mean that those posts are invalid. Developers generally prefer that their projects work fine for everyone.

I know making these comparisons between operating systems is like comparing apples to oranges but it still doesn't mean that we shouldn't be concerned about it ending up the same on desktop WebView (even with the best track record in the world).

Electron is architecturally the same as NW.js (Chromium browser engine + Node.js), so I wouldn't expect anything to be materially different...

My point was more being that Electron seems to be less buggy overall and major companies, including Microsoft themselves already use it over NWjs. Obviously there is no way to know if it's better or worse without trying.

I have these warnings in the console

Failed to register service worker: TypeError: Failed to register a ServiceWorker for scope ('https://app.localhost/') with script ('https://app.localhost/sw.js'): An unknown error occurred when fetching the script.

C3_RegisterSW register-sw.js:1

Web app manifest should have the filename extension 'webmanifest'.

https://github.com/el3um4s/DenoC3Webview2/tree/main/source/c3p

Furthermore the window does not remember the size after resizing by hand

Some random ideas. Obviously I don't know if they are technically feasible, or if the work to make them is disproportionate to their usefulness.

1. I would like the ability to run files on disk (NWjs: run file.exe)
2. I would like open a window without toolbars, borders, or other graphical "chrome" (like electronjs). I would like to be able to draw close, minimize, maximize buttons directly in c3
3. Weird Idea: I don't know if it's technically possible, but I'd like the option to have transparent windows. It would be interesting to experiment with a transparent canvas and window, and "windows" of various shapes drawn directly from construct.
4. Related to the size/position of the window: the possibility of creating tray applications would be interesting (Cross-Platform Desktop Applications: chapter 8)
5. This is a very specific idea, and maybe it's just a quirk of mine: capturing output from shell stdout (I'd like something like this). But it's a very borderline use of Construct 🤔

Thanks for all your work