
Why Elm? [pdf] - antouank
http://www.oreilly.com/web-platform/free/files/why-elm.pdf
======
mistersys
I've tried to use Elm and The Elm Architecture on a project before, but I gave
up.

The Elm Architecture makes it very easy to create small type safe components,
but it forces parent components to manage the state + structure all children
components. This makes it hard to use a component and to separate concerns.

In order to create a list of stateful children, you must:

1\. Add a list of the child states to the component state, event if the parent
component doesn't care about the child's state.

2\. Handle adding + removing child state's manually

3\. Map all scoped child state updates through your reducer, adding a
constructor to your action type

4\. Finally, map each of the child state's to the component's view.

You end up big types and match expressions that just manipulate lists. I have
yet to see a FRP library that allows you to just use a component without
introducing boilerplate.

~~~
KirinDave
I'm curious if you've ever looked at optics-based systems for component
coupling?

Personally I think that the entire top-down state tree is a bad idea, but I'm
willing to be convinced. I'd much prefer a modeling like the actor approach.

~~~
colordrops
Google isn't finding anything regarding component coupling and optics. Do you
have any links that introduce the concept?

~~~
pygy_
A lens is an object that has both read and write access to a property of an
object (or to a path into a tree of nested objects).

Rather than passing parts of the model to the children (as you'd do with React
props), you pass lenses into said parts.

It enables child components to read/write to the global store without knowing
its structure. As long as it receives an appropriate (set of) lens(es) it is
happy.

So, for example, if you have a list of strings, rather than passing the nth
string to the nth component, you'd pass a lens to the nth string. The
component can then not only read but also write to its slot.

Lenses can also be composed, so you can create them on the go as you'd pass
sub-props to grand-children.

[https://github.com/calmm-js/partial.lenses](https://github.com/calmm-
js/partial.lenses) <= a comprehensive lens library

[http://ramdajs.com/](http://ramdajs.com/) also has lenses.

These libs are strongly influenced by the FP world. The underlying data
structures are immutable, writing to a lens creates a new version of the store
(as efficiently as possible, by recycling intact objects).

~~~
charlieflowers
So basically, it's like using dependency injection, and what you're injecting
are higher order functions for the getters and setters for whatever properties
you need. Is that right?

~~~
harperlee
Do they need to be functions? Because this seems a lot like handling [:a
:keyword :vector :for :navigating :trees] in Clojure and passing it to either
update-in or get-in functions, which is a pattern ubiquitous in re-frame, but
not sure is can be called a lens).

~~~
charlieflowers
What you're saying sounds similar. But my question and your post are both
missing the "composition" aspect. Somehow lenses are composable, and I guess
to grok that we'd need to look deeper.

------
antouank
Been using Elm for a few months now. Both in small side projects, and in a
production app for work.

Many benefits over using js, and basically no downsides apart from the initial
learning curve. And even that could be equal to the learning you have to do
every time your team decides to add/use a new foo.js library or framework to
the project.

With Elm:

    
    
      - you are confident about your code 
      - others ( and your future self ) can actually read it and understand it
      - it pushes you to think before you write
      - refactoring is a breeze, not a nightmare
    

I hope I won't have to use js on my next gig.

edit: Also, I cannot speak highly enough about how helpful the compiler is,
and the community in the slack channel. Makes the whole experience a joy.

~~~
minikomi
As an open question to yourself, or anyone else advocating elm heavily, can
you show something cool you've built using the language? That would be the
most convincing argument!

~~~
_greim_
I don't spend a lot of time advocating, but here are my first two attempts at
building stuff in Elm.

