
Elm and Phoenix/Elixir in Production for France TV - tbassetto
http://vincent.jousse.org/en/tech/elm-phoenix-elixir-production/
======
sotojuan
Elixir and Phoenix are stable and by now they're a solid choice (more than
enough warranted praise on HN), but I'm still skeptical about Elm from a
"platform" perspective. From what I can tell, Elm apps are a single blob of
JavaScript that either loads or doesn't (e.g. you can't read the Elm site
without JavaScript enabled), while the JavaScript ecosystem is moving towards
server-rendering, dead code elimination, and "progressive web apps" so to
speak. PureScript for example has dead code elimination—you can make a <1kb
PureScript "Hello World" app.

I know the Elm team is capable of all of these—I just haven't heard of
anything yet. While they're "nice to have" now, these features might become
crucial and important.

Another interesting thing about Elm is its progressive removal of features (I
think the infix operator was or is going to be removed soon) in order to make
the language more approachable. I actually support this because if you need
"true" ML/Haskell features, there's PureScript.

Anyway, glad to see Elixir and Elm being used productively!

~~~
hellofunk
At the very least, Elm code should be compatible with Google's Closure
compiler (just like Clojurescript). There is no reason the Elm folks should
try to re-invent the wheel on this, just harness the power of the Closure
utilities by making your emitted JS standardized and compliant. Then you get
all sorts of things for free, like dead code elimination, just for starters.
The Clojure team realized this from the _start_ and it has done a lot for the
cljs ecosystem.

~~~
danenania
I disagree. Google Closure is antiquated and complicated to configure and adds
a lot of unpleasant baggage to cljs.

I love Clojurescript as a language, but using it alongside existing js
libraries is awkward and error-prone, and getting the build process to work
smoothly takes way more time than it should. Cljs gets a lot right too, but it
shouldn't be held up as an example in this regard.

~~~
smnplk
Do you know about cljs-js ?
[https://github.com/cljsjs/packages](https://github.com/cljsjs/packages)

~~~
danenania
Nope, I hadn't seen that. Definitely helps!

------
Cyph0n
Nice writeup. Elixir definitely seems like a solid language for web dev. For
the frontend, I prefer Scala.js since I'm kind of a Scala fanboy, but I've
heard great things about Elm.

One little comment. At the beginning of the post, you make it seem like the
app needs to scale with the number of viewers, when in fact it doesn't. I
think you should clarify this to avoid confusion.

~~~
weitzj
We are doing a fairly large Elm app right now. And especially the refactoring
reasons and static type system are appealing to us when you work in a team.

Also being a functional language it is easy to crank out features in an
afterthought, e.g. we added an Undo/Redo feature for operations the user does
in this single-page client app. And being side-effect free this "merely" boils
down in wrapping function calls in an "undo/redo" function.

So Elm is really exciting stuff. But still the Api is not completely stable,
yet. So you have to invest some time to adapt to these (small) Api changes.
Also interoperablility with so-called "Native" JavaScript browser functions,
e.g. JavaScript typed arrays is possible but not finalized, yet.

~~~
david-given
Are you using ports much? The examples in the documentation aren't very clear,
and I'd be interested to know how much plumbing is required to talk to
external Javascript in real life.

~~~
danneu
It's not much.

On the Javascript side, the Elm `app` is like an event emitter where you
listen for updates and send it data.

    
    
        var app = Elm.Main.embed(...)
        app.ports.gameState.subscribe((data) => ...)
        app.ports.tileClick.send([x, y])
    

On the Elm side, you subscribe to incoming ports and map them into Msgs. And
you emit to ports with Cmds from your update function.

    
    
        -- Ports.elm
        port gameState : Json.Encode.Value -> Cmd msg  // Outgoing
        port tileClicked : ((Int, Int) -> msg) -> Sub msg  // Incoming
    
        -- Main.elm
        update msg model =
          case msg of
            Tick ->
              -- Define `encode` to Json.Encode the game state
              (model, Ports.gameState (GameState.encode data))
            TileClicked (x, y) ->
              -- Handle tile clicks sent in from Javascript
              
        subscriptions model =
          Ports.tileClicked TileClicked

~~~
david-given
Yes, but just like the ones in the docs, that's a nearly trivial example, and
so doesn't demonstrate the complexity.

What I'm concerned about is the case when I want to call a Javascript function
from deep down inside, say, a computation function. Do I have to split my
computation into two halves, one which sends the event which calls the
Javascript function, and another which receives the result of the function?
How do I pass the in-progress computation state from one to the other?
Normally in a functional language I'd get around this by simply passing a
function reference into the Javascript function which the handler would then
call, so allowing me to have both parts of the computation in the same place
and operating on the same data, but apparently in Elm function references
don't survive being passed through Javascript.

Plus, each port only has a single incoming event, so if I'm calling the
Javascript function from multiple places I can imagine it can very easily turn
into a labyrinth of state passing code.

How do you avoid this?

~~~
danneu
Some interactions with 3rd party libraries (like rendering stuff, leaflet.js,
pixi.js) fall along natural event-driven faults, like the game update tick
finishing, something managed by Elm being clicked, that sort of thing. In
these cases, ports (events) are the obvious fit.

Then there's synchronous 3rd party library stuff where you just want to
execute a Javascript function, like a math function that you aren't going to
reimplement in Elm. In that case, I wrap the function with a native module and
call it like an Elm function. Since you talk of computation, is this what
you're talking about?

The Elm community highly discourages native modules. For one thing, they
aren't very well documented and the API seems to have recently changed. But
I'm not sure what the alternative is.

~~~
david-given
Ah, right --- I _have_ heard of native modules, but only in the context of
things I shouldn't using. I'll look more closely. Ta!

------
kevinastone
> As a business owner/recruiter, I wanted something with a low entry barrier
> for my future hirings. Elm has a low entry barrier, the JS
> ecosystem/fatigue/mess doesn't.

This is nonsense. There's a much greater pool of talent familiar with
javascript than Elm.

Using Elm might be marketable ("come work with Elm here!"), but it's a riskier
bet for a developer given it's relative immaturity and adoption.

~~~
sotojuan
At this point the "come work with Elm" only works at places that have long-
term Elm experts and fans (e.g. No Red Ink which hired its creator, has their
lead evangelist, and probably more than half the top Elm people in the world).

------
qaq
Have not had time to try Elm yet but Elixir is such a pleasure to use, it's
painful going back to JS :)

