Elm is a great frontend framework and it works splendidly with Phoenix as an API layer.

I feel that most comments about lacking websocket support or the fear of ports are largely FUD, since ports are a great (i. e. streamlined and safe) way to do interop. The thing you need to account for is: you cannot do synchronous calls to a JS library through ports.

Elm is in my opinion also a good match for Elixir since it also defaults on immutability and functional concepts while programming (e. g. it uses map and reduce for iterating through lists). It also has great documentation for most things.

But Elm (as well as React and nearly all other FE frameworks) manages its own application state and you absolutely should have a solid usecase that justifies introducing this complexity. The main reason one uses these frameworks is to provide a user experience where interactions feel instantanious. My feeling is that this is, in most cases, not enough to justify introducing what is essentially distributed computing.

So I tend to use the following algorithm:

1. Is this a project with an existing stack? If so: use whatever is there!
2. For green field projects: use standard Phoenix unless
3. I need interactivity (form validation, notifications, …): use LiveView unless
4. I need local state (e. g. for games): use Elm/React/Vue/… components rendered as part of the Phoenix template unless
5. I need true offline support: use Elm (I typically cannot afford runtime errors in these scenarios)

This is interesting! Would you care to elaborate what the features were you could not implement, or felt were not a good fit for LiveView?

This is covered by point 4) in the list. What I tend to do is to render a component inside a normal Phoenix template (e. g. <div id="componentRoot"></div>) where I then render a JavaScript application that can also call API endpoints or react to websocket messages if it must.

But I keep the navigational logic in Elixir and Phoenix. That way I can leverage established standards for authentication and authorization - and this is a huge win. (But this is a pet peeve of mine, so please take it with a grain of salt )

But I assume that you have something specific in mind. Could you extend on that?

No. Elm is in my opinion the best choice for frontend/SPA development by a long shot. That is not to say it is perfect. In fact far from it. But is still the best option for beginners and seasoned programmers. In fact that says a lot more about the competition then about Elm, but I stand by that.

I have (professionally) developed and / or supervised projects in Angular (1/2/…), React(Native), Ember, Vue, Hyperapp, Elm, jQuery(-UI) and Reagent (ClojureScript) and with the exception of Reagent and Elm all of those suffer from long term […] rot in my experience.

(I just deleted five paragraphs… ranting is not too productive )

There are three cases where I’d advise against using Elm (after having decided that you need a frontend framework):

1. When you need to be able to show off proficiency in JavaScript or a specific framework.
2. When you hate beeing bossed around by your tools (or doing things thoroughly)
3. When you need to use specific, ready made things that do not integrate with Elm. In which case point 1) from my algorithm takes effect.

Acutually I cannot. There are so few resources because there is not much to it. You can use the package you’ve found which looks quite good but actually there is no magic in it:

• Using a Phoenix REST/GraphQL-API is simply using those APIs
• Using sockets is not more than using the standard Phoenix socket client, setting up an Elm port and sending messages over this port whenever they arrive

That’s it.

That beeing said: this is my experience with all these technologies. In the end whatever you choose needs to be what you’re comfortable with.

(Reflecting a bit: ClojureScript with shadow-cljs might be a worthy contender to Elm in certain situations, but oh boy is that not beginner friendly )

Elm dropped Websocket package a longggg time ago and haven’t added it back yet. So you have to use Port™ for that. When it comes to SPA, people use Phoenix Channel with them, the frontend stuff.

I’d say go for it, inevitably write JSON Encoder/Decoder and see if you like it, it’s not very hard but cumbersome for many people. Elm also lacks of libraries, if your app UI is not trivial, you have to write your own. You can wrap JS lib within HTML Custom Element and use as a regular node in Elm, as long as the libs do not mutate DOM and confuses Elm runtime (and crashed)

–advance–
You may not encounter this downside of Elm VirtualDom, but Html.Lazy is almost impossible to optimize at non-root level (short explanation is; Elm lost object references almost all the time, ref equality check easily return false)

I’d say list a couple UI/UX features you want to implement and re-evaluate frontend stuff again. VirtualDOM is already an unnecessary for declarative UI development, try evaluate Svelte, the simplest “language & framework”.

-advance-
Try Solidjs or start small with https://github.com/WebReflection/uhtml/blob/master/DOCUMENTATION.md (JS Template Literal based with some event/attrs binding)

Again, what you are going to implement is important.

list a couple UI/UX features you want to implement and re-evaluate