I am new to elm and recently consider for the first time to use elm on a client project. I know elm for about 6 months and I can say I love the language and the developing on elm has always been a pleasure. But as I am working with phoenix and phoenix channels in my projects before making my decision I took a look on the packages that I might be needing to come through with the project. One of the packages that I am interested in is websockets. I found a lot of conversations on the topic and figure out that there is a probable workaround through ports(for elm 0.19) that looks like it’s working for most of the elm developers. Not having a native elm solution for websockets in elm 0.19 is not the end of the world for me especially if there is a straight forward workaround, but what bugs me is that I can see posts from more than a year ago stating that the package is under development and will be released at some point and now more than a year later I can’t find any post stating what is the status, are they still work in progress are they canceled for version 0.19 and it looks like nobody has an answer for that. I would love to hear how you feel about inconsistencies like that because as much as I would like to start using elm with my clients I kind of feel like the way I felt when back in the university I used a library a friend has developed and at some point he just decided half of the anticipated functionality wont be there because it’s not so exciting enough for him. This is not a hate message but I want to hear how all of you that use elm in production handle this kind of behavior and how you feel about it? Because I feel as if I am missing the point here and nobody else seems to have a problem with this behavior.
I’m currently building out an app that uses AWS’s mqtt JavaScript package (some web sockets under the hood) and would love to have the entire thing ported to Elm. But I’m very happy to be able to use ports in the meantime. The benefits I get from using Elm for this project, for me, far outweigh the negatives. With the ease of refactoring in Elm, I can see it being a fun process to move to all Elm code once web socket support is added in 0.19 or later.
I think there was a time when I would have been frustrated by it, but I think that was before I understood how hard it can be to predict which parts of a big project like Elm will end up needing to be prioritized and how much work it can take to communicate with a community about progress and priorities without getting bogged down in the disagreements and expectations that can create.
Prioritization is hard, timeline-ing is hard, defending prioritization decisions to a community is hard, and defending a team against the expectations a community can develop based on what they’ve heard about what is being worked on and how long they think that thing ought to take is also hard. Sometimes stuff takes longer than expected, and other times you work on one thing for a while and then discover that other things need to be prioritized over it or are a prerequisite for it. I think all of that is normal, and I don’t think any of it constitutes bad behavior. It’s just how things go.
In terms of your particular work, my approach would be to assume that the language as it is is all you’re going to have to work with. If the language as is is enough, use it. If not, then it’s probably pretty risky to use it, because even if the features you want do eventually come out, there’s no way to know if it will be by the time you need them.
Thank you so much for your answer straight at the point. I would really appreciate though if you can name some of the benefits you mentioned and what front end framework you have been using before.
Truth is I probably would rather use websockets through ports in order to use the official JavaScript client of phoenix channels and just leverage the functionality from elm. My biggest problem I guess is having trust issues with my own tech decisions when it comes to the front end technologies since coming from a pure back-end development background and that’s why I am trying to be thorough with what in my eyes looks like a grey spot. But all the love coming out of you that already using it in productions helps putting things into perspective.
As a beginner and only code front-end as hobby, I have found that Elm is still more friendly to front-end beginners than the other functional alternatives (Purescript, ReasonML, Clojurescript). Ports is hard to grasp and almost unavoidable, but at least the Elm part is nice to work with.
Yeah I think for websockets in particular, the lack of an Elm implementation really isn’t a big deal, since it maps so well to ports - it’s not a request/response model.
Unlike your friend, Evan is employed by NoRedInk to work on Elm full-time, and he seems pretty dedicated to continue with Elm and language design. So it’s unlikely that progress would stop, even if you don’t know exactly what will be in the next release. It looks like 19.1 will be released soon, fixing some key bugs and adding some major compile time improvements.
For me the benefits are the tooling, the type system, and the difficulty in shipping errors. I’ve worked in React for 4 years now and before that I used ExtJS for 4 years. All of that work has been building large internationally used web apps. I recently started using TypeScript too. With those frameworks and all of the tooling in the JS ecosystem I still find it to easy to make simple bugs and then find those bugs in production. TypeScript helps with a lot of that, but I feel like the compiler is my enemy and not my friend.
Elm gives the exact opposite experience for me. Always helping and guiding me to better solutions. The community on both Slack and Discord gives me the same experience too.
Edit:
I’ve also done work in Unity3D and Unreal Engine 4. I’ve used Java, .NET, C/C++, and Perl at work. I’ve also had the team sitting next to me use Ember at work. I’ve always admired Ember is more about getting the work done and not “where do I put this file”.
My experience has been great in spite of the websockets-package being gone for 0.19 Websockets fit perfectly into the way ports work, specifically because input and output is separated.
With a bit of Javascript to manage the connectivity, it’s not that different from using the elm-package!
and you could look at the code in the official package and get the same exponential backoff stuff for connectivity if you’d like. It’s here
In chronological order I have used AngularJS (Large web-app, >20k lines), VueJS (visual e-mail template editor, bachelor thesis, github plugin maintainer), React (>60k app) and elm. I started out with angular and replaced it with vueJS as my go-to-framework when angular2 was too inflexible and very closely coupled with typescript. VueJS is great - flexible, extensible, well-documented. Helpful community etc.
Then I had my first encounter with elm, got reeeeaaaallly confused at first but came back later to love it. Wrote some elm - understood it as flux plus static types in a well-refined bundle essentially. When I came to react/redux/ts I was thinking: “Really? This is what everyone is so hyped about?” I can just second @wolfadex saying that the compiler is my friend and not my enemy.
My friend who was new to elm and I ported a completely foreign, 5k line project from elm 0.18 to 0.19 within a few hours - I can not imagine doing that with any JS stack\
Whenever I see a new frontend project I get bogged down by the number of options I have: what framework, what linter, which testing environment etc. This is painful because however I refine my toolset, I learn over and over again is that JS does not scale and elm just caters to web app dev sooo well.
I read and understand other people’s code regularly in elm - with JS this it is just a pain now in comparison.
If I were to go with JS, I would recommend VueJS. React and Angular have a lot of traction because of their huuuge marketing budget (remember, facebook and google are behind these). When VueJS has momentum without this marketing budget there must be something to it.
With regard to websockets: Using them through ports with elm I still find much more enjoyable than connecting them to an JS framework.
Please note: I really do like JS, HTML, CSS - the are very interesting and powerful languages and there is a lot to learn from them. From a learning perspective I would write plain/vanilla JS, HTML, CSS. From a productivity perspective Elm (for anything you want to maintain) extended with web components.
VueJS usage for me is limited to building throwaway-stuff nowadays.
Websockets fit perfectly into the way ports work, specifically because input and output is separated.