The One-Person Framework in Practice

Joy was a key reason I chose Clojure.

I've been slowly / occasionally dipping my feet into Elixir / Phoenix dev over the past year or two, building an app idea that's been floating around in my head for a while. It's a bit of a steep learning curve for me, coming mainly from Python land (Django / Flask / FastAPI); I understand that it's designed to be a gentler learning curve for those coming from Ruby / Rails land. Phoenix is also a lot less mature / less feature-complete / less thoroughly-documented (than I had hoped, and) than Django / Rails (many of my Phoenix questions I've only found answers for in the forums, rather than in the official docs). Nevertheless, I agree, BEAM / Elixir / Phoenix is awesome, I'm hoping to get into it more in future.

This was my first impression too but I wasn't sure it covered the OPs convention over configuration stipulation.

Elixir/Phoenix is far and away my favorite framework to build with, but it does leave some things up to the user in a way that Rails doesn't, eg: there is no automatic `class name -> db table` mapping, or automatically inferring what partial or form names to use by a variables name.

In my mind, this is not a downside and there are still idiomatic ways to write Phoenix code, but just to outline some philosophical differences I guess. In the end I much prefer it because everything's a bit more explicit and flexible when I want it.

I think Phoenix also expects read documentation around OTP if you want to really achieve high leverage. This is worth it, and you can sort of drip feed yourself by starting with Phoenix, recognising that Phoenix primitives [sic] are actually Elixir primitives are actually just OTP primitives and you end up with some pretty good examples of how OTP works in a system you're already familiar with.

I highly recommend checking out Elixir & Phoenix.

Elixir + Phoenix is amazing. It's one self-contained stack. Just Elixir processes (and Postgres) which takes care of everything other ecosystems farm out to extra services. Background jobs, real-time channels, and even hot-code deployments run natively within the same BEAM runtime.

Working with this with a small team with one simple stack is a breath of fresh air in today's world.

I have a proprietary one that's much faster in terms of dev velocity.

When I struck out on my own I realised that I no longer had team consideration as a constraint and went a little bit off the beaten path.

Every client I have used it for has had nothing but praise for how maintainable the software is.

Coming from Ruby, Flask is much more of a Sinatra than a Rails. It’s very batteries-not-included. You basically just get routing out of the box. DB ORM, forms, auth, mail, background task, etc. are all DIY. That said, there are high quality packages to do all of those things within the ecosystem and I really like that I don’t feel like I have so much unused bloat in the framework when I’m making a small service.

I still don't get why .NET barely ever gets mentioned in these threads. Even new or niche frameworks like Phoenix, loco.rs and others get mentioned, but almost never .NET. It's as "convention over configuration" as it gets.

I learned to code professionally in Ruby but wrote C# .Net for almost 10 years. I've probably forgotten more about .Net than I ever learned about Ruby at this point so take what I say with a grain of salt.

.Net has tons of configuration and boilerplate so I can't say that it's exactly the same in that sense, but the more meta theme is that just as there is a Rails way to do things, there is a Microsoft way to do things. Unlike Java where you're relying on lots of third party packages that while well maintained, aren't owned by the same company that does the language, framework, ORM, database, cloud provider, IDE and so on. Having a solid well documented default option that will work for 99% of use cases takes a lot of the load of decision making off your shoulders and also means you'll have plenty of solid documentation and examples you can follow. I've been in JVM land for the past couple years and it just can't compare.

I know Java people will come fight with me after this but I just don't think they know any better.

Asp.net core is actually pretty simple to stand up and bang something out. Stick to the Microsoft docs and most patterns are handled.

I can't really say how the web UI side holds up to alternatives, tho.

I started my app using Rails and Hotwire/Stimulus and honestly finding myself way more productive than I did with more JS heavy options. Everything just works so nicely together in the Rails world.

The way I describe language types to non-coders inquiring about language selection for a given project is simply “scale matters”… dynamic types provide flexibility at small scale, but can very easily result in chaos at a large scale. Conversely, the structure of static types can feel onerous and restrictive at small scale, but provide robustness and structure at large scale.

I see what you mean but I have never found it to be an issue even in large codebases. Sorbet and RBS have been problematic. Lots of development slows down with these solutions. I wished it had something baked into the language as well but I'm happy without... just following conventions alone has worked really well for me.