3 ms·
The problem I see is that many websites that rely heavily on JS have become pretty much applications rather than websites and as a result they heavily rely on a
by mr__y 7y ago
The problem I see is that many websites that rely heavily on JS have become pretty much applications rather than websites and as a result they heavily rely on a long running process. The way I understand this problem, this would rather require a long running browser process and (socket based) API exposed for external commands/apps to work with. But then again this would be not much different than Selenium or the likes. The API could be very different but the general principle (web browser process and an API for external applications to control it) would be the same.
- dllthomas 7y agoYeah, I think that's about the shape of it. And I think it's something we don't currently have a good, well established pattern for. It calls for something more localized than a daemon, but longer lived than a utility. We see something similar with language servers. In that case (IIUC, and I may not) they're typically tied to specific places in the directory structure (eg. listening on a unix socket created in the root of the relevant source tree). For the chat client I mentioned above, I tied things together with shell and environment variables. The script to start the long-running process read its initial output and set things up so that future commands would know which process to talk to. The code is at https://github.com/dlthomas/genies https://github.com/dlthomas/genies