8 ms·

Elm in the Real World

214 points by ohanhi 11y ago

fauria 11y ago
For a moment I thought the article would be about the email client: http://www.instinct.org/elm/ http://www.instinct.org/elm/
- chris_wot 11y ago
  Thank goodness I'm not the only one!
bsaul 11y ago
Why do we see a pike of articles about elm recently ? Is it catching on, or are elm people pushing users to communicate more ? Note that it's working. i think i'll install it and play with it on my next free time.
- deadfoxygrandpa 11y ago
  I've been involved with the Elm community for a couple years now and I haven't noticed a recent push to get people to talk about it more. I think people are just trying it out and getting excited by it.
- charlysisto 11y ago
  I don't know if my case is representative, but as a backend dev I'm still on the fence with javascript and at the same time eagerly wanting to step in the frontend realm, because, well Internet. And it seems that elm finally got the right combination of reliability (functional, immutable....) and friendliness (nice syntax, good docs...) for me to cross the rubicon. Add to the mixture charismatic personalities like R. Feldman and E. Czaplisky and this could be the answer.
  - hellofunk 11y ago
    The problem is that to get anything done on the Internet, you will need easy use of existing third-party libraries for a wide range of stuff, or you end up spending huge amounts of time implementing protobuf handling, websockets, ajax, webgl and the myriad of other important technologies that you may likely encounter in those areas. Excellent libraries for that stuff are out there, but Elm makes it hard to interop with them... for now. I really hope that changes.
seivan 11y ago
I guess this is like a better version of using TypeScript, React, *Flux and RxJS. Mostly because Elm seems to have everything builtin while you might have issues with TS typedefinitions. Also their success/fail tasks for HTTP calls reminds me of flux actions being dispatched. Dispatch action for an http class and then dispatch another action for success or failure. Or did I miss understand?
- drapper 11y ago
  Someone should make an opinionated, batteries-included JS/TS framework like Elm, based on TS, React, Flux.
  - seivan 11y ago
    The JavaScript world doesn't like that. That's why no one has made a carbon copy of Rails. Even React, Flux, Router and etc comes in several parts. I know railties are modular but at least they come from the same project and repo and update together.
    - drapper 11y ago
      Yeah, the JS world currently is very pro-modularization, but I already saw some discussions on Twitter from the React/Flux people how that creates too big barrier of entry for the newcomers. One of the things that draw people to Angular is that it has almost everything that you need included - it's easier to say to someone "just use Angular", than "try React, with Redux, and Router, and Webpack - it will take some time to configure it, but it's worth it".
      - seivan 11y ago
        Well, it has it's benefits. I don't like Redux and I like Reflux so it allows me to do that. Then again Rails does let you switch out compatible parts. By compatible I mean if it adheres to "Railties", e.g. using ActiveModel for replacing Pgsql with MongoDB.
    - 11y ago
