Elixir for Humans Who Know Python

The "visibility" of frameworks and the onboarding "ease" are important features for many reasons but there are more attributes that shape people's choices. Talking primarily about open source ecosystems, being able to economise on resources is a major advantage. A "hello world" web app or a "neural net without dependencies" might be quick to do in any modern language but one major pathway to add value is when non-trivial domains are represented in usable detail. This is where a community culture that promotes pooling resources behind a few core libraries or frameworks plays an important role. It enables building on top a second layer of abstractions, plugins, interoperable API's et. Django is one example but the Python world has also "one stack" for numerical calculations (numpy, pandas and friends) and that was maybe more instrumental for adoption.

I've been using Elixir with Phoenix and Liveview at my job for the past three months as part of a small team building a non-trivial web app (https://duffel.com/links). I'm mostly a front-end developer and was brought in to handle the UX side. Prior to this project I've spent the last 5+ years in the React world.

I found a lot of what the author says to be true. I'm used to the nightmare that is managing front-end dependencies, and it was refreshing to use something so 'batteries included' that comes with most of what I need.

It took me a while to get my head around the Phoenix + Liveview way of doing things, but when my mental model clicked into place and I stopped trying to do things the React way I became a lot more productive. When I had an autocomplete updating live as the user typed all going over the websocket without me writing any JS, it felt magical.

However I definitely found a lot of sharp edges that the author doesn't mention. We struggled a lot with any non-trivial UX, for example with the autosuggest mentioned above I had to add a lot of JS to handle things like being able to use the keyboard's arrow keys to select options. Whenever I jumped into the JS world it often felt like I was fighting against Phoenix, and had to resort to using 'phx-ignore' a lot. It was frustrating to continually struggle to do things I knew how to do easily in a pure JS environment.

Another area I struggled a lot is Elixir's syntax. To me, it feels like there are too many operators. The author touches upon it towards the end when they mention things like '\\' for default arguments, '' for joining strings and '++' for joining lists. It's a lot to wrap your head around at times.

Some of the fault for this lies with me; we were working to a tight deadline so I didn't have time to dedicate to learning Elixir, Phoenix and Liveview from first principles, I just jumped in out of necessity. Had I spent more time on the foundations first I may have been able to avoid some of these pitfalls, but I do think it illustrates that like many 'do everything' frameworks, there's a steep learning curve to doing non-trivial things. It's a powerful tool and I'm optimistic about its future, but I'm undecided if I'd choose it for a future project that has significant front-end requirements at this stage.

> “On the other hand, I agree with you that everything that Phoenix generates through its phx.gen generators are for demo purposes and will get thrown away eventually.”

The parent didn’t say that and it’s not true in my experience writing Phoenix apps over the past six years. I usually add to the generated contexts, controllers or now live views, but I often leave the migrations as is. Even when making a migration to edit an existing schema, I still use the Ecto generators. The _only_ thing I’ve often thrown away large parts of was the template.

I’ve taken over about as bad of a Phoenix app as you can imagine (made by a rotating cast of outsourced contractors over years, no use of Ecto relations, no use of “resources” (just get and post), not using built-in validations, pinned to a version of LiveView from two months after its initial release… and using jQuery to drive it). Due to Elixir’s immutable, functional nature, rehabilitating the code base has actually been a bit easier than some Django apps I’ve seen. The most painful part has been unraveling the jQuery.

IMO, Django still hasn’t caught up with 2014 Rails.

It sounds like you were able to be reasonably productive without even any time to learn the framework, so I’d say you did alright!

I’d say up until the recent focus on LiveView, Phoenix has been very easy for devs with experience with Rails or Rails clones in other languages to learn. Recently, with all the LiveView changes and the new components, it’s been harder, but I think it’s finally stabilizing a bit and I’ve got to say the newly-released Phoenix 1.7 is another significant step forward in terms of productivity for new apps.

Serious question—if you were on a tight deadline, why did you choose a tech stack that you still had to learn? Leveraging existing knowledge is exactly what anyone in a rush should be doing.