This looks more difficult than I was thinking it might be.
It looks like I could maybe rewrite the networking code and UI code to actually work in a browser. The problem is that it seems that all the UI code might actually be embedded directly in the TADS game files themselves, not the interpreter. So it's not actually possible to change the UI code.
Even then, it might be possible to use service workers to actually serve the UI code from the game files to the browser. The TADS interpreter would run the game file in the service worker, allowing it to act as a network server/proxy. You could only play one game at a time probably (not have multiple instances in multiple windows), but I think it could work.
The problem is that the default UI code actually uses absolute file paths in the URL. As a result, the service worker would need to act as a proxy for an entire host to run the game file properly. Alternately, it could rewrite the UI code before it sends it to the browser, but that would require custom HTML parsing code. So then, the interpreter would not only need its own web server, it would needs its own web parser/browser as well to do a rewriting, which is starting to get mad crazy.
Since I doubt anyone wrote an alternative WebUI, it might be possible to just ignore the UI code in the TADS3 game files, and just serve a different UI (this would be just like the original option), but then you lose the ability to extend the UI in game files.
This looks more difficult than I was thinking it might be.
It looks like I could maybe rewrite the networking code and UI code to actually work in a browser. The problem is that it seems that all the UI code might actually be embedded directly in the TADS game files themselves, not the interpreter. So it's not actually possible to change the UI code.
Even then, it might be possible to use service workers to actually serve the UI code from the game files to the browser. The TADS interpreter would run the game file in the service worker, allowing it to act as a network server/proxy. You could only play one game at a time probably (not have multiple instances in multiple windows), but I think it could work.
The problem is that the default UI code actually uses absolute file paths in the URL. As a result, the service worker would need to act as a proxy for an entire host to run the game file properly. Alternately, it could rewrite the UI code before it sends it to the browser, but that would require custom HTML parsing code. So then, the interpreter would not only need its own web server, it would needs its own web parser/browser as well to do a rewriting, which is starting to get mad crazy.
Since I doubt anyone wrote an alternative WebUI, it might be possible to just ignore the UI code in the TADS3 game files, and just serve a different UI (this would be just like the original option), but then you lose the ability to extend the UI in game files.