Enabling static import into serverside code

[stevejpurves]

Problem

It is currently not possible to statically import ipywidgets into a platform like remix.run or next.js because of module side effects. The objective is not to enable SSR using jupyter widgets, but instead to reduce the friction of using them in frameworks that do SSR.

This is related to open issues in JupyterLab and Lumino here:

• Enable jupyterlab client packages to be imported in server side code jupyterlab/jupyterlab#13429
• Enable a lumino dependancies to be built in serverside only code jupyterlab/lumino#470

Proposed Solution

Bring in the change suggested in this comment:

ipywidgets/packages/base/src/nativeview.ts

Line 38 in 2af0cc4

const ElementProto: any = Element.prototype; // : typeof Element = (typeof Element !== 'undefined' && Element.prototype) || {};

and work though any implications of that.

[maartenbreddels]

The objective. is not the enable SSR using jupyter widgets

Our of curiosity, do you know what that would entail? I'm not sure of all SSR techniques, my guess is that using React, it's simply a different renderer right? But if we do DOM manipulation, that would be more challenging.

[stevejpurves]

@maartenbreddels yes, exactly. You're still rendering in React (or some framework) but are essentially rendering to a string. For react, I think it's basically the same renderer but only a single render pass occurs on the server (no side effects), then string is then sent to the client for "hydration" and smooth hydration is the trickier part.

For ipywidgets, maybe the valuable case for SSR would be something akin to serialized widget state and how the HTMLManager allows this to be "hydrated" on a standalone page without a kernel? -- if he initial html can be generated without the DOM proper.

[maartenbreddels]

Yes, thanks for confirming that. We are thinking about some form of SSR for https://github.com/widgetti/solara/ but we're not sure of the form yet. I was wondering if there may be SS dom implementations, but it seems most SSR methods avoid the DOM I guess.

[stevejpurves]

yes, the SSR i'm used to is about optimizing that initial page load and then deferring to post-hydration client side code to add interactivity.

Perhaps there is a special case around ipywidgets though, where something like jsdom can enable a static rendering of widgets (like the web examples & HTMLManager does for embedded state+view) to create that initial experience of having a bunch of widgets rendered and visible, then the trick would be how to transition from that html, to some level of immediate interactivity in on the page, like sliders working, jslnk working...