~~~
comboy
Hopefully something grows out of
[https://github.com/bryanjos/elixirscript](https://github.com/bryanjos/elixirscript)
so far it seems very actively developed.

~~~
bryanjos
If issues such as source maps are figured out, I would feel better about
people using it. Also, I would like to work on its user friendliness.

Saying all of that, Elm is pretty nice and I really enjoy using it for some of
the same reasons I enjoy Elixir.

~~~
qaq
Source maps does seam to be the biggest issue to solve before people can start
truly experimenting. But huge congrats on starting and moving forward this
amazing project.

~~~
bryanjos
Thanks!

------
ggregoire
Even if you don't like JavaScript, it's really surprising to me that a CTO
picks something like Elm that nobody uses and only a few know or are
interested in [1].

I'm curious to know how the author will recruit developers, specially in
France. My last company migrated all its backend in Node this year, ONLY
because it was the easiest option to recruit full-stack developers. The market
is completely saturated here (there are a lot more offers than developpers),
you spend months to recruit a front-end developer or a full-stack developer
with front-end knowledge, and I don't see how you can attract someone with
Elm. Having 1 or 2 years of xp in Elm on a resume is not really usefull when
all the companies use JavaScript. You don't even know if Elm will still be
there in 2 years.

[1] [http://stateofjs.com/2016/flavors](http://stateofjs.com/2016/flavors)

~~~
biot
It's no different than listing a Java job vs listing a Scala job. There are
many great developers who would jump at the chance to be hired to write Scala
(Elm), so you might just end up with better developers who self-select to work
on the shiny, new technology.

------
todd3834
This was great to read and it inspired me to give both a try soon.

Question: Did the app receive millions of visitors or was it basically 1
visitor with millions of viewers via the television showing a recorded screen?

At first I thought Phoenix was used because of scaling reasons but now I'm not
so sure.

Either way, nice work and thanks for the write up!

~~~
sotojuan
In my experience, Phoenix is used because a) it's easy to get started with b)
isn't a monolith like Rails (e.g. Phoenix could be _one_ part of your complete
application) but it has good conventions and c) it leverages the Erlang VM's
performance and concurrency through Elixir.

I know HN gets a lot of hype for X new tech every month, but I'm really liking
Phoenix. Ignore the "Phoenix is the future/saved our lives/best thing ever!!"
Medium posts and try it out. It's actually pretty good.