[https://greim.github.io/elmsweeper/](https://greim.github.io/elmsweeper/)

[https://greim.github.io/electron-golf/](https://greim.github.io/electron-
golf/)

Honestly I think it would have been easier to build the first iterations of
these in JS (React or something) but with the second->nth iterations, it
became easier with Elm.

~~~
minikomi
I'm seeing a lot of simple games on the built with elm site - do you think
that's a sweet spot for using elm?

~~~
_greim_
Not sure, maybe.

A lot of it might be that simple games are fun and relatively easy, so well
suited for learning new stuff in your spare time.

Then again, the electron golf game re-renders SVG DOM at 60fps. Building web
apps that way hadn't occurred to me until React came along, and I didn't
attempt it until Elm.

------
zellyn
I want to like and use Elm. However, unless things have changed recently, it
seems the author hasn't learned to delegate. They also like to really get
things right, which takes forever.

So it's really good at what it does, but for everything else, it's just
incomplete. For instance, Elm seems like a natural fit for an offline-first
ServiceWorker design. But I don't think it really covers much of the just-
outside-of-core-Javascript browser APIs. You're likely to run into "I have
some really interesting ideas about how to cover that a super elegant way, but
I'm concentrating on rewriting the $WHATEVER right now" newsgroup posts, but
that's it… :-(

~~~
canadaduane
Yes, this is a problem IMO. I dedicated 9 months to learning Elm, but left
frustrated by the tight control and lack of delegation that would have
leveraged my skills and many others' skills to further the idea and language.

~~~
skybrian
On the other hand, it's easier to wait patiently if you're not using the
language yet :-)

I've been watching Elm for some time. I'll wait until it's done. So my reason
for not using Elm is: I'd rather be patient.

~~~
KurtMueller
I think you're going to be waiting indefinitely then :).

------
ng12
One thing I don't see addressed here is the biggest "Why Not Elm": you have to
learn Elm. Elm is a beautiful language and in the last year or two the
ecosystem has gotten much better. However I don't think I'll ever make
progress adopting it at my day job. For all of it's flaws JavaScript is still
quick, scrappy, and easy to pick up. Convincing a curmudgeonly back-end
developer that React and webpack will make his life easier is hard enough.
Convincing him to learn a seemingly esoteric functional language too is
basically a non-starter.

~~~
cel1ne
Why not Elm on google turns up this:
[http://reasonablypolymorphic.com/blog/elm-is-
wrong](http://reasonablypolymorphic.com/blog/elm-is-wrong)

I think the basic gist was that it's type-system is far from complete.

~~~
zeptomu
The main critics is that it does not support type classes, but maybe that is
actually not a _bad_ thing. The discussion is similar to the never ending Go
discussion about generics and people do amazing stuff with Go (now I guess
critics would say they would do even more amazing stuff with generics).

Not that I say type classes (or generics) are useless, but keeping a language
simple (in the sense of keeping the feature list small) has benefits on its
own. I did not to complicated projects in Elm, but I watch the language
closely and really like what I have seen so far, so I hope Evan keeps up the
good work, as I think he has pretty good taste for language design.

------
eweise
I'm using Elm for an internal customer service app and it is working out
fairly well. My background is more server side programming so the ability to
avoid javascript and its constantly changing ecosystem is a big plus. Elm the
language is simple enough to understand in a day and the basic architecture is
also straightforward. The biggest challenges are finding examples of how to
architect larger apps but this example should help
[https://github.com/rtfeldman/elm-spa-
example](https://github.com/rtfeldman/elm-spa-example) Also, I tried mentoring
another coworker on Elm but they seemed to have a harder time than I did. I
think it could be partly because they were an experienced Javascript developer
who wanted to apply their existing patterns to Elm.

------
jshute
Elm hasn't merged a trivial change to allow manipulation of UTC and timezones
in 6 months:

[https://github.com/elm-lang/core/pull/739](https://github.com/elm-
lang/core/pull/739)

Basically, if you have to deal with local time, this isn't the language for
you. If you expect to be able to add to the platform where you find it
lacking, this isn't the language for you.

At this point, Typescript has the momentum to make it irrelevant

~~~
zeptomu
Typescript is a completely different language advocating different paradigms
so they are not comparable.

However I have to agree with you that the lack of support for local time is
pretty unfortunate.

~~~
jshute
I've used both heavily. I think paradigm is the key word if you're thinking
mind-expanding properties. While immutable types and combinators are less used
in Typescript (you've got me there) you can certainly get 80% of the value of
strong typing, and there are several variants of Virtual DOM support.

Elm's error messages and semantic versioning are still a class above anything
else, though. Sad to see it rotting on the vine like this.

------
azangru
I am surprized Elm gets talked about so much more than Purescript. Although
Purescript is more of a general-purpose language and feels like Haskell that
compiles to Javascript, and Elm is something that relies on its specific
runtime to work.

~~~
zem
same reason rails got so much more mindshare than any of the competing web
frameworks of its day - there is considerable value in optimising for the
common case, and indeed adding constraints in the name of safety and good
architecture; most languages/frameworks try to optimise for flexibility and
miss out on this fact.

~~~
KurtMueller
I think this is one of the main selling points about Elm - it's got
conventions and it's got opinions. There's only one way to structure your app
and it's the Elm way. That's a good thing when you're

1) building & growing the app - there's only way to grow and it must follow
the same conventions as every other Elm app 2) bringing on developers - their
main hurdle is the business logic itself and not the structure of the app 3)
finding resources in the community - most everybody is traveling down the same
road and can teach one another the lessons they've learned

