Comms are indeed a thing, but I think the archival-grade HTML output is a more attainable baseline for something to work. Renderers, unless very carefully architected, won’t work outside of their “home” client, but rando comm things pretty much need to live within their client today.
I think a way forward here would be a JEP encouraging either the comm target_name to be a mimetype, or more backwards-compatible, adding a new field, and running more things through the mimerender detection pipe described above. For example, I’ve got this open PR (and a draft JEP) to enable wrapping the state of Language Server Protocol exchange. If there were an application/lsp+json (and a schema for it) it would be more straightforward, of course, but anything would be better than hand-waving. To that end, the LSIF protocol shows a nice path forward for at-rest interactive content, which we’d also like to support. If a non-browser client (or, at worst a headless browser) was able to excite the comm target during execution, and this could be intercepted and stored, statically-hosted documentation sites would have a path forward to maintaining at least an “on the garden path” set of excursions, at the expense of a heavier deployment payload.
realtime apps with Dash
Much like Bokeh, I do not foresee any plotly/dash stuff becoming a first-class and -party tool supported by the Jupyter protocols, specs, and clients… but maybe that’s just me. However, once voila has adopted federated modules, I very much see the prospect of having fully-statically-hosted, nicely customizable apps, similar to the jyve experiments, built out of Jupyter widgets.