I've been trying out Phoenix, and it seems like the top contender for a Rails successor. It's not quite as fluent as Rails, but it's close. But I'm curious: since it is so much like Rails, won't it suffer from all the same complaints as in the article? It is still a monolithic, "Phoenix is your app" kind of framework, isn't it? Isn't the Devise-but-for-Phoenix library going to require Ecto? I think of Phoenix as just "Rails but faster." How is it different from Rails in ways the article author would appreciate?
(Edit: Btw I happily accept Rails' monolithic nature for all its conveniences, and I don't really identify with this author, but I'm curious to hear your opinion whether Phoenix would be a good fit for him.)
> A new phoenix application is not a monolith. The `phoenix.new` generator generates a regular Elixir application for you that sets up a default Endpoint worker in your supervision tree, as well as a web directory to put phoenix related files (routers, controllers, etc). wrt to collective process, we add `worker(MyApp.Endpoint, [])` into your supervision tree, so we do exactly what you are wanting. Building a Phoenix application is building an Elixir application, not the other way around. Your phoenix dependency and related workers are just one component to your larger Elixir/OTP infrastructure. Note: Lance Halvorsen, who gave the "Phoenix is not your App" talk, is on the Phoenix core team. We have been pushing these ideas since the beginning and as Lance I and laid out in our ElixirConfEU talks, we're taking a stronger stance on isolation with upcoming changes to guides and phoenix resource generators.
I think it's really quite a testament to Phoenix that so many people think it too is monolithic. A client can request a Phoenix application and I can get productive immediately without worrying about creating an unmaintainable, unperformant mess. No wasting 2 days on configuration hell. I can even jump into an existing project and be productive.
Another point is that the libraries around Elixir aren't (in my experience) Phoenix-focused or obsessed with magical Phoenix integration. In most cases, things work well together. Just call functions.
Monkey-patching, thread-unsafe operations, and uncontrolled shared global state are all non-problems in Phoenix. Decent code architecture and testability aren't usually a problem either because proper separation is enforced. Functional/immutable programming makes a huge difference here too.
Ecto 2.0 is really what ActiveRecord should've been. It's incredibly well thought-out. I suspect the author would be really pleased with Ecto.
Finally, Phoenix favors simplicity over ease in most cases. Complexity is not hidden in 100 layers of abstraction and callbacks.
The author also mentioned DHH's... colorful personality. So I'll take this opportunity to mention how much more welcoming and humble Jose Valim and Chris McCord are.
(Edit: Btw I happily accept Rails' monolithic nature for all its conveniences, and I don't really identify with this author, but I'm curious to hear your opinion whether Phoenix would be a good fit for him.)