The tl;dr for those unfamiliar with the situation:
In Elm, there is no FFI. Instead, you can communicate with Javascript through the use of a pub/sub system similar to making requests to an external server, known as ports.
The user in question was using an intentionally undocumented underyling system to write JS code that isn’t type-checked
In the next release of 0.19, the way this system works is changed, and restricted further. This leads user to be concerned about their continued use of Elm
Mayve it’s just not clear to me, but is there an actual problem here, or just “I can’t do it exactly how I want to so I’m going to stomp my feet and threaten to leave”?
Does the OP want something that would circumvent all of the static benefits of using Elm? Is the message passing system inadequate?
I believe the actual problem is a communication problem: the user has read some bit and pieces, and started to be concerned about the way they are currently using Elm might not work going forward. That’s a very legitimate concern to have! However, based on what they said, their problem is actually completely solvable right now in Elm without the method they used to bypass Elm’s safety, via ports. Also, the undocumented API they used (“Native” code) led to this situation.
Does the OP want something that would circumvent all of the static benefits of using Elm?
My understanding is yes, that’s what they want: but in standard XY problem fashion, the real concern they have is becoming blocked by upstream bug fixes not being merged as often as they’d like. This is something we’re actively looking into improving in Elm going forward.
Is the message passing system inadequate?
There are some aspects of it which are inadequate, for sure. Ports require that all the code that use them be async in both Elm and JS. This can be a problem if you need sync code in your view function, for example. However, that’s entirely possible to work around.
Last I checked the creator of Elm literally did not allow any libraries to be published to the central repository without his personal approval if they used the JS interop system.
While technically true, this doesn’t really paint the whole picture.
You can publish any Elm part of a package that uses ports. What you can’t do is publish the ports exposed themselves. There’s a good reason for that: to avoid name collisions on ports. So, what you do is:
Publish the Elm parts as a package.
Publish the JS parts as a package.
Instruct on how to connect the two.
It’s straight-forward to do things in this manner.
Thanks for the context. While I still think it’s problematic from a social perspective to have a benevolent dictator who acts as a personal gatekeeper for what is and isn’t allowed to be published, from a technical perspective it doesn’t seem so bad.
The message passing system is absolutely inadequate for some things (e.g., for replacing Math library functions, or for, as in this case, replacing the native websocket module). These can not be implemented async, and therefore not with ports.
See this quote from the author:
We also have some synchronous functions JS functions that we need to call that we will not rewrite in Elm. Sorry but we can’t upgrade to the official 0.19.
For these things, you need to use JS to do it yourself, and in the latest version, there’s a whitelist restricting which people can create such JS modules. This whitelist is restricted to the elm team.
As result, people are considering forking the compiler, or moving away entirely.
This is not accurate: ports are perfect for replacing the websocket module. The reason why the original poster mentioned websockets is because they wanted to patch the library themselves. However, using ports instead would’ve worked just fine. That’s how the existing library is modelled, after all.
If what I’ve read is correct, we won’t be able to switch to Elm 0.19 until Evan decides to merge those changes, which might take years judging from the fact that there has been no official reply to any PRs of that package that have been open since 2 years (https://github.com/elm-lang/websocket/pull/12).
It’s basically out of their hands as a user who didn’t create and doesn’t maintain the extension that their production app came to rely on so they’re already using a fork. That situation was not ideal but they had an easy path forward with the fork. They are now worried that that easy path forward has come to a dead end because the original package doesn’t seem to be maintained well enough for them to think that this will be remedied soon and they will have to do a lot of work, one way or another, to upgrade Elm ≥ 0.19. It might be an amount of work that their team will just port the app to something else entirely.
There are libraries like elm-websockets the OP had to fork and use their forked version because their bug fix PRs have not been merged in 2 years. So the issue of not having releases for years (instead working on the next major release only it seems) and now planning to even disallow this work around for the lack of releases.
After looking for pro/cons in Elm and ReamsonML, my final point was that although Elm has a great pattern and offer simplicity, the interop with JS to import any external library is not fitting the need that I have.
If I ever need to write apps without JS interoperability, then elm would be great, but for now, the ecosystem not here yet.
It’s not really that odd, when it fits into the Elm model of the world: I suggest listening to this podcast, which goes over why things in Elm are the way they are: https://elmtown.audio/99e18f41
I think the vision put forth by Evan sounds like a great thing to strive for. However, as he says, these things are going to take years to happen.
I think we are seeing the tension between building out this grand vision were everything has an ideal interface, and people using it to ship features today. It seems that recently, there has been more and more negative chatter about the limitations and issues of the language around this tension.
Not having small patches to fix things like the issue mentioned in the linked post is probably one of larger concerns. Users of the language can make a hotfix and push it to prod in minutes, but issues in language aren’t patched for a year. I know these aren’t the same thing, and actually doing things are never as easy as they sound, but this seems to be where the creator and user are at odds.
I think we are seeing the tension between building out this grand vision were everything has an ideal interface, and people using it to ship features today. It seems that recently, there has been more and more negative chatter about the limitations and issues of the language around this tension.
I think it’s OK, and even a good thing, if the power users of a language or library or whatever are persistently frustrated by the thing, if it means a stronger and more consistent story for new and intermediate users. They’re by far the larger and more important demographic. I don’t know a lot about Elm but I get the sense that this is the case.
Oh, certainly. Even having the userbase around to have these frustrations is a good thing.
It seems there are some growing pains going from a toy language no one really uses, to one that companies are built on. I guess we have yet to see how these concerns are handled.
The tl;dr for those unfamiliar with the situation:
Mayve it’s just not clear to me, but is there an actual problem here, or just “I can’t do it exactly how I want to so I’m going to stomp my feet and threaten to leave”?
Does the OP want something that would circumvent all of the static benefits of using Elm? Is the message passing system inadequate?
I believe the actual problem is a communication problem: the user has read some bit and pieces, and started to be concerned about the way they are currently using Elm might not work going forward. That’s a very legitimate concern to have! However, based on what they said, their problem is actually completely solvable right now in Elm without the method they used to bypass Elm’s safety, via ports. Also, the undocumented API they used (“Native” code) led to this situation.
My understanding is yes, that’s what they want: but in standard XY problem fashion, the real concern they have is becoming blocked by upstream bug fixes not being merged as often as they’d like. This is something we’re actively looking into improving in Elm going forward.
There are some aspects of it which are inadequate, for sure. Ports require that all the code that use them be async in both Elm and JS. This can be a problem if you need sync code in your view function, for example. However, that’s entirely possible to work around.
Last I checked the creator of Elm literally did not allow any libraries to be published to the central repository without his personal approval if they used the JS interop system.
While technically true, this doesn’t really paint the whole picture.
You can publish any Elm part of a package that uses ports. What you can’t do is publish the ports exposed themselves. There’s a good reason for that: to avoid name collisions on ports. So, what you do is:
It’s straight-forward to do things in this manner.
Thanks for the context. While I still think it’s problematic from a social perspective to have a benevolent dictator who acts as a personal gatekeeper for what is and isn’t allowed to be published, from a technical perspective it doesn’t seem so bad.
The message passing system is absolutely inadequate for some things (e.g., for replacing Math library functions, or for, as in this case, replacing the native websocket module). These can not be implemented async, and therefore not with ports.
See this quote from the author:
For these things, you need to use JS to do it yourself, and in the latest version, there’s a whitelist restricting which people can create such JS modules. This whitelist is restricted to the elm team.
As result, people are considering forking the compiler, or moving away entirely.
This is not accurate: ports are perfect for replacing the websocket module. The reason why the original poster mentioned websockets is because they wanted to patch the library themselves. However, using ports instead would’ve worked just fine. That’s how the existing library is modelled, after all.
Here is the exact reason the user expressed as to why they’ll have to use a fork of either Elm or rewrite the extension they rely on:
It’s basically out of their hands as a user who didn’t create and doesn’t maintain the extension that their production app came to rely on so they’re already using a fork. That situation was not ideal but they had an easy path forward with the fork. They are now worried that that easy path forward has come to a dead end because the original package doesn’t seem to be maintained well enough for them to think that this will be remedied soon and they will have to do a lot of work, one way or another, to upgrade Elm ≥ 0.19. It might be an amount of work that their team will just port the app to something else entirely.
There are libraries like elm-websockets the OP had to fork and use their forked version because their bug fix PRs have not been merged in 2 years. So the issue of not having releases for years (instead working on the next major release only it seems) and now planning to even disallow this work around for the lack of releases.
After looking for pro/cons in Elm and ReamsonML, my final point was that although Elm has a great pattern and offer simplicity, the interop with JS to import any external library is not fitting the need that I have.
If I ever need to write apps without JS interoperability, then elm would be great, but for now, the ecosystem not here yet.
I find this odd given that Elm targets browsers. It’s a bit like creating a native language and say: we don’t need C FFI, people can use named pipes.
It’s not really that odd, when it fits into the Elm model of the world: I suggest listening to this podcast, which goes over why things in Elm are the way they are: https://elmtown.audio/99e18f41
I think the vision put forth by Evan sounds like a great thing to strive for. However, as he says, these things are going to take years to happen.
I think we are seeing the tension between building out this grand vision were everything has an ideal interface, and people using it to ship features today. It seems that recently, there has been more and more negative chatter about the limitations and issues of the language around this tension.
Not having small patches to fix things like the issue mentioned in the linked post is probably one of larger concerns. Users of the language can make a hotfix and push it to prod in minutes, but issues in language aren’t patched for a year. I know these aren’t the same thing, and actually doing things are never as easy as they sound, but this seems to be where the creator and user are at odds.
I think it’s OK, and even a good thing, if the power users of a language or library or whatever are persistently frustrated by the thing, if it means a stronger and more consistent story for new and intermediate users. They’re by far the larger and more important demographic. I don’t know a lot about Elm but I get the sense that this is the case.
Oh, certainly. Even having the userbase around to have these frustrations is a good thing.
It seems there are some growing pains going from a toy language no one really uses, to one that companies are built on. I guess we have yet to see how these concerns are handled.