[elm-discuss] Re: Creating an API to be consumed by JS developers
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Creating an API to be consumed by JS developers
That's pretty much how GWT was.
On Sat, Oct 8, 2016 at 1:34 PM, OvermindDL1 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
> elm-discuss+unsubscr...@googlegroups.com.
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Creating an API to be consumed by JS developers
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 > 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
>> elm-discuss...@googlegroups.com .
>> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
