3 ms·

What feature is that?

arthurbrown 4mo ago
One form of JavaScript interop. Instead of being able to write bindings directly to native code, you had to pass messages through "ports" instead. https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826 Personally, I was sad to see signals and FRP go in 0.17 https://elm-lang.org/news/farewell-to-frp https://elm-lang.org/news/farewell-to-frp
wavemode 4mo ago
Lots of things were disallowed in 0.19, but probably the most disruptive were that custom native modules were disallowed (which basically means that, only certain official packages would now be allowed to directly call native JavaScript), and the package manager was locked down (which means that you can only install packages from the official elm repository, not GitHub or anywhere else). You can still indirectly call native JavaScript, in a message-passing kind of way (via Ports or custom elements) but these changes were still really disruptive to many codebases.
crote 4mo ago
On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossible! If I recall correctly something similar happened to other core libraries. This "nobody is allowed to do this until Evan himself has made time to come up with a blessed solution" style of development left a lot of people quite disappointed. Elm was marketed quite heavily as the best thing since sliced bread and the future of front-end web development, but in reality it turned out to be just Evan's toy language which you could look at but weren't allowed to touch. Which is of course allowed, but it does rapidly kill any kind of community around it. [0]: https://github.com/elm-lang/websocket https://github.com/elm-lang/websocket
- hombre_fatal 4mo ago
  This really overstates the problem and situation. Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop. But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port. It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference, but that's what happened. It's also a learning lesson for people who thought that a tiny, pre-v1.0 ecosystem that already had breaking changes would never break again especially in a way they disagree with. I think it's time to just accept the lesson.
  - crote 4mo ago
    I'm not mad, I'm disappointed. Elm was quite promising prior to this, but 0.19 essentially killed it. And the problem isn't just that sync interop was removed. That would've been fine. It's the double-whammy of 1) killing sync interop, 2) making async interop libs impossible, 3) still allowing it for "blessed" libraries, and 4) gaslighting everyone else that they were Holding It Wrong. Breakage is totally fine, I never expected anything different from Elm. But community-killing permanent core feature removal is a bit much, is it not? I luckily never invested too deeply into the ecosystem so there wasn't a lot dor me to "learn", but it sure ruined any chances of me - and with me I bet a lot of other people - ever looking at an Elm 1.0 or Elm++, and considering the valuable insights gained from TEA that really is a shame.
    - bmurphy1976 4mo ago
      Don't fret it. Many of us were in the same boat. Evan can do whatever he wants, but we can also call it out when it's wrong. I personally made the same decision. It became very clear to me that Elm was not the foundation for me to build a business on.
      - troupo 4mo ago
        > Evan can do whatever he wants, but we can also call it out when it's wrong. IIRC you couldn't, and would be banned on any channels for questioning decisions

One form of JavaScript interop. Instead of being able to write bindings directly to native code, you had to pass messages through "ports" instead. https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826 Personally, I was sad to see signals and FRP go in 0.17 https://elm-lang.org/news/farewell-to-frp https://elm-lang.org/news/farewell-to-frp

wavemode 4mo ago

Lots of things were disallowed in 0.19, but probably the most disruptive were that custom native modules were disallowed (which basically means that, only certain official packages would now be allowed to directly call native JavaScript), and the package manager was locked down (which means that you can only install packages from the official elm repository, not GitHub or anywhere else). You can still indirectly call native JavaScript, in a message-passing kind of way (via Ports or custom elements) but these changes were still really disruptive to many codebases.

crote 4mo ago

On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossible! If I recall correctly something similar happened to other core libraries. This "nobody is allowed to do this until Evan himself has made time to come up with a blessed solution" style of development left a lot of people quite disappointed. Elm was marketed quite heavily as the best thing since sliced bread and the future of front-end web development, but in reality it turned out to be just Evan's toy language which you could look at but weren't allowed to touch. Which is of course allowed, but it does rapidly kill any kind of community around it. [0]: https://github.com/elm-lang/websocket https://github.com/elm-lang/websocket

hombre_fatal 4mo ago
This really overstates the problem and situation. Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop. But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port. It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference, but that's what happened. It's also a learning lesson for people who thought that a tiny, pre-v1.0 ecosystem that already had breaking changes would never break again especially in a way they disagree with. I think it's time to just accept the lesson.
- crote 4mo ago
  I'm not mad, I'm disappointed. Elm was quite promising prior to this, but 0.19 essentially killed it. And the problem isn't just that sync interop was removed. That would've been fine. It's the double-whammy of 1) killing sync interop, 2) making async interop libs impossible, 3) still allowing it for "blessed" libraries, and 4) gaslighting everyone else that they were Holding It Wrong. Breakage is totally fine, I never expected anything different from Elm. But community-killing permanent core feature removal is a bit much, is it not? I luckily never invested too deeply into the ecosystem so there wasn't a lot dor me to "learn", but it sure ruined any chances of me - and with me I bet a lot of other people - ever looking at an Elm 1.0 or Elm++, and considering the valuable insights gained from TEA that really is a shame.
  - bmurphy1976 4mo ago
    Don't fret it. Many of us were in the same boat. Evan can do whatever he wants, but we can also call it out when it's wrong. I personally made the same decision. It became very clear to me that Elm was not the foundation for me to build a business on.
    - troupo 4mo ago
      > Evan can do whatever he wants, but we can also call it out when it's wrong. IIRC you couldn't, and would be banned on any channels for questioning decisions