
The Elm Architecture - lelf
https://github.com/evancz/elm-architecture-tutorial#the-elm-architecture
======
saosebastiao
So out of all the compile-to-javascript languages out there, elm is easily my
favorite, despite not being usable outside the browser. This article is one
illustration why it is so attractive: app architecture that is blindingly
simple (its all just state machines under the cover, which is exactly what a
UI is).

Now all we need is an elm that compiles to native code that somehow can do
what React Native is doing for the native interface. I would easily pay 3-5x
Xamarin's prices to be able to do so. Who's up for it?

~~~
wz1000
Haskell with an FRP library may work for what you want to do. Reactive-banana
looks good, though I haven't used it.

~~~
photex
The trouble though comes about once you have to start working with a UI
library. It's a mess and a half unless you use C++. I'd like to try using Elm,
or Purescript for UI work using atom-shell or nw.js. That opens almost the
same can of worms (how easy it might be to 'bind' your engine to your
UI/view). I've written a non-trivial application using QtWebkit entirely for
the UI and it was a very agreeable experience. The engine of this app was C++
but it got my gears turning.

~~~
pjmlp
Actually that I my opinion from any web based UI, a mess of JavaScript/CSS
trickery and HTML.

Native UI development feels so much more advanced and user friendly.

Saying this as a UX developer since the mid-90's.

~~~
photex
My comment was in reference to using native toolkits from a language other
than C++ and not the status of using native toolkits in general. <friendly-
joke>I have a hard time believing that you've been using native UI toolkits
using Haskell since the mid-90s.</friendly-joke> :)

~~~
pjmlp
No, but I was using Turbo Pascal followed by Delphi. Also played with C++
Builder, but by then Visual C++ had taken over as Borland was going through
their Inprise phase.

------
jasim
I've been thinking of giving Elm a go, and this walk-through is very helpful
in breaking the initial barrier. Exciting to see these ideas finally giving us
answers on how to do user interfaces on the web right.

ReactJS has also converged into the ideas proposed by Elm: the Model is
explicitly defined (props and state); view is always a function of the Model;
and the Model is mutated only through Signals (one-way bound callbacks in
plain React, Actions when using Flux).

I have a question for anyone who've worked with both Elm and React. It seems
to me that these ideas (component model, well-defined mutation point for
state, composability, one-way binding etc.) are what matters more than the
language itself. Granted that the language can influence how code is written
(immutability, pure functions, ..), but does Elm (or ClojureScript for that
matter), drastically improve creation of typical user interfaces just by
virtue of the language?

~~~
Lethalman
When there was no React.js, I had in mind something like that and implemented
a very simple concept like this with ghcjs. Functional languages tend to let
you write this kind of code.

It felt very organized and just worked, then I looked at Elm and said: "that's
exactly what I thought I'd do with ghcjs". Then with react.js: "finally
somebody implemented the concept in plain javascript". Which is after all a
kind of stricter mvc model for the single-page web applications. The fact is
that with an haskell-like language, the kind of mvc concept is much more
structured, you do less design mistakes because the language itself
constraints the effects. So what react.js did is adding these constraints on
top of plain js in an elegant way.

In other words: I think the addition of elm is the language itself, for those
acquainted with haskell and where type checking matters a lot, compared to
plain js.

On the same path, there are other libs similar to react.js that are even
faster because they have stricter requirements on how data is mutated.

~~~
jasim
Thanks a lot for the response. Your comment about constraints improving design
makes a lot of sense.

As to libs similar to React, I assume you're talking about Mercury and
Mithrill. But I'm quite happy with React's performance and escape latches
(shouldComponentUpdate). I'll however switch in a heartbeat if a better design
comes along.

The problem is that unlike when I was mutating DOM with spaghetti JS or
wrangling with Angular, I am yet to say "why is this thing so darn difficult"
with React for almost all use cases I've thrown at it (yet to figure out
animations). And the last React.js Conf has taken care of most things that I
could imagine improving in web development with Relay and CSS in JS.

------
cogware
My experience with Elm was that it's very elegant and fun to work with if you
are building a purely clientside application, but once you need communication
with server the APIs are not very well developed and it becomes a major
headache.

Note that none of the examples in this page (or in any Elm tutorial I found)
flesh out interaction with a backend.

~~~
phamilton
Consuming data isn't hard. Creating a dashboard that displays the values sent
down on an interval over a websocket is super easy.

Sending data isn't hard. Sending the mouse coordinates on a click to the
server over a websocket is super easy.

There is, however, no easy way to consume data and send a response. To write
an echo server, for example, you currently have to send the data to a
javascript port and then read from the port to send it back.

~~~
CGamesPlay
I ended up implementing this in JavaScript using Rx, but the core concept is
the same:

    
    
        Incoming requests:     --a------------->
        Requests to server:    ---b------------>
        Responses from server: -----------d---->
        Updates to app state:  ---c--------e--->
    

a - User "sends message" to chat room

b - Handler for that action queues a request

c - Handler for that action also queues a local update

d - Server responds with the sent message

e - Handler for that response queues a local update

------
Matthias247
I have read the document and find the ideas around Elm really interesting. It
seems nicely designed and is also understandable for a newcomer in FP.

Some things that would interest me but which I couldn't figure out from these
docs are:

1\. Will sending something to a Channel or the DOM event that causes the send
to the channel (e.g. onClick (send channel Decrement) in the example) be
executed synchronously (aka direct function calls in the transpiled JS) or
asynchronously (signal processing in the subscriber is deferred, e.g. with
settimeout). If it's deferred, can it really be guaranteed that for example a
button could only be pressed once (with direct calls you could disable it
immediatly in the onClick listener) or other actions which you might want to
see immediatly?

2\. Are there any concepts around cancellation? E.g. in one other example
there was a textbox whose text-changed signal triggered the downloading of
images which were shown in another view. There old pictures were still shown
despite the input has changed already again because they are in the HTTP
response signal at some point of time. I guess you would have to create and
map a new HTTP signal each time the input change and disconnect the old one.
But this seems like against the proposed architecture.

------
amelius
It all looks great, but I wonder what happens when my model is actually a
large database (or, for example, a large map), and the visual components are
each observing changes in this database (or map). Would the database be one
big signal? Or would the database be a large collection of signals? How would
one model this (efficiently) in elm?

------
amelius
I wonder if it is also possible in elm to perform layout-dependent logic. For
example: show a piece of text horizontally, but if it is too wide (in pixels),
show it vertically.

------
gilgoomesh
A little off topic but I followed the links to elm-lang.org and the examples
page is filled with unlicensed copyright/trademark material (images and trade-
dress from Super Mario World, Legend of Zelda and Apple's iOS Calculator):

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

A bit disappointing.

------
PaulHoule
Wow, that looks like COBOL.

~~~
jacquesm
I've programmed COBOL for a living back when it was still fashionable and I
don't think it looks like COBOL at all, what specifically triggers your 'looks
like' bit?

~~~
PaulHoule
The separate sections for data definitions, forms, etc.

~~~
jacquesm
Ah, the 'divisions'. Right, I see what you mean. Quite a few languages have
such 'divisions', though they're not usually explicit. For instance, C code
usually has a bunch of include statements at the top, followed by internal
structure declarations followed by function definitions.

We don't name the sections there but they might as well have names (you can
include a file in the middle of another but that's pretty bad form). Other
languages are more formal (for instance Modula-2, Erlang, Ada). That's not a
COBOL specific thing.

