If this requires installing WebView2 on Windows, then I'd recommend against this approach. I did something similar myself (to avoid distributing a bloated Electron build), but, since the WebView2 installer sets its window title to "Microsoft Edge Update", I got a lot of negative feedback from a few very vocal Steam users who thought my game was trying to re-install Microsoft Edge--a browser they had meticulously removed all traces of. I think one Steam user even called my (free and open source) game "malware", just because of that window title (which only appeared on first run, when the WebView2 installer ran).
I'm sorry to say that if I had to do it again, I'd use Electron, despite the bloat. I bet Electron would also make distributing a Linux build easier, too. (WebView2 didn't work fullscreen on Proton when I last tested.)
Sorry to be a downer! Obviously, I originally loved this approach since I did something similar--it just didn't end up paying off. No one noticed that the download was ~100 MB lighter--but they sure noticed a brief flash of "Microsoft Edge" on their screen!
CommonGuy 1 hours ago [-]
This shouldn't be a problem with Windows 11 anymore? AFAIK, the "evergreen" version of WebView2 is installed by default.
datatraveler 50 minutes ago [-]
It might even be better than that. It sounds like Microsoft pushed WebView2 to (at least some) Windows 10 computers (N.B. Steam says 32% of users are still on Windows 10).
Of course, the docs still say:
> Even if your app uses the Evergreen distribution mode, we recommend that you distribute the WebView2 Runtime, to cover edge cases where the Runtime wasn't already installed.
I wish we knew how prevalent that situation was. Not sure what the failure mode would be. But it sure would be nice to be able to assume that a modern WebView always exists on Windows! That certainly wasn't the case back when I made my decision circa 2022.
flashgordon 1 hours ago [-]
Out of curiosity how do you feel about wasm? Reason I am asking is I've been doing something like this but using Go and phaserjs. I've found the experience pretty awesome and my main target was the web so didn't think beyond that. My choice was based on comfort with Go and a big frustration with the react eco system (also low expertise there).
Dang I am not sure why I was downvoted. But to your question I just used a basic MVP pattern where the Go side was pushed events from the browser and the game lib did the validation and called back methods on the browser to update the view state. So the browser side was very stateless for me. This made my testing a lot easier.
echelon 1 hours ago [-]
I wonder if Tauri is subject to this.
The sooner Tauri grows Electron/Chrome bundling capabilities, the better.
Chunky and predictable beats confusion, errors, and inconsistencies.
20after4 2 hours ago [-]
Is there really no way to get around the webview2 installer? Why not package it in your app bundle somehow instead of installing it as an external dependency?
magicalhippo 1 hours ago [-]
> Is there really no way to get around the webview2 installer?
WebView2 supports both the auto-updating "Evergreen" version and a fixed version[1]:
In the Fixed Version distribution mode, you control the timing of updates to the WebView2 Runtime for your app. You download a specific version of the WebView2 Runtime and then package it with your WebView2 app. The WebView2 Runtime on the client isn't automatically updated.
For me personally, I was trying to avoid bundling an entire browser runtime, so I viewed that approach (bundling WebView2's runtime instead of downloading on demand, only if needed) as no better than using Electron. At the time, that also wouldn't have solved my "Linux support" problem, but the blog post author is using webivew (which uses WebKitGTK on Linux), so that might not be relevant to them either. At which point I have nothing relevant to say!
skinnymuch 2 hours ago [-]
Hah that is so unfortunate when it’s so much nicer not to be using electron.
potatoman22 12 minutes ago [-]
I'm currently making a tycoon game with React, it's not bad for making some games. I use setInterval for a simple game loop along with a zustand store for the game logic. I'm keeping the game logic and state client-side for now, but I might move it over to a server in the future.
pjmlp 49 minutes ago [-]
I would rather use the user's installed browser, using Chrome Firefox, Safari as the game engine.
laurencerowe 2 hours ago [-]
This is cool but I don’t understand why they didn’t choose to make it a local first web app since nothing about it seems to require unrestricted local access.
It's SDL + WebGPU + Node. It doesn't give you a webview. It gives you (windows, input, audio, joypads) via SDL and graphics via WebGPU. I'd guess you can run three.js on it.
It's not looking super loved though but it does show a simple idea. Glue SDL and WebGPU (via dawn or wgpu) to pretty much any language and you get an environment to make portable apps.
esperent 2 hours ago [-]
> I'd guess you can run three.js on it.
I'm a bit out of the loop with three.js. How far along is their WebGPU renderer? Is it close to feature parity with the WebGL renderer?
matt3210 1 hours ago [-]
I saw Dino, which is a web technology, but I was very saddened that after trying to click components in every screenshot, non of them were web based and just screenshots :frowny-face:
zephraph 3 hours ago [-]
Pretty cool! While I was at Recurse I took a stab at building a library like webview client mentioned in the post. https://github.com/zephraph/webview. Deno was my first target. I really enjoy deno's tooling overall, it's nice to be able to just import a server script as a URL and limit its permissions.
Agentlien 1 hours ago [-]
This game is to Sim City what My Summer Car is to Need For Speed. That's delightful!
ranadomo 2 hours ago [-]
Fun game. Great work. I think schools are billed twice, once when you build and then again at the end of the month. Also there may be a bug with "lowest rent". It never seems to change and is higher than the "median rent".
Would also like to see more infrastructure like water and electricity. Any plans to open source parts of this?
tibu 2 hours ago [-]
It would be great to see a business model behind it too. You had to manufacture all the products in a factory and every product would be breaker down to the very basics. This was my idea for ages but never started to build it...
kamranjon 3 hours ago [-]
awesome! I have wanted to do something like this since the deno compile feature came out - great to see someone pulled it off, and last i checked the binaries were significantly less bulky than electron.
I'm sorry to say that if I had to do it again, I'd use Electron, despite the bloat. I bet Electron would also make distributing a Linux build easier, too. (WebView2 didn't work fullscreen on Proton when I last tested.)
Sorry to be a downer! Obviously, I originally loved this approach since I did something similar--it just didn't end up paying off. No one noticed that the download was ~100 MB lighter--but they sure noticed a brief flash of "Microsoft Edge" on their screen!
Of course, the docs still say:
> Even if your app uses the Evergreen distribution mode, we recommend that you distribute the WebView2 Runtime, to cover edge cases where the Runtime wasn't already installed.
https://learn.microsoft.com/en-us/microsoft-edge/webview2/co...
I wish we knew how prevalent that situation was. Not sure what the failure mode would be. But it sure would be nice to be able to assume that a modern WebView always exists on Windows! That certainly wasn't the case back when I made my decision circa 2022.
https://ebitengine.org/en/documents/webassembly.html
The sooner Tauri grows Electron/Chrome bundling capabilities, the better.
Chunky and predictable beats confusion, errors, and inconsistencies.
WebView2 supports both the auto-updating "Evergreen" version and a fixed version[1]:
In the Fixed Version distribution mode, you control the timing of updates to the WebView2 Runtime for your app. You download a specific version of the WebView2 Runtime and then package it with your WebView2 app. The WebView2 Runtime on the client isn't automatically updated.
[1]: https://learn.microsoft.com/en-us/microsoft-edge/webview2/co...
It's SDL + WebGPU + Node. It doesn't give you a webview. It gives you (windows, input, audio, joypads) via SDL and graphics via WebGPU. I'd guess you can run three.js on it.
It's not looking super loved though but it does show a simple idea. Glue SDL and WebGPU (via dawn or wgpu) to pretty much any language and you get an environment to make portable apps.
I'm a bit out of the loop with three.js. How far along is their WebGPU renderer? Is it close to feature parity with the WebGL renderer?
Would also like to see more infrastructure like water and electricity. Any plans to open source parts of this?