Hi. First of all, thanks for your work on those bindings, it is much appreciated!

Assigning a value to a conditionally chained field actually hits you with aSyntaxError: Left side of assignment is not a reference, which means the JS we're benchmarking against looks more like this:

consth2=document.querySelector("h2");if(h2){h2.style.color="red";}

Still very succinct for sure, but a fairer comparison.

The current version of @rescript/webapi provides anasHtmlElement utility in theWebapi__Dom__Element module which returns an option (Seehere). I think your approach withtryParse from theHTMLHeadingElement side makes more sense. Not sure about the name (fromInstance?).

In any case, I'm not sure this function would fit in this library. I like the idea of having zero-cost bindings available and maybe a utility library on the side. The question then becomes: should @rescript/webapi be the zero-cost bindings library, with something like @rescript/webapi-utils for utilities and a more idomatic API, of instead be the accessible default while @rescript/webapi-raw provides the zero-cost version for those who want it?

If we suppose the utility library also wraps all nullables with options, we could dream of something like:

openWrappedWebAPIGlobal.document->Document.querySelector("h2")->Option.flatMap(HTMLElement.tryParse)->Option.forEach(h2=> {h2.style.color="red"})

which is still quite verbose but doesn't feel too bad to me.

Hello, thank you for your recent PRs and sharing your thoughts on this.
I think it make sense to keep@rescript/webapi a zero-cost bindings only package.
Something like@rescript/webapi-utils might fit the bill better. (Although, I don't like that exact name).

It also makes wonder if we should not go for a workspace approach with multiple packages.
Extract some parts of the current package into new packages to keep@rescript/webapi a bit more lightweight.