7 ms·

> remove escape hatches needed to fill out the immaturity of the language I think you mean "immaturity of the platform". Also, native modules weren't the only

> remove escape hatches needed to fill out the immaturity of the language I think you mean "immaturity of the platform". Also, native modules weren't the only "escape hatch". An Elm application can communicate with JS through ports.

k__ 8y ago
Complicated interop with JS also broke Darts back.
- pjmlp 8y ago
  Politics broke Dart's back.
  - k__ 8y ago
    Sure, the bad JS interop had to come from somewhere.
AlexCoventry 8y ago
What was the capability of native modules which enabled the dev.to essayist to use them, where ports would have been unreasonable ("there is no other reasonable way to do what I need")?
- always_good 8y ago
  Ports are an asynchronous interop boundary. You basically subscribe to a port from Javascript and attach a callback to handle data as it passes from Elm -> JS. Javascript errors then are relegated outside of Elm or they fail at the boundary (like serialization errors when passing data from JS to an Elm port). They're kept outside of Elm. Native modules, on the other hand, let you create Elm functions that synchronously call Javascript. That means that what look like regular Elm functions can now synchronously blow up at callsite inside Elm. The first native modules I saw in the wild as a beginner were people making shortcut functions for things like `Math.random()` instead of the proper way of threading a random seed into the entry point and keeping it in the model which has various benefits. Same with quick access to "Date.now()". From this perspective, you can see why native module access was removed, and especially why you needed permission to publish a native module Elm's package repo. Native modules are tempting because they are easy, but widespread use eliminates one of the major upsides of Elm: no runtime errors inside Elm, or rather the ability to boundary them. However, some forms of JS interop are hard or impossible without synchronous FFI, 1:1 JS library wrapping being the most obvious example. Having to use asynchronous ports for that is like wrapping a Javascript library's sync functions with an EventEmitter. You emit an event and then listen for the resulting event. Maybe you even decide to pass in a messageId echo for request/response reconciliation (I've seen people build this abstraction around Elm's ports!). On one hand, a lot of people have the idea that because they are using Elm, they shouldn't have to write any Javascript at all. After all, this is what many compile-to-JS languages give you. And on the other hand, no more synchronous FFI means that some Elm apps that exist today cannot move ahead, and some people think the approach is too heavy-handed or they disagree with the direction. In my experience, Elm is best seen as a way to build a functional core that you wire up to an external world of Javascript. For example, a game simulation that emits game states over a port, and you write Javascript to render those updates with a JS library like Pixi.js, resisting the temptation to wrap Pixi.js in Elm and calling it from Elm.
  - heavenlyhash 8y ago
    > you needed permission to publish a native module Elm's package repo. See, this, to me, sounds quite reasonable. A feature is potentially dangerous to the rest of the ecosystem if encountered unexpectedly: therefore, we put some extra friction on sharing code which uses those features, and made it an obvious and opt-in process if you wished to take that potential danger into your project. Great! Given that... why on earth would it be necessary to remove the feature from the language entirely?
    - oomem 8y ago
      You can find some explanations by the language author here: https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826
- loevborg 8y ago
  Check out this comment for an explanation of why Ports cannot possibly cover all use cases: https://www.reddit.com/r/elm/comments/99bzf8/elm_or_reasonml_with_reasonreact/e4n83jk/?context=3 https://www.reddit.com/r/elm/comments/99bzf8/elm_or_reasonml...
  - big_elephant 8y ago
    hm i'm not sure why ports would not work in that use case (the keycloak one, right?). the port would be how you communicate between js and elm, so it looks like inside the js callbacks is where you would `send` that data through the port to elm
    - loevborg 8y ago
      Agreed, it could work with Keycloak, or other 3rd party libraries, depending on the amount of collaboration between JS and Elm. My point was that some things that are simple when you can pass around promises suddenly get very complicated when all you have is ports and messages.
    - AlexCoventry 8y ago
      I came across an example which makes using ports sound a bit tedious (but suggests an alternative.) It's at the start of this talk: https://www.youtube.com/watch?v=tyFe9Pw6TVE https://www.youtube.com/watch?v=tyFe9Pw6TVE
      - big_elephant 8y ago
        excellent video, thanks. custom elements are a very interesting alternative

