Live data from Hacker News

Elm and Phoenix/Elixir in Production for France TV

vincent.jousse.org

21–30 of 80 posts

Re: Elm and Phoenix/Elixir in Production for France TV

#21
post #3

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…

> Elm apps are a single blob of JavaScript that either loads or doesn't

This is what bothers me about Elm. In the next few months, I'll be starting on a site project, and I've been fiddling with Elm and I don't see how I can create progressive web apps with it. It doesn't seem to play well with service workers for an offline mode, and there's no fallback if Javascript is disabled. Either it loads or it doesn't.

I want to use Elm, I don't want to use JavaScript, but I also want a progressive web app that will offer some functionality offline. I guess there's a way to do some server-side stuff with Phoenix, but then the front-end / back-end division isn't so clear and I'd end up using JavaScript for the service workers anyway.

I've not looked super deep into this, so I'd be happy to be corrected if I've got the wrong end of the stick here.

Re: Elm and Phoenix/Elixir in Production for France TV

#22
post #7

Earlier quoted context omitted.

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 t…

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 ta…

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.

Re: Elm and Phoenix/Elixir in Production for France TV

#23
post #21
post #3

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…

> Elm apps are a single blob of JavaScript that either loads or doesn't This is what bothers me about Elm. In the next few months, I'll be starting on a site project, and I've been fiddling with Elm and I don't see how I can create progressive web apps with it. It doesn't seem to play well with service workers for an offline mode, and there's no fallback if Javascript is disabled. Either it loads or it doesn't. I wan…

Its true that you can't currently write a service worker in Elm. However, in practice for any decent size app you are going to end up with a mix of Elm and Javascript with communication happening through ports. Therefore you can write the service worker in JS and then talk to it from Elm.

Of course it would be nicer to be able to write everything in Elm, but I find having the majority of your app in Elm with a bit of JS is significantly nicer than having the whole app in JS.

You can make it nicer still by using Typescript instead of Javascript, and defining interfaces for the data going through the ports, giving you type safety across the whole stack.

I'm using this approach right now in a mobile Elm/Typescript app with great success.

Re: Elm and Phoenix/Elixir in Production for France TV

#25
post #4
post #2

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.

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…

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.

Re: Elm and Phoenix/Elixir in Production for France TV

#26
post #7
post #6

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!

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 t…

Fwiw, I'm writing a Phoenix is the Future post at the moment that I hope to publish in the next month. :) Might have to revise the title.

Re: Elm and Phoenix/Elixir in Production for France TV

#27

Earlier quoted context omitted.

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 ta…

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.

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. :)

Re: Elm and Phoenix/Elixir in Production for France TV

#28
post #4

Earlier quoted context omitted.

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…

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.

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

Re: Elm and Phoenix/Elixir in Production for France TV

#30
post #29

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

Most people seem to be coupling the two together based on getting into functional programming. It also doesn't hurt that the Daily Drip, a great Elixir "Railscasts" clone also has a section for Elm.
Post reply on HN