------
0xCMP
I like Elm a lot. I also do a lot of React and I have worried about picking
Elm to avoid killing a nice product written in it because no one is willing to
learn it to maintain it after I'm gone. Better to pick React to avoid any
rewrites just to continue maintaining the product.

However, if they could just be convinced to learn Elm I'm positive that Elm
would be much easier to maintain and improve than just React by its self.
React can definitely be maintained easily, but Elm does a lot of the work to
check itself and also enforces discipline that React can't (although you could
get a lot by just using Flow extensively and treating its errors as blockers).

~~~
mistersys
The static types system is great, however, having used elm: elm unloads much
of the work react does onto you. React automatically (with keys) manages state
creation for lists and child components, but with elm you have to manage that
manually.

Using a component isn't simply matter of importing and using, you have to
integrate its state into your component, send all it's events back to its
reducer, and then map each child state to the corresponding view. You end up
with lots of boilerplate.

~~~
fpoling
From my small experience with Elm all that boilerplate is nicely dealt by
compression-oriented programming [1]. It is easy to move common code into
helper function and Elm pure functional nature makes that rather maintainable.
The hard part is to come up with good names for those helpers and avoid being
too generic when refactoring code.

[1]
[https://mollyrocket.com/casey/stream_0019.html](https://mollyrocket.com/casey/stream_0019.html)

~~~
mistersys
I think the bigger problem here is the load it takes to change from stateless
to stateful.

Let's say a create a stateless subscribe button component, that's part a of a
stateless header component. It just accepts a listener that is called when the
button is clicked.

Now, my designer wants me to add a dropdown menu to the subscribe button that
allows people to enable email notifications. The dropdown menu needs state, so
now I add a reducer and model to my subscribe button, I need to wire that up
through the stateless header component making it stateful, then finally wire
it into the the atom for the app. I ended up doing these chains of updates and
adding parameters to add simple features.

Also, elm lacks typeclasses. Try making a modular form builder with elm that
allows other authors to define fields with custom state, it's a mess.

------
kureikain
I really like Elm. It makes writing code so easier. At first, it's bit hard to
get into the habit. But once I got paste that state(that takes 1-2 days) and
get into how to write Elm, everything become so clear.

I currently use Rails and this helper[1] to render an Elm component. Then I
mount it like this: [2]

``` <%= elm_component('TeamPicker', {flags: { formAuthenticityToken:
form_authenticity_token, domain: current.domain, teams: user.my_teams.map {
|team| {id: team.id.to_s, name: team.name || ""} }, current_team: {id:
current.team.id.to_s, name: current.team.name || ""} }}, {tag: 'div', class:
"nav-item"}) %> ```

I think this is an easy way to get into Elm world step by step.

My site is still normal HTML but I used ELM here and there for some component
require interaction/multi step form etc.

\---

[1]:
[https://github.com/NotyIm/trinity/blob/master/app/helpers/el...](https://github.com/NotyIm/trinity/blob/master/app/helpers/elm_helper.rb)
[2]:
[https://github.com/NotyIm/trinity/blob/master/app/views/part...](https://github.com/NotyIm/trinity/blob/master/app/views/partials/dashboard/_header.html.erb#L46-L52)

------
bauerd
Off-topic, but here I go: Has anyone tried compiling Elm's compiler (written
in Haskell) to JS (with ghcjs)? Are there any other small and approachable
functional languages that are in-browser compilable and provide JS interop?
I'd love to hack on a small Agent Based Modelling environment for the browser,
comparable to what NetLogo[1] achieves in large on the desktop. Or maybe just
make it a LISP?

[1]
[https://ccl.northwestern.edu/netlogo](https://ccl.northwestern.edu/netlogo)

~~~
firethief
Since you don't seem set on a language, let me throw my hump in for OCaml.
It's supports a functional style without forcing you to use it for everything;
js_of_ocaml compiles OCaml's dense, high-performance bytecode to Javascript
that apparently integrates well with web APIs.

------
steinuil
I think the two things Elm lacks the most right now are some form of
polymorphism and some way to make parts of an Elm application manage their
local state.

At the moment there's only an internal API for the latter, and it's pretty
ugly. I think what would be good for Elm would be to spin up a few separate
Elm processes and provide an easy interface to make them communicate, sort of
like in Erlang. You can do this using ports and binding them together with js
right now, but it's kind of ugly.

------
filoeleven
Late to the party, but someone posted in the Ableton "Get started making
music" thread[0] that the components in their slick web app[1] were made with
Elm. Pretty impressive.

[0]
[https://news.ycombinator.com/item?id=14299816](https://news.ycombinator.com/item?id=14299816)
[1] [https://learningmusic.ableton.com/](https://learningmusic.ableton.com/)

------
sandeepc24
Also have a look at [https://www.npmjs.com/package/fable-
elmish](https://www.npmjs.com/package/fable-elmish) with F# flavor.

~~~
KurtMueller
Do you use Fable / Fable-Elmish? If so, how do you like it?

~~~
sandeepc24
I am working on a project using Fable Elmish and I am really happy with it.
All I can say is give it a shot.

~~~
KurtMueller
As a side project or at work? Thanks for any info.

------
Myrmornis
The string "haskell" doesn't seem to appear in the text at all. That seems
silly and rather patronizing, since it seems to be a book about a language
that is heavily based on haskell, with very similar syntax. It bothers me when
authors take this sort of "oh you don't need to know about that" approach.

------
jlebrech
Last time i tried Elm I couldn't figure out how simply modify this clock
example to move the hand quicker than every second

[http://elm-lang.org/examples/clock](http://elm-lang.org/examples/clock)

~~~
redka
Well this isn't _that_ hard.

    
    
      Time.every (second / 2) Tick
    

and to still move it the same amount:

    
    
      Tick newTime ->  
        (newTime * 2, Cmd.none)

~~~
jlebrech
I tried to use millisecond, but I don't it has the same interface as second.

------
snappyTertle
Is there an effort to bring elm on native mobile to compete/work with react-
native?

~~~
kuon
There is [https://github.com/ohanhi/elm-native-
ui](https://github.com/ohanhi/elm-native-ui)

------
pcvarmint
I used elm for a while after mailx, but finally settled on pine. I never got
used to mutt's UI.

Oh, how tech names keep getting recycled!!!

------
arrty88
Is it good for server side NodeJS as well?

~~~
agentultra
Don't know about Elm, but there's Bucklescript or Reason and they generate
really great, readable JS for use on Node.

(And even on the front-end there's `bucklescript-tea`; a port of the Elm
architecture to OCaml)

------
bradknowles
Good question. For a CLI mail client, I prefer mutt or pine. But elm isn't too
bad as an alternative, if those aren't available.

------
mrbill
Too many products with conflicting names. I thought this was about the email
client at first.

[http://www.instinct.org/elm/](http://www.instinct.org/elm/)

~~~
ng12
> Update 06th Jan 2000: elm 2.4 is not Y2K compliant.

I'd be really surprised if it were.

~~~
richardwhiuk
> Sadly, most of the information about elm on the internet is badly out of
> date.* The program is still being slowly developed, and the release (March
> 24, 1999) of elm 2.5 is promising.

Awesome.

