Hacker News Reader

Comment by inopinatus | Hacker News Reader

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

View on HN

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.

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/

Phoenix is to Elixir as Rails is to Ruby - Elm and Coffeescript are mainly front-end considerations in this case.

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

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

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.

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

Reply on news.ycombinator.com