# Better JavaScript API support? + Is it a good idea to create alternative DOM bindings?
**URL:** https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432
**Category:** Ecosystem
**Created:** [March 3, 2019, 8:02pm UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432 "2019-03-03T20:02:48Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@TheAspiringHacker](https://discuss.ocaml.org/u/TheAspiringHacker)
#### Post date: [March 3, 2019, 8:02pm UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432/1 "2019-03-03T20:02:48Z")
I’m currently using Js\_of\_ocaml to create an SVG-based web interface. I think that OCaml as a language is very enjoyable due to its type system, and I wouldn’t use JavaScript instead. I’ve also found Js\_of\_ocaml to work really well with Dune without me needing to get my hands dirty. However, I have been frustrated by the Js\_of\_ocaml API.
One major issue is the separation between the Dom\_html and Dom\_svg modules. They each define their own different types, such as (`Dom_html`|`Dom_svg`)`.element` and (`Dom_html`|`Dom_svg`)`.document`. In the case of element, I was able to work around the incompatibility by coercing to a common supertype. However, I just hit a roadblock because `Dom_svg.document` is not a supertype of `Dom_html.document`. `Dom_html.window`'s `document` attribute is of type `Dom_html.document`, and I cannot use it as a `Dom_svg.document.`
I feel the need to create my own DOM bindings from the ground up because I do not feel that I can work with Js\_of\_ocaml’s bindings. However, I do not want to further OCaml ecosystem fragmentation (repeating the “multiple standard library” issue). I also feel concerned about existing fragmentation in the OCaml-JavaScript sphere due to BuckleScript, which has yet another standard library extension and DOM API, and supports interop with NPM packages but not OCaml packages.
- Is it a good idea for me to create my own bindings and share them as a library?
- If so, may I solicit advice from other people to see how I may design the library to be useful for them?
- Would it be too ambitious to attempt to support both Js\_of\_ocaml and BuckleScript, to prevent fragmentation between compilers? The two compilers have different FFIs.
---
### Author:  [@Drup](https://discuss.ocaml.org/u/Drup)
#### Post date: [March 3, 2019, 8:23pm UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432/2 "2019-03-03T20:23:32Z")
What are you trying to do exactly, and why is js\_of\_ocaml’s API insufficient ? If you are looking mostly into building new elements (and making them change over time), then [tyxml](https://github.com/ocsigen/tyxml/) provides an alternative take that might be sufficient.
Note that unless you are writing an svg document with embedded javascript (and not an html document with pieces of svg in it), `Dom_svg.document` is probably not what you want.
---
### Author:  [@TheAspiringHacker](https://discuss.ocaml.org/u/TheAspiringHacker)
#### Post date: [March 3, 2019, 8:29pm UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432/3 "2019-03-03T20:29:21Z")
Thank you, I didn’t realize that `tyxml` existed,
The functions that create new SVG elements (`createG`, `createRect`, etc.) take `Dom_svg.document` as an argument. I cannot pass the document of an arbitrary window, as the `document` attribute of `Dom_html.window` is a `Dom_html.document` ([https://ocsigen.org/js\_of\_ocaml/3.1.0/api/Dom\_html.window-c](https://ocsigen.org/js_of_ocaml/3.1.0/api/Dom_html.window-c)). Is there a reason why there are two different types?
EDIT: I looked into `tyxml` and it seems that it is only for building XML documents? My use case involves heavy DOM manipulation of existing elements as well.
---
### Author:  [@TheAspiringHacker](https://discuss.ocaml.org/u/TheAspiringHacker)
#### Post date: [March 3, 2019, 11:46pm UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432/4 "2019-03-03T23:46:26Z")
Okay, I managed to use cppo to implement conditional compilation, so that different implementations of the same interface can be used with either Js\_of\_ocaml and BuckleScript. Is this a good idea? I have to think about it…
---
### Author:  [@TheAspiringHacker](https://discuss.ocaml.org/u/TheAspiringHacker)
#### Post date: [March 4, 2019, 3:23am UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432/5 "2019-03-04T03:23:45Z")
I tried making something that could work with both BuckleScript and Js\_of\_ocaml, but I found it infeasible because the two compilers handle things like objects differently in a way that I couldn’t abstract away. Js\_of\_ocaml’s bindings don’t always reflect the actual DOM API, but I think that I’d rather work around any rough edges than try to build an alternate bindings. I’d close this topic if I had the privileges.
EDIT: Although I couldn’t find it on MDN, it seems that document, when used with SVGs, does have a `rootElement` attribute, so having separate types is correct. The functions for creating SVG elements should then just take a `Dom.document` instead of `Dom_svg.document` so one can use it with `window##.document`. For the most part, it seems that Js\_of\_ocaml covers the DOM API, with a few rough edges with the types that I’m unfortunately hitting. I take back what I said before about wanting to create new bindings.
---
### Author:  [@yawaramin](https://discuss.ocaml.org/u/yawaramin)
#### Post date: [March 4, 2019, 4:30am UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432/6 "2019-03-04T04:30:46Z")
Out of curiosity–could you provide a small example of the difference in handling objects?
---
### Author:  [@TheAspiringHacker](https://discuss.ocaml.org/u/TheAspiringHacker)
#### Post date: [March 4, 2019, 4:39am UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432/7 "2019-03-04T04:39:49Z")
Sorry, I simply meant that the two compilers use different ways to map between JS objects and OCaml. Js\_of\_ocaml has `readonly_prop`, `writeonly_prop`, `prop`, and `meth`. Attribute and methods are accessed differently (`##.` vs `##`) and attributes are set with `:=`. BuckleScript separates const attributes, mutable attributes, and methods with `[@bs.set]` and `[@bs.meth]`. Both attributes and methods are accessed with `##`, and attributes are set with `#=`. I know that Js\_of\_ocaml uses a PPX, and I was unable to find out how BuckleScript handles its syntax. I simply decided that trying to be compatible across both compilers was infeasible.
---
### Author:  [@yawaramin](https://discuss.ocaml.org/u/yawaramin)
#### Post date: [March 4, 2019, 2:51pm UTC](https://discuss.ocaml.org/t/better-javascript-api-support-is-it-a-good-idea-to-create-alternative-dom-bindings/3432/8 "2019-03-04T14:51:35Z")
Ah, thank you for the explanation. Yeah I agree, you would have had to jump through a few hoops to abstract away all those differences.