I’m mid-project on a small webapp with a Elixir / Phoenix back end and Elm front end. The Phoenix app uses Absinthe to create the GraphQL endpoint. The Elm app communicates to the back with elm-graphql.
It works. It’s pretty cool. I wouldn’t recommend it. The app we’re building is fairly small and straight forward with 5 pages and if it were a straight Phoenix/Liveview app it would have been done in about one third of the time. I’ll be charitable because this is our first Elm project outside of a tutorial and say that adding Elm and GraphQL roughly doubled the implementation time.
Absinthe automates most of the set up for the graphql endpoint, but it has some rough edges that elm-graphql package dogmatically turns into some nasty types like Maybe (List (Maybe Foo)) that then add a lot of clutter to your Elm code. The Elm-graphql library illustrates what I feel to be a big rift in the philosophy of writing documentation between the Elixir and Elm communities. Elm docs for most packages generally feel very incomplete and are coupled with a few meager examples that are equally poorly documented.
Mostly I feel that by the time you set up an API and a front end SPA you’ve taken away all the big productivity boosters from Elixir/Phoenix/Ecto web apps. There’s also a very big paradigm change every time you switch contexts front-to-back end since Elixir has a lot of conventions built into it (productive as long as you follow them) and Elm is more “here’s a few powerful tools to go write whatever you want”. There’s no real synergy gained by the combination.
I feel like I’m the only person so far with a negative take so I’m watching this thread closely to see if there’s something I’m missing.
As someone who really loves writing apps in Elm, I find Elixir & Phoenix to be my preferred choice of backend. Especially now that it’s possible to integrate Gleam with Elixir to get more type safety on the backend.
If you’re coming at it from the other perspective - that you love Elixir and want to choose a front-end option - you may or may not enjoy Elm. I think the mindset is a bit different between the languages. Elixir is much stronger on all the non-core-language-related parts of developer experience - documentation, frameworks, testing, tooling - and getting productive quickly. Elm’s strengths mainly relate to its type system & compiler, which make it easier to model data, write correct code without so many tests and do huge refactors without much risk. I think Elm also scratches the itch of helping you learn a bit more about the mathematical aspects of programming, if you’re interested in that stuff.
Between the two languages, I guess it depends where you sit on that spectrum as to what you value more - practicality or… I almost want to say, beauty. I quite enjoy using both because it’s good to keep my brain working in different ways!
I have to say, though, that I am a part-time, solo developer (I did write an Elm/Phoenix system that we use at work, but mostly I just do hobby projects for fun), so I can’t say whether Elm + Phoenix is a good choice once you factor in all the additional complexities of working in a team, etc.
Hey, thanks for the feedback! I’m actually a hobbyist solo developer myself, so I’m specifically looking for a stack that I could use to work on my personal projects. I primarily value tools that would allow me to iterate quickly but at the same time wouldn’t hold me back if I wanted to increase complexity.
Oh then I probably should not have deleted my five ranting paragraphs
Again, my main take away is: don’t resort to “frontend all the things” without a propper use case!
This completely sums up my experience with this library although for the one specific problem you mentioned:
You need to make sure on the backend that values you don’t want to be Maybe typed are not nullable in the API schema. Otherwise the generator is completely correct to assume that you could receive a Maybe in your API. Once you typed the schema correctly, the generator will happily produce a List Foo type.
For sure. This was in graphql schema generated by absinthe-relay, so not directly accessible by me. The flag to make the list and its contents not nullable is in master for some months, but not released. This is only an annoyance for a consumer like Elm. In regular js the developer can realize that the pagination will always return a list that’s empty or contains non-nulls, but elm makes you handle the [null] case. Sure it’s more “correct” and you can guarantee no runtime error. You prevent some errors that way but in that case it wasn’t going to happen anyways and now your code has a little more confusing clutter.
I have been using Elixir and Elm for quite some years now, and I just love the combo.
I know LiveView is the new hotness for many developers and do not begrudge that.
I love the simplicity and the philosophy of Elm. I do not agree that it is limited in interop, as has already been said, ports rock.
I have written several large Elm/Elixir apps, some as an SPA, some with Phoenix doing the routing, and am currently writing a new dashboard for our clients to manage their hotspots with elm-spa, elm-graphql and absinthe. In the past we have used Elm to transition one of my clients system from Rails to Phoenix.
My personal preference, as I am definitely NOT a front end developer, is to use Elm on the front. It gives me the assurance that my code works and all my bases are covered.
My brother, also a long-time developer, developed an offline-ready Elm SPA, that interfaces with indexedDB and he loves it, even though he is using Rails on the backend (for now…).
In my company we have a small backoffice app running on elm/phoenix combo. While initially great for development, elm turned out to be a bad choice in the long run. Integrating elm with frontend js libraries is difficult on 0.18 and almost not possible on 0.19. Support for new js/dom features is nonexistent. We are stuck on elm v0.18 with no easy migration path - most of the elm libraries we use were never ported. Build tools stopped supporting 0.18 2 years ago so we are stuck on old webpack/node also. The language itself introduced massive breaking changes in 0.19. We are considering a rewrite in react/vue/live_view.
I am loving this combination so far within a large codebase.
For people who have some rendering on backend in addition to the majority on front end, how do you organize and share css between backend and frontend. That is, do you use elm-css and separate css on backend or actually share by using sass?
although for the one specific problem you mentioned:
