Why I Chose Elixir Phoenix Over Rails, Laravel, and Next.js

Thing is with Elixir though, yes the tools are right there, but you do have to take time to understand them. I've been on and off with Elixir since 2016 and I'm currently wrapping up on a fairly complex elixir project with zero UI. (connecting Shopify GraphQL to a series of 3rd party fulfilment providers who use SFTP (gross). So yes, GenServer, Supervisor etc are all right there as first class citizens, but whilst they are relatively simple to start using, you can end up with some horrifically structured code that would have been much better written without the distributed stuff.

Personally, I prefer Django. Been using it since 2006 and as a person who started off in design but ended up as an engineer, nothing beats Django's template engine (braces for incoming). Django isn't perfect but nothing is. When I have to get something done quick and there's UI work for me to do, I go to Django. When performance or no UI, I go elixir. If someone else is doing the UI, I go phoenix.

Maybe it is obvious in retrospect…

I mean sidekiq is tried and true

This particular bit does seem interesting and would make sense to take advantage of the BEAM's cheap green threads. Couldn't find any info on LiveView's GitHub landing page nor the Phoenix website (haven't dug too much), do you happen to have a link?

For example I have a small side project using LiveView where users would typically pull their phone out, quickly record data, then put it away again. But due LiveView only working with a connected websocket they often have to wait ~1s for the socket to reconnect, and get an annoying error message while it does.

I'm sure there's more I could do to configure this but the default at least is terrible. I believe with Hotwire I wouldn't have this problem, my view would just work and then restore the websocket when it can.

I use Phoenix and LiveView for a lot but I wish we could get more of these rough edges polished up.

This means in a vanilla PHP setup when i do something like this:

    $a = new Fiber(function () {
        sleep(2); // block
        Fiber::suspend();
        return null;
    });
    
    $b = new Fiber(function () {
        sleep(2); // block
        Fiber::suspend();
        return null;
    });
    
    // Start execution
    $a->start();
    $b->start();
    
    // ... later in code wait for both executions to finish
    $a->resume();
    $b->resume();

    
    // Total execution time is not 2 seconds, but 4

That said JVM is only a target, so if Java is not your cup of tea, you are free to pick and choose from any of the various JVM languages, like Clojure, Kotlin, Scala etc.

I hope you at least let devs deploy on whatever stack instantly with new projects and services with something selfserve-y like (Vercel/Heroku/etc).

Redis, postgres. I think there's a couple of commercial offerings.

solid_cable is a database polling mechanism which can also be swapped in.

What Ruby has though is ability to express what you are doing in a clear syntax. Elixir has a lot of ritual (albeit less than erlang) to set up your most used things like GenServer - you don't abstract away the concurrent flow (which is good, concurrency should be obvious), but you also wouldn't write elixir without it, so code inevitably becomes filled with technical concerns.

I'm biased, I write elixir for a living after a decade in Ruby, and I'm happy with that tradeoff. But there are times where you need to do an imperative thing and make it clear as day, and Ruby often does a better job here.

Rails is also somewhat more ergonomic for fast prototyping than phoenix. ActiveRecord is a blessing and curse, it's insanely productive for making things do things in minutes, but lacks composition later on.

As for raw performance I'm sure you'd get better deal with Elixir out of the box than Rails out of the box but if you wanted to keep all the benefits of Rails and scale websocket usage look into AnyCable.

Next.js server performance isn’t great either - honestly, it’s pretty bad. Pages don’t feel that fast for users despite all the tricks and optimizations. In my opinion, metrics like LCP and others are much easier to optimize in older, more traditional frameworks. Unless you’re building a full-blown web application, a classic web page will almost always be faster and simpler to deliver without all the Next.js complexity.

In newer versions, import maps are recommended instead. The problem is that import maps enforce ESM, while Sprockets (as far as I know) doesn’t support ESM at all. On top of that, there are compatibility issues with Turbo links, various form libraries, and the limited extensibility of the import map library itself - adding extra dependencies is just painful.

Installing CKEditor wasn’t straightforward either, so I ended up creating a small DSL to simplify it. But then came another challenge: providing support for custom plugins in a way that would work with every Rails version, even without a bundler.

All of this is made even harder by the fact that CKEditor is distributed in both cloud and NPM versions, which complicates integration paths further.

In contrast, Phoenix makes things much simpler. From what I remember, the standard setup uses esbuild, which automatically pulls NPM dependencies from the deps directory - the same place where Elixir libraries are installed. This means you can distribute a package that includes both the Elixir and NPM parts of the editor, without having to manually modify package.json or worry about dependency conflicts.

In some cases it's just not what you need and SSR etc are more important - then just use appropriate tools instead of forcing React to do that too

I don't mind picking up a contract for maintaining React code, but never again am I touching anything built by Vercel; unless I specifically crave the “automagically different every release” quicksand masochism of their tools. I'm sorry to the people working on, say, Next; these are qualified and talented individuals. But the DX over time, gods…

React is still a reasonable view library, although not a top choice at all (for me). Insisting on using it for SSR via Next is self-inflicted pain down the road.

sounds like you are using Elixir on Kubernetes. What is the experience and the reasoning with this? I was thinking about this and read on many blogs that it is somehow redundant because Kubernetes implements something like "let it crash" on its own when it's already an Erlang/OTP/Beam concept.

But I could be completely wrong (or have the wrong perception).

Note: not at all suggesting hardwork/progress isn't being made.

Are you giving this advice to every company in existent? Think about that for a second.