For security reasons, browser-based VNC viewers are usually forbidden from making direct TCP connections, so they have to make WebSocket connections instead. That requires either a VNC server with WebSocket support (such as the TurboVNC Server, which does not run on Windows) or a WebSocket proxy (such as websockify, which also doesn’t run on Windows.) You could probably use websockify and noVNC (an HTML5 VNC viewer) to connect to the Vino server, but I don’t know how you would connect to the TightVNC server. (Maybe you could configure another websockify instance to forward noVNC connections to an RFB port on a different machine.) In either case, TurboVNC wouldn’t solve the problem for you. TurboVNC allows users to create and manage multiple virtual X servers under their accounts on a Un*x machine and to connect to those virtual X servers remotely, thus implementing a Un*x-based multi-user multi-session remote desktop solution. TurboVNC doesn’t support connecting to a physical X server. The TurboVNC Server integrates with noVNC, in the sense that it can optionally start a tiny web server that serves up noVNC on a particular port corresponding to the display number of a TurboVNC session, and it can print a noVNC URL specific to the TurboVNC session. However, integrating noVNC with any other VNC server is out of scope for this project.