Experimental new lightweight Windows wrapper

3 favourites
  • 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!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I Love when you open to trying new tech to improve the Engine that gives a lot of hope for the future even if it fails but at least you try, which gives more trust and security that you trying all in your capabilities to improve your engine.

    PS:

    I hope you can try new tech for the "Android" side swell as is much needed desperately as it's deteriorated quite a lot recently. :)

    Thank you for your hard work

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

  • This is an amazing development. The only issue I really had with Construct at all was its desktop export bloat, I could have a low poly 3D Unity game that had a download a lot smaller than a pixel art C3 game using the old Node Exporter. I tended to publish pretty much only web builds with C3 for this reason, mobile also similarly having the benefit of a small file-size.

    As I have a somewhat limited upload speed on my internet connection, I am really happy to see this and hopefully not having to re-upload a 200mb file for a bug-fixed game build 10 times over the course of a few hours, when the game itself is a tiny fraction of that.

    I really hope this continues into development, even if it ends up being Windows only (or until a similar solution is available for the other desktop OS). I think this will also hopefully make Construct a lot more competitively viable for making mini PC games with tiny download sizes, compared to similar engines that just compile a build without packaging a ton of libraries.

  • Fantastic!

    Could the WebView2 auto-update feature ever break games? I think I remember some versions of NWJS breaking stuff with updates, like you never know if the updates is going to be a harmful one or not, so I'm glad that when you export with NWJS it doesn't change version automatically!

  • Hurray! I've been experimenting with denojs, webview and c3 for a few days: I'm happy to be able to try a more "native" solution

    Avast currently recognizes the file as a threat

  • Could the WebView2 auto-update feature ever break games?

    Just like with publishing HTML5 games, it's possible that browser updates can break projects, but it's generally rare. There are old Construct 2 exports from years ago that still run just fine AFAIK.

    Avast currently recognizes the file as a threat

    That's a concern, but there's probably not much we can do about it - generally all unsigned executables are viewed with suspicion by both the OS and antivirus software. Usually if you are a serious about publishing to Windows you'd digitally sign the app, which increases the level of trust. Without signing trying to evade antivirus is a losing battle - there are probably dozens of security tools out there, and lots of malicious people have spent years trying increasingly clever ways to evade them. The best approach is probably to report false positives to the antivirus vendor. One of the under-appreciated benefits of web publishing is you never have this type of problem!

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

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

    On the contrary, I'd say NW.js is actually the cause of most such issues, and avoiding using it will avoid these issues. The unmodified browser engines go through very stringent testing, including testing labs, and broad release on the canary, dev and beta channels with active use by global developer and tester audiences, before arriving at stable. 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. Therefore I think using an unmodified browser engine, which is what WebView2 does, should actually be more reliable than NW.js. As I mentioned before, many web exports have been working fine for years, so I think historically the compatibility has proven very good.

    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. Given how good web compatibility has been historically, I think getting browser engine updates for free is actually a benefit.

    I think Android's webview implementation, is already a prime example of webview not being the best option.

    Android is a whole other operating system so I don't think this has any particular bearing on Windows. I'd add that on the whole I think the Android Webview does work well. People don't tend to write forum posts saying "everything worked fine", so you can get a skewed impression from the forum sometimes.

    WebView2 feels more like an opportunity to improve Construct 3 Desktop to me.

    My goal is to not have to have a Construct 3 Desktop at all, and do everything in the browser. I think we're actually quite close to achieving that, especially since the editor can use file access now.

    (Maybe this is also a great time to look into Electron as another option for desktop distribution but that goes a little off-topic.)

    Electron is architecturally the same as NW.js (Chromium browser engine + Node.js), so I wouldn't expect anything to be materially different with that. The point of this experiment is to remove a significant amount of complexity, maintenance complications, and release management, and go as far as possible to having a minimal lightweight wrapper. Having nobody else involved between us and the WebView actually makes things a lot simpler and, since complexity always adds bugs, more reliable. That's part of what this WebView2 experiment is aimed at. The fact it makes different tradeoffs also makes it a more interesting alternative to NW.js - for example if you really want a tiny file size overhead, Electron is not particularly interesting as it has a similar overhead to NW.js, but WebView2 is as it has a tiny overhead.

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

  • Just tried to use the recorder from the Xbox Game Bar, and it didn't work.

  • Personally I don't care about the extra hustle or download size with using NWjs.

    I care about performance, features and stability, if the end result is the same, then I don't think it's worth your or my effort.

  • 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

  • Aside for project including the NW.js, I guess that exported HTML5 projects via Construct 2 should work too. Is it correct?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)