HTML live preview, with no browser engine
Editora’s Markdown preview renders natively because I didn’t want to ship a browser engine. HTML is different, because the reason to preview HTML is to see it in a real browser, with that browser’s CSS, JS, and layout. So HTML live preview takes the opposite approach from Markdown and hands the page to a browser you already have. Editora’s part is to make that fast and live.
A tiny server, on loop-back
When you click the globe on an HTML file, Editora starts a small web server using
the JDK’s built-in HttpServer, bound to 127.0.0.1:0, which means loop-back only on a
random port, never the LAN. The file’s parent directory becomes the document
root, so its sibling CSS, JS, and images load exactly as they would when
deployed.
The previewed file itself is served from the editor’s in-memory text, not from disk. That’s why you don’t have to save to see changes.
A couple of safety details matter even for a localhost server: paths are checked against a traversal guard (you can’t escape the document root), and serving live buffer text means the preview always reflects exactly what’s on screen.
Live reload without WebSockets
The page finds out when to refresh by long polling, an old technique that needs no dependencies.
Editora splices a small <script> into the served HTML. On load, that script
hits a /__editora_livereload endpoint, and the server holds the request open
until a volatile long version counter changes (or ~25 seconds pass, then it
retries). Every debounced edit bumps that counter; the held request returns
200, and the script reloads the page.
There is no WebSocket library and no SSE plumbing, only a held HTTP request and a counter. A cached daemon thread pool backs it so those parked requests don’t starve normal asset serving.
The user’s browsers
“Open in a detected browser” means actually detecting them, per OS: macOS app
bundles (open -a), Linux binaries on PATH, Windows Program Files executables,
plus a System Default entry routed through JavaFX’s HostServices. The picker
even gives each browser its own icon. The detection and launch-argument logic is
pure and unit-tested, with the OS and filesystem probes injected, so it’s
testable without launching Chrome in CI.
Staying off the hot path
The whole feature is careful not to tax the editor. Live reload is one
volatile bump on the already-debounced 250 ms edit pulse, with no new
per-keystroke work. The server runs on its own daemon threads. The browser is
launched detached (fire-and-forget), so a slow-to-start browser can’t stall the
UI. And it’s all off by default, behind a Settings toggle, with the commands
filtered out of the palette when disabled.
Why not a WebView?
Because the browser you test in is the one that matters. A bundled WebView would be one more renderer that isn’t the one you test in, and it would mean shipping a browser engine inside a text editor, which Editora avoids. Serving to your real, installed browsers gets you accurate rendering, your devtools, and no extra download. The only thing Editora adds is the live-reload glue.
It’s a Beta feature today. Give it a try (enable it under Settings → HTML Preview) and let me know how it holds up in Discussions.
Update (October 2026). HTML live preview is no longer Beta and is now on by
default. The server has also changed since this post: the worker pool is a
fixed pool of 16 threads rather than a cached one, so held long-polls cannot
exhaust threads; each preview is served under a per-session URL prefix; and a
request whose Host header does not name the loopback listener is refused.