kasbah 11y ago
I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that. I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-write everything in JS. In retrospect Elm really wasn't the right choice for that project because it wasn't mature enough (and maybe I hadn't been using it for long enough either). The lack of any kind continuation monad for managing effects at that point (later added to the language as Tasks) and the cumbersome interop with JS (still an issue) were real sticking points. It's just frustrating when you have a problem that can be solved trivially with a state-mutating for loop and you have no easy mechanism to do it. The boilerplate required to use Chrome's messaging within the app was really painful. I tried to use Elm again for a personal project, a kind of gallery website with a JS search function [2]. After starting an initial prototype in Elm I switched to using React (which I had never used before) and found I was much more productive (even though the code is messier). Having a much bigger repository of re-usable modules and being able to take short cuts is really valuable at this stage of development (and the server-side compilation ability is really cool). These experiences have made me wonder about the real-world place for Elm and how long it would take for it to rival something like React. I definitely think there is a lot of value in learning Elm to help you think about state in your application in a more higher level way but I would really hesitate in advocating to use it for real-world project at this stage (it does depend on the project of course). [0] https://github.com/switchface/helm https://github.com/switchface/helm [1] https://github.com/kasbah/mooltipass.hid-app https://github.com/kasbah/mooltipass.hid-app [2] http://kitnic.it/ http://kitnic.it/ | https://github.com/monostable/kitnic https://github.com/monostable/kitnic (work in progress)
- hellofunk 11y ago
  I strongly believe that for any language that compiles to JS to be successful, seamless integration with existing JS is absolutely required. This is the main selling point of Clojurescript which, while I enjoy Clojure a lot, is a dynamically typed language like JS itself, and I wish I could interact with JS in a stricter way. If Elm can improve on its interop, it has potential to be a strong force. But this is true of any new language. If you can't easily interop with the lowest common denominator language in the platform you build for, your language is too restricted for meaningful use. This is why Rust integrates well with C, because it has to, or it is irrelevant in many cases. This is why Clojure interops seamlessly with Java. Elm needs to get this point, or it will remain a niche hobby language avoided by professionals.
agentgt 11y ago
One thing I like about Elm over the plethora of Javascript converters is that it is its own language devoted to one runtime (js) and a very different language than most (syntax wise). The same goes for Coffeescript as well.. for the most part at least. I particularly don't like general purpose language to JS converters like Scala.js, Clojurescript, GWT, etc because I think these converters can cause some cognitive dissonance (based on past experiences). That is I actually think its better to have different languages for different environments but I suppose not everyone shares that belief.
fencepost 11y ago
I have a couple of projects in mind that would require some level of JS front end, and Elm sounds like something interesting to look at since I've not done more than dabble with JS a bit. That said, every time I see a post about it I can't help the immediate response of "didn't pine replace that?"

214 points by ohanhi 11y ago

For a moment I thought the article would be about the email client: http://www.instinct.org/elm/ http://www.instinct.org/elm/

chris_wot 11y ago
Thank goodness I'm not the only one!

bsaul 11y ago

Why do we see a pike of articles about elm recently ? Is it catching on, or are elm people pushing users to communicate more ? Note that it's working. i think i'll install it and play with it on my next free time.

deadfoxygrandpa 11y ago
I've been involved with the Elm community for a couple years now and I haven't noticed a recent push to get people to talk about it more. I think people are just trying it out and getting excited by it.
charlysisto 11y ago
I don't know if my case is representative, but as a backend dev I'm still on the fence with javascript and at the same time eagerly wanting to step in the frontend realm, because, well Internet. And it seems that elm finally got the right combination of reliability (functional, immutable....) and friendliness (nice syntax, good docs...) for me to cross the rubicon. Add to the mixture charismatic personalities like R. Feldman and E. Czaplisky and this could be the answer.
- hellofunk 11y ago
  The problem is that to get anything done on the Internet, you will need easy use of existing third-party libraries for a wide range of stuff, or you end up spending huge amounts of time implementing protobuf handling, websockets, ajax, webgl and the myriad of other important technologies that you may likely encounter in those areas. Excellent libraries for that stuff are out there, but Elm makes it hard to interop with them... for now. I really hope that changes.

seivan 11y ago

I guess this is like a better version of using TypeScript, React, *Flux and RxJS. Mostly because Elm seems to have everything builtin while you might have issues with TS typedefinitions. Also their success/fail tasks for HTTP calls reminds me of flux actions being dispatched. Dispatch action for an http class and then dispatch another action for success or failure. Or did I miss understand?

drapper 11y ago
Someone should make an opinionated, batteries-included JS/TS framework like Elm, based on TS, React, Flux.
- seivan 11y ago
  The JavaScript world doesn't like that. That's why no one has made a carbon copy of Rails. Even React, Flux, Router and etc comes in several parts. I know railties are modular but at least they come from the same project and repo and update together.
  - drapper 11y ago
    Yeah, the JS world currently is very pro-modularization, but I already saw some discussions on Twitter from the React/Flux people how that creates too big barrier of entry for the newcomers. One of the things that draw people to Angular is that it has almost everything that you need included - it's easier to say to someone "just use Angular", than "try React, with Redux, and Router, and Webpack - it will take some time to configure it, but it's worth it".
    - seivan 11y ago
      Well, it has it's benefits. I don't like Redux and I like Reflux so it allows me to do that. Then again Rails does let you switch out compatible parts. By compatible I mean if it adheres to "Railties", e.g. using ActiveModel for replacing Pgsql with MongoDB.
  - 11y ago

kasbah 11y ago

I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that. I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-write everything in JS. In retrospect Elm really wasn't the right choice for that project because it wasn't mature enough (and maybe I hadn't been using it for long enough either). The lack of any kind continuation monad for managing effects at that point (later added to the language as Tasks) and the cumbersome interop with JS (still an issue) were real sticking points. It's just frustrating when you have a problem that can be solved trivially with a state-mutating for loop and you have no easy mechanism to do it. The boilerplate required to use Chrome's messaging within the app was really painful. I tried to use Elm again for a personal project, a kind of gallery website with a JS search function [2]. After starting an initial prototype in Elm I switched to using React (which I had never used before) and found I was much more productive (even though the code is messier). Having a much bigger repository of re-usable modules and being able to take short cuts is really valuable at this stage of development (and the server-side compilation ability is really cool). These experiences have made me wonder about the real-world place for Elm and how long it would take for it to rival something like React. I definitely think there is a lot of value in learning Elm to help you think about state in your application in a more higher level way but I would really hesitate in advocating to use it for real-world project at this stage (it does depend on the project of course). [0] https://github.com/switchface/helm https://github.com/switchface/helm [1] https://github.com/kasbah/mooltipass.hid-app https://github.com/kasbah/mooltipass.hid-app [2] http://kitnic.it/ http://kitnic.it/ | https://github.com/monostable/kitnic https://github.com/monostable/kitnic (work in progress)

hellofunk 11y ago
I strongly believe that for any language that compiles to JS to be successful, seamless integration with existing JS is absolutely required. This is the main selling point of Clojurescript which, while I enjoy Clojure a lot, is a dynamically typed language like JS itself, and I wish I could interact with JS in a stricter way. If Elm can improve on its interop, it has potential to be a strong force. But this is true of any new language. If you can't easily interop with the lowest common denominator language in the platform you build for, your language is too restricted for meaningful use. This is why Rust integrates well with C, because it has to, or it is irrelevant in many cases. This is why Clojure interops seamlessly with Java. Elm needs to get this point, or it will remain a niche hobby language avoided by professionals.

agentgt 11y ago

One thing I like about Elm over the plethora of Javascript converters is that it is its own language devoted to one runtime (js) and a very different language than most (syntax wise). The same goes for Coffeescript as well.. for the most part at least. I particularly don't like general purpose language to JS converters like Scala.js, Clojurescript, GWT, etc because I think these converters can cause some cognitive dissonance (based on past experiences). That is I actually think its better to have different languages for different environments but I suppose not everyone shares that belief.

fencepost 11y ago

I have a couple of projects in mind that would require some level of JS front end, and Elm sounds like something interesting to look at since I've not done more than dabble with JS a bit. That said, every time I see a post about it I can't help the immediate response of "didn't pine replace that?"