It's not clear to me if they used Electron's Node backend for much more than it's File API. If that's the case, they might have been better off just using a QT webview (e.g. pywebview) for the sake of performance (which they cite as reason for moving from NW.js/Electron).
I'm not very familiar with Qt or Qt webview but from their documentation it states:
> This version of Qt WebEngine is based on Chromium version 73.0.3683, with additional security fixes from newer versions.
Assuming they both have a full Chromium embed, would there have been better performance? I assume the developers are mostly JavaScript devs so their choice to use Electron/Node makes sense.
Most folks complaint with Electron isn't that it isn't performative, but rather that it is bloated (you ship an entire browser when all you needed was eg the canvas and v8 engine).
In all fairness, are you aware of a tool for web developers that only ships the canvas and v8 engine? Legitimately curious, because I've tried looking in the past for similar reasons (game dev on an engine I already know) and came up empty-handed.
It's not finished yet but you can get close to 20M mem usage + overhead of your libs & assets. Executable size is node.js + 2M (30M total IIRC and it compresses nicely to ~10M *.dmg because node contains a lot of strings)
Please file an issue if you want it to happen so that it can be tracked how many people want it too (I had no idea that this is a thing in gaming community). It's now at the bottom of my priorities (I'm working on raspi support so that it can run as smartmirror) but it's not that hard to add so it could actually happen.
I added a watch to it and starred; I think it'd be a good idea to be more clear with what's being built in the README.md because I wouldn't have thought that this was a stripped-down browser based on the headline. As well, it's difficult to see exactly what you are getting from graffiti (is it just canvas, does it include DOM stuff) at a glance which may turn away those browsing repos.
Agreed that README is very unclear - it's not a browser at all, actually. It's just a GUI library for rust & node.js which happens to have little DOM-like layer.
This pseudo-DOM is really just enough to make web frameworks work. I want to do GUI apps with the same tools & libs which I use for web development but I don't want to include the whole browser and moreover I want it to be enough resource-savvy so that it can run on my raspi attached to the TV.
It's hard to describe what it is good for because there are many use-cases. It's really rather a platform just like Electron or Qt is, but of course it's very limited now. But really, if you or anybode else have better headline, I'd love to hear it.
Just in case you are not being facetious: totally agreed; but in the case of delivering a game on platforms that include Steam, and also for perception reasons, not really an option.
This would be great, if only... Realistically, I just want a canvas with some audio/input stuff in most cases (though being able to put some divs in places may be nice for rendering things like menus).
I looked a bit a few months ago. There are some interesting things out there. But you will probably be a bit on your own (but not uncommon when it comes to game dev though!)
They tend to use ~10x the memory that seems reasonable—generous, even—for what they're doing, and periodically misbehave and decide to eat tons of cycles continuously for no obvious reason, in a way native apps don't, or at least not so frequently and nigh-universally.
Sure, partial counterexample in VSCode, but then there's all the others.
I agree with what you are saying with regards to the tendency of the platform. But, aside from the weight of unnecessary/unused browser features, I think that has more to do with the needs of the developers attracted to the platform more than the platform itself.
"The needs" being a requirement to ship a MVP ASAP using developers that can agree on a lowest common denominator language of js.
Except for then you have to deal with whatever version of embedded Internet Explorer .NET uses. Maybe the UWP solution uses Edge now, but that still isn’t wonderful compared with embedding Chromium.
Usually in .NET you typically get IE, not Edge. People have been using CefSharp as a replacement. A number of software I have contributed to have done this.
In contrast, UWP applications do use the Edge rendering engine, and while it may or may not be possible to use CEF in these applications, you won't be able to get it certified by Microsoft, therefore no one, at least to my research, has bothered doing so.
I wonder what the future brings with Edge now just being chromium based
Most websites don't run well on even high end hardware. There's most certainly a performance tradeoff using a browser, especially for something as performance sensitive as a game.
