For OP's criteria it works. It's relatively simple (by today's standards), it's full-stack, has everything out-of-the-box. Getting started is as easy as it gets (in 2021).

What would you choose?

Elixir Phoenix. It’s what rails copied for the Hotwire stuff. With distillery you can compile all of it, css, js, images, html, down to one tarball that you unpack and run as a service placed behind a forward proxy for complex setups or standalone if desired. Plus it’ll blow the doors off a Rails app performance wise, measured in micro not milli seconds, and will deploy on a fraction of the resources. Plus the community is filled with ex rails devs who left ruby for elixir so it has a very familiar feel if you come from Rails.

> It’s what rails copied for the Hotwire stuff

It is not. From the outside the end result for the user might be similar, but that's where the similarities end. Elixir's LiveView what I assume you're talking about keeps state on the server, in memory, and sychronizes changes back to the client over a websocket. Hotwire is "stateless" in the sense that no end user state is kept in memory on the server across requests. You can also use most of Hotwire without websockets.

My previous company was using Elixir, and they moved away from it because everything took longer to develop, the ecosystem of libraries was very lacking, the tooling (such as editor support) was terrible, and it was very difficult to hire experienced developers.

Performance wise, I agree, it is faster and you will use less servers. A nice problem to have to be honest.

When I say copy I don't mean implementation but inspiration. They may not have copied it exactly in implementation, it is FP vs OO, but stimulus.js was a direct response to LiveView. I don't think there is anything wrong with that however I welcome any advancement that requires less JS.

If we're talking about inspiration, then maybe it goes the opposite way? Given Turbolinks existed many years before even elixir or phoenix existed. In fact the creator of elixir was a very prominent rails dev.

But I insist, they have almost nothing in common other than maybe the end user result. The approaches they take are architecturally very different and with very different trade offs.

They're his words not mine. Go fight with him if you think otherwise https://www.youtube.com/watch?v=Of1phFsC4ZI&t=3290s

I'd argue against that. Recently, I tried making a few test apps with Phoenix and Rails to get my feet wet with something different (I write Go, Java and PHP in my day job), and with Phoenix I ran into a few issues getting the environment set up, the guide doesn't seem to be as coherent as the Rails dev guide, and there is no matching the resources available for Rails compared to Phoenix.

It'd be great to see that change over time, but to be honest I'd be more excited to see some movement behind the crystal lang, because I love coding in Ruby. All of my side projects are now being written in Ruby because I don't need something that scales in microseconds, or 10's of milliseconds for that matter, and I feel so much more productive.

Again, I hope I'm proven wrong. I think Phoenix has a lot of potential, but it still has a long way to dethrone Rails.

Not a knock on you but maybe you're too new to Rails too.

I've been using Rails for 10+ years now and setting up a phoenix app is very intuitive. A lot of "oh this is like X in Rails". IME most of the complexity was around JavaScript and that's changed with esbuild.

However it sets up with very similar patterns to Rails. Something I'd expect as it's creators came from Rails. Usually the differences are specific to FP vs OO.

Admittedly coming in from another language especially with an OO background would be harder as it's a smaller community than Rails and doesn't have 10 years of documentation sitting out there. That said documenting elixir code is much easier IMO, so that is sure to change. Also the scope of FP languages requires significantly less documentation IME.

The only thing vs Rails that I have found somewhat needing more attention in Phoenix is SSO integration but it's there and progressing especially with the Phoenix 1.6 changes.

You'd argue against using a framework for a project because you encountered a few issues (which ones?) setting up the environment, and recommend another one because you love coding in ruby?

Do you realize how biased you sound to be?

He's arguing from his opinions and experiences. Say he is biased, is true but irrelevant. (Water is wet)

The original post literally asked for a framework that's "simple and joyful" to develop in. So subjective (biased) opinions definitely matter on this one...