When I was broadcasting live tournaments through a JavaScript viewer I just configured the machine where the games were running as a web server. (I used the free Abyss web-server for Windows for that.) Then the viewer (for which the HTML and JS files were also on the machine) could directly access the game files. It was a bit of an annoyance that I could not put the viewer page itself on my regular web server, and have it sneakily retrieve the game file it needed from the machine where the game was running. But, like pgn4web says, JavaScript forbids this (for security reasons).
TLCV is complex. The original version is not browser-based, so you have to download a dedicated client. On the server side TLCS must run on the machine where you play the games, and it makes that machine a dedicated server for TLCV clients only. But once they connect it reverses the client-server relationship, and initiates connections to all logged-in clients whenever the game produced new data (moves or PVs). So users of TLCV have to rig their computer as a server, opening holes in all firewalls (including their modems and routers). Which is such a pain that many people never get it running.
There are several aspects of my old broadcasting system I consider unsatisfactory, and I am trying to find better solutions for. For independent reasons I developed a turn-based server as a CGI script, for which the JavaScript client also contains a viewer function (e.g.
http://hgm.nubati.net/variants/elven ), and where the normal web interface can deposit moves for adding to the game (using a HTML GET method). This can potentially be used for broadcasting, by letting the broadcasting entity deposit moves for both sides. I am thinking about equiping the turn-based server with real-time capability anyway, through 'long polling' (meaning that the CGI server script will not deny a request for a not-yet-existing move, but will wait for that move to be deposited and then satisfy the client request after all). That way the clients would be immediately informed of any deposited move.
I already built an undocumented feature into WinBoard to assist in depositing moves: rather then writing the debug information (containing all engine-GUI communication) on a file, you can also send it to another process through a pipe. At the other end of the pipe a broadcaster program could be waiting for input with an ordinary blocking read, and as soon as it arrives, pick out the stuff it wants to broadcast (e.g. the moves and the not-too-early PVs, and perhaps clock times), and immediately deposit it to a remote server through an URL request to the CGI script. I already made a trial version of such a broadcaster.