
The Hitchhiker's Guide to Elm - roadbeats
http://azer.bike/journal/elm/?
======
jxxcarlson
I've been working on a project, now at
[http://www.knode.io](http://www.knode.io) for quite some time. It went from
Rails to an Elixir back end with an Angular 1 frontend, then a brief
experiment with an Angular 2 frontend, and finally to an Elm frontend. It is a
complex project with JS interop using ports to render (a) mathematical text
and (b) Asciidoc. Plus, there is a Latex-to-Html parser-differ-renderer
package that I wrote entirely in Elm (2K of code).

I couldn't be happier with Elm in this project. Many major refactors: instead
of the usual white-knuckle experience with prior languages/frameworks, it was,
like, zen.

------
tdbgamer
I really liked Elm a lot, but the issue for me was that composing components
is a shit show. You have to add variants to the root Msg type for every single
subpage and have it dispatch to the right update/view functions.

I'm really excited about a project inspired by Elm called Yew but allows you
compose components much more naturally and easily.

[https://github.com/DenisKolodin/yew](https://github.com/DenisKolodin/yew)

~~~
zoul
_I really liked Elm a lot, but the issue for me was that composing components
is a shit show. You have to add variants to the root Msg type for every single
subpage and have it dispatch to the right update /view functions._

Doesn’t that make sense, though?

An app in Elm is some kind of state + messages that change the state. Since
the state is usually too big to fit in a single structure, you break it down
recursively into progressively smaller substates. These again have some
messages that mutate the state.

Now, doesn’t it make sense to send the “child” messages through the parents?
You shouldn’t command the children directly, you should always tell the parent
to tell the child do this and that. At least in our [Swift, not Elm] app that
makes sense, composes well and keeps the model simple to think about.

~~~
tonyjstark
Not op, so I don't know his/her struggle. My struggle comes maybe from the
syntax I'm not used to, but also it always feels like you have to keep the
whole message-graph in mind to understand which message comes from where and
goes where and needs to contain which data and while that type system helps,
it feels like it also makes it more difficult. You cannot just run it and see
how far you come, you're code just won't compile. I know, this is a good thing
for bug free production code, but exploration is harder (at least for me).

Also the types become really complicated after a while since you wrap
everything in some kind of message type. So your parent message contains a
child message, containing some data that needs to get passed to the next view.
So errors become less readable or helpful. Or I'm doing something wrong, which
could very well be because I'm a bloody beginner.

~~~
zoul
_[I]t always feels like you have to keep the whole message-graph in mind_

It should be quite the contrary. When you design a piece of the app, the piece
should have its state, messages and view code, so it should be perfectly
possible to ignore any context, focusing just on the single piece. Just like
when writing pure functions, for example.

 _You cannot just run it and see how far you come, you 're code just won't
compile._

This is a known initial hurdle with expressive static type systems I think. It
gets better quickly and then you won’t be able to go back, feeling existential
fear without the compiler watching your back.

 _So your parent message contains a child message, containing some data that
needs to get passed to the next view._

This is getting too particular for me to explain/help/argue directly. In our
app, for example, the main app model is either _onboarding_ , _home screen_ or
_signed out_. Then it makes big sense for the main model to accept messages
regarding onboarding, home screen or signed-out state. And when it receives a
message related to one of its child states, it just delegates it. This makes
sense conceptually and is quite natural to follow when reading the code.

I am not an experienced Elm programmer, so maybe I am getting this wrong, but
what we have has worked for us well, so far.

------
gsvclass
I built [https://bellpluscat.com/](https://bellpluscat.com/) entirely in Elm.
It's a database in your browser kinda like a simpler Airtable. It uses Google
Drive as it's backend.

Elm let me a single programmer build this in a couple weeks with no runtime
issues even after major refactoring to add new features. It was such a
pleasure to work on.

------
grandinj
Are the elm overlords still hell bent on "thou shalt program our way or not at
all"

Because that kind of dogmatism is a complete show stopper for languages that
want to be deployed on even medium term projects.

~~~
grandinj
Specifically stuff like
[https://news.ycombinator.com/item?id=16510267](https://news.ycombinator.com/item?id=16510267)
is a showstopper.

I maintain long lived applications. Sooner or later we __always__ have a need
to call out to the host environment to work around limitations of the
compiler/runtime.

Not being able to do so, and the attitudes of the core elm team that prohibit
such actions, make elm a non starter for me.

~~~
zoul
Can’t you just call out to the JS world using the ports feature?

~~~
lewisinc
Yes. Yes you can.

------
bhnmmhmd
Great post. I welcome any alternative to HTML+CSS+JS. It's time we moved on
from these [in my opinion] garbages.

~~~
rkangel
Elm is in no way an alternative to HTML+CSS. It is an alternative to JS as a
way of doing work client side (it does in fact compile to JS).

The 'view' functions in Elm return HTML (represented using an ELM DSL for
convenience) that is added to the DOM and so then rendered using some CSS
provided elsewhere in the normal way.

~~~
jdemler
I have a vastly different experience: At CurrySoftware we used style-
elements[1] to build a internal frontent for a client. The whole project only
contains 15 lines of HTML that sets up the elm-app. Zero CSS or other HTML.

Try it out. IMO it changes everything about frontend development.

[1]: [http://package.elm-lang.org/packages/mdgriffith/style-
elemen...](http://package.elm-lang.org/packages/mdgriffith/style-
elements/latest)

~~~
rkangel
Thank you. I hadn't heard of this and it's really interesting. What are the
downsides of that approach? Is style-elements as full featured as you'd want?

~~~
jdemler
It is pretty much fully featured as what you would need in any typical web-
app.

One crucial thing that is missing is guaranteed browser support. That is why
we only used it for the clients internal frontend. But as I understand it,
this will be addressed in the upcoming 5.0 release.

Also the resulting HTML is not always as optimal as I would hope.

All in all development is just so much faster and cleaner. No need to worry
about layout and style. After using style-elements for a while, HTML + CSS
seem like a really stupid idea to describe layout and style.

------
freekh
Working on an elm project now and a few months in I believe I might see the
main wart if elm which is the amount of boilerplate required. I suppose that
should shock no one because elm might be many things but feature rich is not
one of them. I still like it though. And boilerplate might be easier to read
than some bad abstraction. Still it ends up less dry than I would have liked.

------
werds
Disappointed that that article did not start with "Don't Panic" in large
friendly letters.

------
venuur
Unfortunately, I am unable to read the article on my phone. The code examples
do not render properly. They extend off the left and right sides clipping most
of the code. Some sort of word wrap or shrinkage might be better.

------
hackbinary
I thought this was going to be about the email client. The that pine is not.
:/

------
crispy-jam
nice@!!!!!

