Is there any disadvantage to ReactiveHTML?

Panel
1

I have been using the ReactiveHTML class to successfully wrap a number of very nice JavaScript UI elements from the w2ui library. I’ve implemented a tree sidebar, tabs, resizable layouts, and toolbars this way. So far so good! What I’m wondering is this: is there any disadvantage in using ReactiveHTML relative to, say, implementing a custom Bokeh model? Is there any power that I’m giving up by not integrating more closely with Bokeh? So far I haven’t run into anything that I couldn’t do, but I have run into a few things that I couldn’t do easily although I ended up being able to do them eventually. Just curious about people’s perspectives on this.

1 Like
2

There are some downsides but until you experience them there is no reason to change anything.

For example

  • Bokeh Models are developed with npm, typescript and other frontend frameworks. That can be an advantage if you have experience with that. If not its a disadvantage.
  • ReactiveHTML elements might have some performance penalty over Bokeh Models. But I have not experienced any so far.

In my experience ReactiveHTML elements are simpler to maintain as the api changes less frequently. In my experience each Bokeh minor version leads to maintenance of Bokeh models while ReactiveHTML elements will continue working.

If you can share some of your custom components please do. Thanks.

3

@Marc thanks for your reply. Do you know any details regarding the performance penalty? I haven’t done any comparisons but I assume the way it works is pretty much the same (communication over websockets) so I wonder where there might be a difference, if any.

I would definitely like to share the custom components I made. The issue I have with ReactiveHTML is that the scripting logic (namely, the glue that maps the elements in _scripts to actual scripts on the JavaScript side) is not very ergonomic to use. Out-of-the-box it requires you to write JS in a text block in a Python script, which is not nice. I did some additional work to load the scripts from file; this works well but it means that there are additional moving parts. I’ll see if I can pull some of those pieces out into a separate mini-project and share that work as a repo.

1 Like
4

The performance penalty is only the loading of the javascript you write. It might be slower or faster I don’t know.

Regarding not nice to write js in a python text file. It is on the roadmap for Panel 1.5 to modernize ReactiveHTML. It will be a new base class used in another way. I believe the implementation is there. It now needs testing and documentation. See Add support for ESM bundle on ReactiveHTML #5593.

5

Thanks, I was not aware of this work but that’s definitely the kind of thing I had in mind. It would be a huge improvement and I’m looking forward to it. Right now we’re implementing a similar sort of functionality ourselves.