Migrate from ipywidgets to anywidget - #123
Conversation
`jupyter_rfb` is a simple widget in terms of its dependencies, but the ipywidgets packaging story forced a heavy build setup: webpack, node/yarn in CI, nbextension/labextension shared-data, and a `js/` directory of boilerplate. This also limited compatibility to platforms that supported the classic ipywidgets extension model. anywidget serves the ES module directly from a file path, which makes jupyter_rfb work anywhere anywidget does (JupyterLab, Notebook 7, Colab, VS Code, Marimo, etc.) without platform-specific packaging. As a side effect, all the bundling infrastructure goes away. The JS widget logic is preserved nearly verbatim. The main structural change is replacing `extends DOMWidgetModel`/`DOMWidgetView` with plain classes that proxy through the anywidget model, wrapped in an AFM factory export.
almarklein
left a comment
almarklein
left a comment
There was a problem hiding this comment.
Thanks a lot Trevor! I was planning on working on the AnyWidget support this week, so the planning is awesome 😉 🙏
I resolved the earlier CI error. I have a few small questions to help me understand how things work.
Another thing that I'd love to do is to embed a canvas on a 'static' webpage, so I can create a full screen widget in the browser to render to. Then serve that with a server like starlette to communicate with the server (where the rendering happens). Is this viable with AnyWidget? I saw some integrations for e.g. Svelte, but I prefer to go frameworkless. Or do you think its simpler to implement a websocket channel from scratch?
|
Hi @almarklein sorry for the radio silence on my end!
You could in theory write your own AFM host, backed by starlette and a websocket if you'd want to re-used the AFM. Shiny for Python also supports Jupyter widgets (and therefore anywidgts) but that might be a little overkill. I'd be happy to chat about the use case more. With the architecture above, I think you could roll something very barebones. |
I'll probably make an attempt soon. I'll cc you there 😉 |
|
I'm merging this. I've pending local changes to overhaul the whole thing. |
|
@manzt thank you for AnyWidget! The more I learn how it works, the more awesome I find it. ❤️ |
|
awesome work @manzt! thanks |
3 participants
There are cool projects that depend on
jupyter_rfb, but it's difficult to support them outside of JupyterLab/Notebook because they rely on traditional Jupyter widgets. I'm certain this project has already dealt with some of that platform complexity.These changes migrate to anywidget.
jupyter_rfbis a good candidate because its frontend only depends on@jupyter-widgets/base, which is what anywidget provides a protocol-based abstraction over. Thejs/build system is inherited from the ipywidgets cookiecutter and can be removed entirely in favor of a single_esmfile reference.With this change,
jupyter_rfbshould work in any environment anywidget supports, including marimo, Google Colab, and VS Code.I focused on minimizing the diff in
widget.jsto make it easy(er) to review. It could be restructured further separately.