~~~
matt4077
I'm enjoying working with phoenix, but when comparing it with Rails, it would
be fair to say "it's basically rails" and add a few footnotes about the
differences.

People who started after Rails was released don't see it because they haven't
seen how it was done before. But it's incredible how many conventions DHH
created with rails that have since entered the basic repertoire of all web
frameworks: migrations, its take on MVC, :belongs_to, the router DSL, the
asset pipeline, generators – while you can probably find prior art for all of
them somewhere, it's the implementation in Rails that, 10 years later, is
still the blueprint for new frameworks.

Rails was also the best teaching tool ever invented in the space. Code quality
was atrocious, people were reinventing "clever" solutions for every project,
testing was probably rare (I never saw it, but it must have been around,
right?) I distinctly remember a templating system that turn .xls into a perl
script that would write php. If you changed projects, you'd usually be greeted
by a directory tree 8 levels deep with the main config.php in
/[..]/tmp-2008_b, along with config.inc, main.html.php.old and
construction.gif~2.

(Not that Phoenix doesn't add lots of refinements that make it a pleasure to
use)

~~~
kinofcain
I'd add that Rails was also hugely influential in its focus on developer
productivity. A lot of it was magic and incredibly difficult to debug or
modify when it went wrong, but it raised the bar for how you market a
framework to developers.

~~~
brightball
Yep. The Dev productivity area is where Rails really set the bar high. All the
other "win the benchmark" stuff that everybody goes to to try to dethrone it
is a fair example of people missing the point. :)

------
dvcrn
So I saw Elixir+Elm, Elixir+Elixirscript, Elixir+Scala.js here so far.

Chiming in with Elixir+Clojurescript. It's what I've been using for most of my
projects these days and absolutely love it. Pure functional programming on
both, server and client, with the server concentrating on well distributed
concurrency and parallel processing with GenServers and the client on
immutable front-end code while using Go-blocks for async stuff.

------
mattetti
> Elm has a low entry barrier

Sorry Vincent, you lost me there. Elm is interesting for sure, but it's far
from having a low entry barrier. Something has basic has having a button play
a sound takes forever to figure out. You almost have to learn everything all
over again. It's a cool project and I'm glad it's working out well for you,
but Elm has a serious learning curve.

~~~
not-much-io
Just my 2c:

Paradigm wise: Yes functional programming can seem strange and hard if you
haven't done it before. But that really isn't the fault of Elm, elm makes FP
as simple as it can.

Language wise: Yes, the Elm architecture takes a bit to grok, but for me it
was just an afternoon. Once you grok it, there isn't really much else you need
to learn - you can hit the ground running, look up what you need when you need
it.

Tooling wise: Just some basic tooling you get will get you very far, no setup
either, just install and use.

If you do js interop, yes that can be cumbersome, but it is intentional. Elm
strives to keep js out and write libraries in Elm. This is so we can have more
of the guarantees that Elm provides. (no runtime exceptions!)

I'd rather say: "Elm has a low entry barrier for a FP language". One of it's
main goal is to bring FP to the masses after all. :)

------
leshow
I hope Elm doesn't get too closely tied with Elixir. It's a great language no
matter what backend you choose.

~~~
sotojuan
I also don't get why they're coupled a lot... they're very different once you
get past that they're both "functional" (and Elixir really just has HOFs and
immutability by default, it's very practical). If it makes you feel better, I
only see this coupling online. Most people just use server-rendered pages or
regular JavaScript.

~~~
s_kilk
It's really just a weird overlap in the communities. There's nothing tying Elm
and Elixir together aside from the anomaly where many people who started
experimenting with one also started experimenting with the other.

------
Ericson2314
Damn, look at this European protectionism /s.

(I'm a functional programmer, so yay for them!)

------
rhlala
_the guests were Nicolas Sarkozy (12 millions viewers), Arnaud Montebourg (9
millions) and lately Alain Juppé (13 millions)._

I would like to see the results of the two other guests.

~~~
conradfr
There has only been three shows so far IIRC.

------
conradfr
As a French trying Elixir these last few months (don't have much time for Elm)
it's great seeing the language picking up some hype.

At work I don't see it happening though, we're a PHP shop now addind nodejs
(to my despair) and maybe some Go. I think there is a Haskell fan and that's
it.

