3 ms·

> Otherwise, it will dwindle away soon into the endless annals of forgotten languages. The opportunity I perceive for Elm to avoid this fate is Phoenix adoptin

> Otherwise, it will dwindle away soon into the endless annals of forgotten languages. The opportunity I perceive for Elm to avoid this fate is Phoenix adopting it in the default new project, in a similar fashion to Rails adopting CoffeeScript.

ams6110 10y ago
But why would they use Elm instead of Elixir as the language? There is already at least a start at a Erlang Javascript parse transform: https://synrc.github.io/shen/ https://synrc.github.io/shen/
- shadefinale 10y ago
  Phoenix is to Elixir as Rails is to Ruby - Elm and Coffeescript are mainly front-end considerations in this case.
  - ams6110 10y ago
    Yes, perhaps to clarify: I mean why not have Elixir be the language that compiles to JS, rather than Elm. Then you only need one language for frontend and backend (in the context of a Phoenix app).
- dragonwriter 10y ago
  > But why would they use Elm instead of Elixir as the language? The same reason Rails would use CS instead of Ruby -- its a lot less work to leverage an existing front-end language than to build a rock solid compile-to-JS option for your existing backend language.
moosingin3space 10y ago
Phoenix seems to delegate front-end stack management to brunch.io, which supports Elm.
sotojuan 10y ago
This would be an easy way to make no one want to use Phoenix. Elm is just way too different and the truth is that while it's cool it's an ML so it's "weird" and most devs seem to be doing fine with just modern JavaScript. Having to either learn a new language or remove a plugin just to get something basic going would suck. ES2015+ is the CoffeeScript of Phoenix. And like moosingin3space says, Elm support is just a plugin away.
di4na 10y ago
Chris is quite big on saying that he chose Brunch because it is working quite well and avoid him to even touch the frontend. I bet Phoenix will not make a so heavy choice on frontend and keep the default to vanilla js.

ams6110 10y ago

But why would they use Elm instead of Elixir as the language? There is already at least a start at a Erlang Javascript parse transform: https://synrc.github.io/shen/ https://synrc.github.io/shen/

shadefinale 10y ago
Phoenix is to Elixir as Rails is to Ruby - Elm and Coffeescript are mainly front-end considerations in this case.
- ams6110 10y ago
  Yes, perhaps to clarify: I mean why not have Elixir be the language that compiles to JS, rather than Elm. Then you only need one language for frontend and backend (in the context of a Phoenix app).
dragonwriter 10y ago
> But why would they use Elm instead of Elixir as the language? The same reason Rails would use CS instead of Ruby -- its a lot less work to leverage an existing front-end language than to build a rock solid compile-to-JS option for your existing backend language.

moosingin3space 10y ago

Phoenix seems to delegate front-end stack management to brunch.io, which supports Elm.

sotojuan 10y ago

This would be an easy way to make no one want to use Phoenix. Elm is just way too different and the truth is that while it's cool it's an ML so it's "weird" and most devs seem to be doing fine with just modern JavaScript. Having to either learn a new language or remove a plugin just to get something basic going would suck. ES2015+ is the CoffeeScript of Phoenix. And like moosingin3space says, Elm support is just a plugin away.

di4na 10y ago

Chris is quite big on saying that he chose Brunch because it is working quite well and avoid him to even touch the frontend. I bet Phoenix will not make a so heavy choice on frontend and keep the default to vanilla js.