3 ms·
I once wrote a terminal-style interactive web app as a single chunked HTML page, because I couldn’t be bothered to implement a websocket endpoint. HTML and inli
by oefrha 2y ago
I once wrote a terminal-style interactive web app as a single chunked HTML page, because I couldn’t be bothered to implement a websocket endpoint. HTML and inline JS are interweaved and sent in reaction to user actions on the page. The only problem is browsers think the page never finishes loading.
- eastbound 2y agoCouldn’t you put the initial page in its own separate html, and load the rest as a long-running JS file using AJAX?
- oefrha 2y agoSure, but browsers don't do streaming execution of JavaScript (need to download the entire script), so you then need to manually stream the response and do HTML patching / eval chunked JS, as opposed to the browser trivially loading HTML / executing inline JS as the HTML page is streamed in all by itself. It does solve the loading spinner problem.
- lloeki 2y agoHa I'm curious now, did useragents eventually time out due to lack of interaction? If so, were you sending NOOP keepalives?
- oefrha 2y agoBrowsers don't time out ongoing requests once it's receiving the body (not sure if there's a maximum time for receiving all the headers). ISPs may drop idle connections after periods of inactivity, especially if they use CGNAT. Since my app runs on LAN, there's no such problem, I don't do any heartbeat and I often pick up right where I left off the previous day. Heartbeats are easy too if necessary: just send <!----> periodically.