EDIT: Rewrote to be more concise, despite being a wall of text still.
Is NWJS "fully" removed on r450?
If I save a project that has the NWJS plugin, then upgrade to r450, then preview, I see error along the lines of:
runtime.js:1 Uncaught (in promise) TypeError: this._runtime.IsNWjs is not a function
I presumed that NWJS was deprecated, so that you can still use your project with NWJS if you had the plugin added, but most stuff is "hidden away", so no exports and no adding the plugin. But judging by this, I take it that NWJS is removed from the core of C3 in whatever way C3 used to detect NWJS? This would mean all past projects with NWJS plugin cannot be run on r450 until it is removed?
I also presumed that we could still choose to use NWJS, but no support provided from Scirra, so we would be on our own to export via HTML5 and mash it together with NWJS if we wish, or if a new NWJS version broke the deprecated NWJS plugin, then Scirra won't support this.
If it is intended that existing projects with NWJS plugin must remove the plugin entirely to use their project:
This feels rough, my choice to use NWJS has backfired and stalled me. I abruptly need to remove NWJS plugin, which is deeply ingrained into my project. Maybe there were warnings (or maybe it is unintentional that projects are erroring), but oh mann I was eager to try the new Text improvements in r450 (which deeply affect my project when I unexpectedly encountered this when migrating my project to WebGPU-only effects. I had worked around it for a month or two, with poor results, but didn't want to pester Scirra, and assumed it was a Chrome bug, but then got excited to see the update).
Repeating what is known - WebView2 is not quite there yet. Very close but not equal to NWJS. Steam Overlay (fallback not ideal), supress the "fullscreen/Mouse pointer lock" popups. WebView2 feels more restrictive whereas NWJS feels more adaptable. I liked how C3 integrated fixed builds for NWJS, but WebView2 we must follow a guide externally. An advanced user may enjoy other aspects of NWJS, such as using Node Modules for further enhancement of their game (e.g. enabling Toast notifications on desktop).
NWJS's Steam Overlay relies on an experimental Chrome flag, a risk that some players cannot play or get crashes. Personally? No hesitation, I'd enable that flag, it's important for my case. I'd rather my game behave like a standard game and not split into many processes, I want Steam Overlay/Achievement popups, I want OBS to behave as it does with any other game that is a single-process (Yes you can still record a window, but, if there's a choice to make it consistent with how OBS detects other games, I'd choose that). I don't care for any performance/stability reasons to avoid that flag, it is an optional flag that we can choose to use, it works fine for most, but if it didn't, you can offer a 2nd build on Steam with the flag disabled. All doable with NWJS, but WebView2 prevents all of this, there is no choice, and that sucks bad.
I feel distrust towards WebView2 and slight distrust on following the Scirra path of EXE solution (again, only if this NWJS plugin issue was intentional and expects us to remove the plugin to preview our projects). Had I used Electron years ago, I wouldn't be suddenly panicked about what to do to update to the next beta. I'm thinking "what if" since this is now occurring: What if Scirra decide WebView2 is not the path to go with, due to slow rate of Microsoft response to WebView2 bugs/requests (such as the slow response to the "fullscreen" popups), or if Microsoft/Valve both say "No" to resolving the Steam Overlay issue and C3 cannot ever have Steam Overlay unless changing EXE solution - Some plausible situation like this happens, then Scirra move on to the next EXE solution, repeat this loop of killing projects until they remove the old plugin, etc. Such a time-sink for us trying to work on our games (and I empathise with the headache this causes Scirra to deal with). Where I mention distrust to Scirra's EXE solution, this means that I currently seek to find a way to continue using NWJS and am opposed to moving to WebView2, at least as of now. Still love practically every other decision Scirra makes, I am not going anywhere.
Another point of distrust to WebView2, was what we saw with WebView2 being cross-platform - a promise then a rejection, so it's not far-fetched to distrust the future of WebView2.
I also struggle to find "real-world" examples of WebView2 games on Steam, I think I encountered one months ago, but it's so rare to find, whereas NWJS has indeed had success out there with big named titles from RPG Maker and such. I can't peek at reviews to gauge what players experiences are like with WebView2, I can't Google info about it, it's way too new/experimental.
I think I've missed the point of why NWJS is no longer viable. It had been for years, since C2 days. I recall FileSize being the downside, but surly I am mistaken - FileSize matters for browser-based games, but rarely for Steam games.
I want to crack on and work on my game, but I'm rewriting stuff to fit in with SDKV1, WebGPU, and now WebView2. I'm happy to, and really try to recognise Scirra's goal and follow the philosophy. SDKV1 feels necessary, WebGPU provides a tangible benefit, but WebView2 is a downgrade as of now.
LTS will support NWJS still and have build server and presumably NWJS gets new versions added and bugs that arise will be fixed for LTS, the workload for Scirra still happens for the duration of LTS to support NWJS but the primary version of C3 won't benefit from this work.
I could use LTS version, it's a great addition, but what awful timing for my case with the WebGPU Text improvements, it's vital I can utilise that, especially after all the months of effort of mangling my project to not use WebGL effects.
Last lesser point, it feels antithetical for WebView2 to rely on C++ addons. I don't believe there's many addons for over a year, besides one companion addon? I imagine it's more difficult than the typical addon to create, and may have less chance of attracting community members with the skillset to make these. I'd have thought encouragement of Node.JS would be the path to promote - More JS shenanigans to mess with and unlock more power for desktop builds (not to mention the huge repo of nwjs modules that exist now).
The community has aided me to understand that, you can still use NWJS, just do it as JS event blocks. This is viable, but must I really have to re-interpret every NWJS action (as I made essentially full-use of NWJS plugin) into a JS event block/function, and figure out the more complex ones like loading into a Binary Data object (which again, heavily used in my case). Whyyy when it was working so fine just one version ago. :(
My apologies for the reactionary post. I fear the workload of having to move to FileSystem plugin, which may not be a simple swap-n-replace since NWJS was sync and FileSystem is async - And it feels like work that will just result in a downgraded end result when it comes to exporting.