Functional language choices for elixir front ends?

I’m working on a new side project, which I’ll backend with Elixir. The front end will be a multimedia tool with a non-standard gui, interacting with webaudio API and HTML5 Canvas likely. I’m curious what opinions are in the Elixir community on platforms for doing rich media FRP in the front end. Right now I’m looking at Elm, ClojureScript, and maybe PureScript. Anyone have pros and cons opinions on those with regard to learning Elixir?

1 Like

At the end, they all compiles to JS…

Maybe You should mention Bucklescript and ReasonML. The later being pushed by FB as a way to introduce JS programmers to FP.

Probably You should choose between

  • Clojure -> Clojure script
  • Haskell -> Purescript
  • OCAML -> Bucklescript, ReasonML
  • ? -> Elm

I am not sure what is the root of Elm. You can also try to go FP with vanilla JS.

I would choose something from OCAML as a personal choice…

2 Likes

how pure?

I’m having a good time with react and rxjs - aka redux-observables - the structure with reducers, “epics” and “ducks” gets very genserver-ish for your UI/data handling…

of course looking forward to reasonml, not sure if the tooling for reasonml and react is there yet.

Both Haskell and OCaml, bits of both, but lacks a lot in comparison.

1 Like

Right now I’m looking at Elm, ClojureScript, and maybe PureScript.

ClojureScript: While you get immutability by default you don’t get compile time static type checking as you get with the others.

Elm: Good beginner experience - but some people, once they get to a certain point, feel too constrained either by Elm itself (they want type classes and higher-kinded types) and move on to PureScript or by the “The Elm Architecture” (e.g. its single source of truth).

Now one issue is your reliance on the Web Audio API and Canvas API. Being browser based these APIs are designed for use with JavaScript (dynamically typed, mutable and object-based). Any of these languages require some JS-Interop ceremony but Elm tends to be the most rigid and elaborate. Now there are some efforts like elm-webaudio (which doesn’t look like it’s been used with 0.18 yet) and elm-canvas but even elm-canvas suggests looking at elm-graphics or WebGL for Elm instead.

PureScript: My guess is that it has the steepest learning curve - especially if you haven’t already dealt with Haskell yet.

4 Likes

Thanks for the tips. Do you think that as far as interacting with Canvas and WebAudio that ClojureScript would be the best choice then? I’m used to dynamic languages (Python is my day job) so if the bar for canvas and audio interop is lowest in ClojureScript that’s a big point in its favour for me.

There seem to be several web audio libraries to keep the experience more Clojure-like - here is an example of what interacting with the canvas API looks like.

I’m used to dynamic languages

Yeah, but it feels like a shame to pass up on proper compile time type checking if you already have the burden of transpilation (Mareo/ReasonML 3).
cljs-mario

1 Like

Well the conversations on this board have been enlightening, and now I’m quite curious about Bucklescript. Can anyone comment further on whether Bucklescript would work well for making a dataflow type system of components reacting to streams (ie real FRP)? The stuff I’m planning involves components that use canvas and webaudio, and are hooked up in dataflow style (think PureData, MaxMsp, etc).

Thanks!

There are OCaml libraries that already implement FRP full and proper that you could use if wanted (bucklescript is just an OCaml backend).

Thanks. Any in particular you’d recommend?

I’ve not used them myself yet so I cannot comment on that regard. I have this habit of making my own styles… ^.^;

Thought I’d post an update here in case others are checking out this thread. I have chosen ClojureScript over Elm for now, with an eye to learn Bucklescript down the road. I really like the health of the ClojureScript community and the variety of well established projects around React and React style development. There’s Reagent with Reframe, or Rum, or Om.Next: you have a wide choice of minimal to maximal toolkits, all with very healthy project activity. And the hot loading from figwheel in the browser is insanely productive. So if you’re a dynamic language lisp fan, I’d really recommend it.

Elm I wound up ruling out over the fact that it’s largely a one-man show, and a one-trick pony. If you decide you don’t want the architectural choices the main dev is choosing, you’re stuck. There is a lot more opportunity in cljs for writing your app without being married to one tool kit and it’s choices.

All that said, I’m bullish on Bucklescript and ReasonML as things that will blow up in the next couple of years and am definitely going to learn buckle. I think facebook’s choice to position ReasonML as the ocaml gateway drug with a low barrier to entry while cooperating with Bucklescript is going to be huge for driving adoption.

Thanks for the tips everyone!

6 Likes

I’ve heard this is quite good, I’ve been meaning to look in to it. :slight_smile:

If you don’t necessarily want to use a »real« FP language, you could try to use a JavaScript module that offers methods for functional programming. Examples of this are lodash/fp and Immutable.JS. This gives you the obvious advantage of being able to interact with any other JS modules more easily and not needing to learn a new language.

lodash/fp even has a construct similar to Elixir’s pipe plus automatic currying:

import _ from "lodash/fp"

const plusOne = _.map(x => x + 1)
const timesTwo = _.map(x => x * 2)

_.flow(
  plusOne,
  timesTwo,
  _.sum
)([1, 2, 3])
// => 18
2 Likes

Ramda (Thinking in Ramda) is another example

const f = R.pipe(R.add(1), R.multiply(2))
const g = R.pipe(R.map(f), R.sum)
g([1,2,3]) // 18
2 Likes