ianfab
commented
3 months ago For me hosting it as a static website currently is the main use case. Of course having a proper offline GUI would also be very valuable. However, I think that for it to be a full-fledged GUI for end users it should be properly bundled, e.g., as an electron app, to hide all technicalities from the user. If it is possible to have both approaches maintained in a single repo without too much overhead, that is a serious consideration. Otherwise it probably is better to split the two projects, online playground and offline GUI and develop them separately.
Either way, my expertise in the two is very limited, so that is just my basic view on this. Furthermore, if this project will be extended more and more, and potentially even used as a basis for a local GUI, one should perhaps seriously consider changing the stack/framework, since the current approach simply was the easiest to start out as a lot of code was already there, but might not be very suitable for a larger project.
Most modern offline chess GUIs can load binary engines, while online websites uses WASM instead due to browser security restrictions. Fairyground can be either deployed online or offline, where offline versions can use Node.js as its backend to load binaries. But for online deployed versions like Vercel, this isn't possible. I made a simple try before #26 is merged --link, and it proved that engine loading function can work on offline versions (Tested on Windows Edge Browser). I don't know whether such functions that need a backend in order to work are suitable to be added to Fairyground, as users are unable to get a quick try on it from Vercel. If it is not suitable, I will no longer consider these features that require a backend.