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. On Saturday, October 8, 2016 at 1:38:30 PM UTC-7, Dave Ford wrote: > > That's pretty much how GWT was. > > On Sat, Oct 8, 2016 at 1:34 PM, OvermindDL1 <[email protected] > <javascript:>> wrote: > >> 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. >> >> >> On Saturday, October 8, 2016 at 12:22:12 PM UTC-6, Dave Ford wrote: >>> >>> 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? >>> >> -- >> 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 >> [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
