Creating an API to be consumed by JS developers

[Dave Ford]

My experience with compile-to-js languages include: GWT, Dart and TypeScript.

GWT was very good at calling JS libraries. Almost zero friction. But not so, in the other direction. Creating API's to be consumed by JS was so ugly that I can confidently say that it was not worth it. Unless you are creating an API that has a very small surface area to functionality ration (like maybe a spell checker).

Dart has a similar story to GWT. 

By far the best inter-op story is TypeScript. If you write a lib in TypeScript it can be consumed by JS as-is. No special anything is needed. 

So my question is, where does Elm fall in this spectrum. Is it advisable to create an api in Elm to be consumed by JS developers?

[OvermindDL1]

The 'official' interaction between Elm and javascript is via ports, which involves marshelling any JSON-compatible type across the interface.  From the Javascript side it involves just 'send'ing something to somewhere (like via `Elm.MyApp.ports.someport.send("something");`) or to get data from Elm you 'subscribe' to it (such as in `Elm.MyApp.ports.someport.subscribe(function(msg){console.log(msg);})`).  It defines a specific interface for data to transfer over so everything on the Elm side can be 'safe' and any unsafe access happens only through know access points.

[Dave Ford]

That's pretty much how GWT was.

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/Rw3dPPgaRRI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[art yerkes]

Elm has very little friction when used as a library from javascript if your API can be expressed in terms of callback streams or promises, although it'll be necessary to write trivial wrapper code to do give it a nice API (for example, to match requests to responses when fulfilling promises).  

My website http://superheterodyne.net/ ( https://github.com/prozacchiwawa/superheterodyne ) uses elm to do fallback server side rendering via a port, and I've made some other experiments using elm code in a worker role to interact with javascript ( https://github.com/prozacchiwawa/elm-worker-runner-example , https://github.com/prozacchiwawa/elm-react-native-experiment ).  

Overall elm feels natural in this role.

Perhaps the most disappointing thing is the need to occasionally inject code into the generated javascript from elm.  Most commonly, something will link Html and need empty document and window vars in elm's closure to function.  I've experimented with using elm's Http in node on the server side and it works given the injection of https://github.com/driverdan/node-XMLHttpRequest as XMLHttpRequest , although you could make a port based abstraction that you could fulfill in different ways on node and in the browser that wouldn't involve modifying the generated javascript.

To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.