What are everyone’s thoughts and opinions on front-end tools that are complimentary to Elixir/Phoenix?
There seems to be a multitude of front-end libraries and frameworks, and new ones announced continuously. Some that seem to be getting a lot of attention are react.js, angular, elm, etc.
One that I just discovered yesterday is SAM. At first glance, it seems to have much in common with Elixir/Phoenix.
So, what has been everyone’s experience with or thoughts about the front-end tools in terms of meshing with Elixir/Phoenix, not only from a programmatic interface point of view, but also from a programming paradigm point of view?
I’m glad you posted this thread as I want to evaluate what to use with my first Phoenix app too.
There is also an Opal Phoenix wrapper if you like Ruby.
For Ruby projects I would look at one of the front end frameworks, of which there are now many: Volt (which is an isomorphic front and back end framework) Clearwater, Inesita or just plain Opal. There is also React.rb a Ruby wrapper for React.
I come from a frontend development background, so I’ve been trying to keep up with the evolution of different frameworks/libraries. I haven’t built a Phoenix app yet, so my thoughts are based more on intuition/research than experience (so take with a grain of salt). My general impression is the industry is gradually shifting toward React.
That SAM architecture looks very interesting. I will need to read that article a few times to understand it completely. Most of the articles I’m finding are complementary about React with Redux (which was inspired by Elm architecture) and GraphQL, so it is interesting to read an alternate viewpoint.
For better or worse, however, I think the React/JSX/Redux combo will be around for a while because:
- React is backed by a huge company
- I haven’t seen anything that really compares to React Native yet
At about 11:40 into this video from ElixirConf 2015, Chris McCord talks about how some of the ideas behind GraphQL and React may inspire the next version of Phoenix.
This apparently caused some people to think that GraphQL would become part of Phoenix which is not accurate. Jose Valim clarified this on Hacker News.
Thanks for that post @MichaelC, I hadn’t see Jose’s post on HN - which is good news - I’d hate to see Phoenix become tied to anything owned by FB:
I am member of the Phoenix team. We are not adding GraphQL to Phoenix. What Chris McCord said in his keynote is that some of the ideas behind GraphQL/Falcor, like co-locating your query with your view, is also useful on the server side because it makes the code more maintainable (for example, you no longer need to write a big query in the controller with knowledge of all the view pieces). It also makes views easier to cache, easier to detect when the cache is expired, easier to compose and so on.
How that will affect Phoenix is yet to be seen but developers shouldn’t expect a big departure. In any case, if folks want to build their own package that provides GraphQL/Falcor server and clients on top of Phoenix, by all means, go ahead and have fun!
Elm certainly seems like a step in the right direction, and it’s great to see so many people here interested in it (perhaps a little unsurprising given both it and Elixir are functional languages).
In this podcast interview, Chris McCord said that the space is split between Ember and React, while React made the most sense to him.
I have found that elm + phoenix mesh very well together. If you set it up right, anytime you make a change to an elm file it will automatically refresh for you just like your elixir code. Alan Gardner wrote up a great blog post on setting up elm with phoenix, and the workflow is about as smooth as it gets
Elm + Phoenix
Elm and React. Anything that won’t require a 100% rewrite of your front-end is fine. Ember/Angular are fantastic, but they require that you go all-in for the full application, and you would like to gradually upgrade in most cases.