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 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.