k__ 8y ago

Complicated interop with JS also broke Darts back.

pjmlp 8y ago
Politics broke Dart's back.
- k__ 8y ago
  Sure, the bad JS interop had to come from somewhere.

AlexCoventry 8y ago

What was the capability of native modules which enabled the dev.to essayist to use them, where ports would have been unreasonable ("there is no other reasonable way to do what I need")?

always_good 8y ago
Ports are an asynchronous interop boundary. You basically subscribe to a port from Javascript and attach a callback to handle data as it passes from Elm -> JS. Javascript errors then are relegated outside of Elm or they fail at the boundary (like serialization errors when passing data from JS to an Elm port). They're kept outside of Elm. Native modules, on the other hand, let you create Elm functions that synchronously call Javascript. That means that what look like regular Elm functions can now synchronously blow up at callsite inside Elm. The first native modules I saw in the wild as a beginner were people making shortcut functions for things like `Math.random()` instead of the proper way of threading a random seed into the entry point and keeping it in the model which has various benefits. Same with quick access to "Date.now()". From this perspective, you can see why native module access was removed, and especially why you needed permission to publish a native module Elm's package repo. Native modules are tempting because they are easy, but widespread use eliminates one of the major upsides of Elm: no runtime errors inside Elm, or rather the ability to boundary them. However, some forms of JS interop are hard or impossible without synchronous FFI, 1:1 JS library wrapping being the most obvious example. Having to use asynchronous ports for that is like wrapping a Javascript library's sync functions with an EventEmitter. You emit an event and then listen for the resulting event. Maybe you even decide to pass in a messageId echo for request/response reconciliation (I've seen people build this abstraction around Elm's ports!). On one hand, a lot of people have the idea that because they are using Elm, they shouldn't have to write any Javascript at all. After all, this is what many compile-to-JS languages give you. And on the other hand, no more synchronous FFI means that some Elm apps that exist today cannot move ahead, and some people think the approach is too heavy-handed or they disagree with the direction. In my experience, Elm is best seen as a way to build a functional core that you wire up to an external world of Javascript. For example, a game simulation that emits game states over a port, and you write Javascript to render those updates with a JS library like Pixi.js, resisting the temptation to wrap Pixi.js in Elm and calling it from Elm.
- heavenlyhash 8y ago
  > you needed permission to publish a native module Elm's package repo. See, this, to me, sounds quite reasonable. A feature is potentially dangerous to the rest of the ecosystem if encountered unexpectedly: therefore, we put some extra friction on sharing code which uses those features, and made it an obvious and opt-in process if you wished to take that potential danger into your project. Great! Given that... why on earth would it be necessary to remove the feature from the language entirely?
  - oomem 8y ago
    You can find some explanations by the language author here: https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826
loevborg 8y ago
Check out this comment for an explanation of why Ports cannot possibly cover all use cases: https://www.reddit.com/r/elm/comments/99bzf8/elm_or_reasonml_with_reasonreact/e4n83jk/?context=3 https://www.reddit.com/r/elm/comments/99bzf8/elm_or_reasonml...
- big_elephant 8y ago
  hm i'm not sure why ports would not work in that use case (the keycloak one, right?). the port would be how you communicate between js and elm, so it looks like inside the js callbacks is where you would `send` that data through the port to elm
  - loevborg 8y ago
    Agreed, it could work with Keycloak, or other 3rd party libraries, depending on the amount of collaboration between JS and Elm. My point was that some things that are simple when you can pass around promises suddenly get very complicated when all you have is ports and messages.
  - AlexCoventry 8y ago
    I came across an example which makes using ports sound a bit tedious (but suggests an alternative.) It's at the start of this talk: https://www.youtube.com/watch?v=tyFe9Pw6TVE https://www.youtube.com/watch?v=tyFe9Pw6TVE
    - big_elephant 8y ago
      excellent video, thanks. custom elements are a very interesting alternative