I tried for ~18 months but eventually threw in the towel.

I was super impressed with Live View when it was first announced, so then I started building my app without Live View since at that point LV wasn't open source.

Things were moving along slowly but surely. It was slow for me because Elixir isn't the easiest language to learn if you're coming from Ruby or Python -- at least it wasn't for me.

Then LV went open source and got a few pre-1.0 versions under its belt. So then I decided to rewrite my app using LV. This was a grueling process because there's very little docs (at least 6-9 months ago in case things have changed), and almost no community resources around it. So I was asking a lot of questions and getting stuck but eventually I got most of it working (although it was in a very inefficient manner) with the help of a bunch of people who were kind enough to answer my questions.

I ran into issues left and right and ran into some really big concerns like not being able to detect if CSS or JS bundles changed on a LV driven page (I went all-in with LV and developed my whole site with it). So I opened a discussion about that and a few days later Phoenix and LV were patched to have that behavior which was an amazing turn around, so really, hats off to Jose and Chris.

But that really scared me a lot. It scared me because the CSS / JS bundle issue is something Turbolinks has solved like 5 years ago and it's something you would encounter when deploying your first application with LV. I didn't even get to the point where I was ready to deploy it, but I was getting close to MVP status so I was marking items off my check list.

What I'm getting at is, and maybe I'm totally off base here is that, if anyone on the core team were using LV in production then this issue would have been addressed long ago. It really shattered all and any confidence in using LV. I know as of today https://bytepack.io/ (Jose's SAAS app) is powered by LV, but it's being developed behind closed doors and seems to still be in a pre-shipped status so we don't really know what's happening there on the dev side of things or how the app looks and feels.

Also my app requires a decent amount of uploading and about a year ago uploads with LV were "on the horizon" according to the author of LV. It's now a year later and the latest 2020 ElixirConf keynote talked about file uploads. It's still not available yet and given my experience with the CSS / JS bundles, I'm not really sure how battle hardened the uploader will be initially. I know someone has to pioneer new features in production but I'm a firm believer that initial burden should be on the developers of the library. Sort of like how Rails usually fully bakes features into Basecamp for months before extracting them out into Rails so the community can test them.

It's nice to see the core team is building a real application using the technology they are developing. This is IMO why Rails is so successful (Basecamp was the focus from day 1). Phoenix IMO has a lot of catching up to to do and I hope one day it gets there because there's a lot of great things around the ecosystem of the language in general. However for now, I've stepped aside with intent to consider it again in a few years. It's unlikely I'd rewrite my current app in it then, but maybe the next one.

I hope no one takes this as a personal attack on Elixir and Phoenix. This has been my experience and I hope nothing but the best for Phoenix / LV in the future. I still do want to use it, eventually.

Also if anyone is wondering why I didn't just bail on LV and use Phoenix directly with "dead views", it's because I determined the juice wasn't worth the squeeze. A web server takes in HTTP requests and returns an HTTP response. We can do that in any modern framework and still get 100ms or less response times on low powered DigitalOcean servers without things becoming an infrastructure mess. Web server + background worker + Redis + Postgres can go a LONG ways in almost any stack. It seemed like I could get my app off the ground much faster using a language and framework I'm familiar in, with a much larger ecosystem of libraries to leverage.