
Elm in the Real World - ohanhi
http://futurice.com/blog/elm-in-the-real-world
======
kasbah
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)

~~~
pjmlp
Personally I don't buy into any "Compiles to JS" language for production code,
other than for dabbling.

The JavaScript compatibility problems across browsers are already enough, for
me to sell to customers yet another layer to debug that might not even be
properly supported by the respective browser debugging tools.

~~~
lumpypua
Any commentary on "The Birth and Death of Javascript"?

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

As far as I can tell, Javascript the runtime is a juggernaut that there's no
stopping. If a platform gets popular tooling fixes itself.

~~~
pjmlp
Personally, even though I also do have quite some webdev experience, I am
wishing that mobile native development wins.

But on HN that is a sure way to be downvoted.

~~~
KingMob
I'm personally hoping the future holds some way to blend the
openness/interoperability of the web with the performance of native apps.
Maybe React Native, maybe web assembly, etc.

I hope that pure mobile development doesn't win, because the mobile app
ecosystems are way more controlled than desktops/servers, and if everything
went Android/iOS, it would be a major loss for freedom.

------
bsaul
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.

~~~
charlysisto
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
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.

------
fauria
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
Thank goodness I'm not the only one!

------
agentgt
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.

------
seivan
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?

~~~
cies
> I guess this is like a better version of ...

Make sure to look at PureScript as well. It is a much less "opinionated"
cousin of Elm. By opinionated I mean that Elm pulls HTML and CSS into the
code, and has functional reactive programming built in; in PureScript these
are libraries.

~~~
ujal
I am currently into Elm and intend to transition to Haskell/GHCJS at some
point. I've also looked into PureScript but don't really see how it fits
between Elm and GHCJS.

------
fencepost
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?"

