Scope of rdkit-js?

[roccomoretti]

I'm curious about what the intended scope of rdkit-js is.

Right now it looks like the interface is rather minimal, mainly consisting of the ability to display molecules, do substructure matching and fingerprints, and some simple property calculations.

I'm wondering how deliberate that minimal scope is. Is the current functionality set merely a reflection of no one implementing the other functionality, or is there a (unwritten?) idea about what sort of functionality should be included and which is "too much"? (Realizing that the more functionality is added, the chunkier the wasm file gets.)

Is there any functionality in Python-level RDKit which would be vetoed for addition to the Javascript interface? And if so, is there anywhere where those distinctions are made explicit?

And were someone to need functionality which doesn't make the cut, what's the recommended approach for dealing with that?

[ptosco]

@roccomoretti The idea is to have a minimal, useful set of functionality that can be accessed from JS (and other languages through the CFFI interface). The original scope of MinimalLib was mostly centered around 2D molecule depiction, and the reason to keep the base functionality minimal is, as you say, to minimize download and initialization time of the WASM library.

That said, I have actually been exposing increasing chunks of functionality (e.g., reaction depiction, substructure search through the SubstructureLibrary and most recently MCS calculations. The idea is to make these "extra" bits of functionality optional, and allow users to opt them in at compilation time only if they need them and if they are willing to pay a small price in terms of download/initialization time.

This paradigm, while still under review, seems to me like a good compromise between having a lightweight library for general use and a heavier one for more advanced use cases.
Through this paradigm it would be possible to expose additional bits of useful functionality (e.g., atom/bond getters/setters, R group decomposition, etc.) without unnecessary bloating the base WASM (or CFFI) library if that functionality is not needed.
So far my main driver for exposing additional functionality has been the need for supporting novel web apps.

[greglandrum]

I agree with Paolo, but one additional factor that I think is important to keep in mind here is the support burden: every feature we expose does have an incremental support cost for us, that may be in terms of documentation, answering questions, fixing bugs, etc.