I like exercises like this. We do things pretty differently, and don’t draw any true inspiration from other frameworks with Ash. It has pros and cons, we’re free to carve out our own paradigm, which is fundamentally different than anything else out there. For instance when building APIs with Ash, for example, you don’t write a single controller. Everything is derived from data. I think there is value in this thought process.

However, I think that its also important not to write off the similarities phoenix bears to rails as something akin to “well this was how rails did it so this is how we do it” type thinking. It’s a process of refinement, taking what worked well and what didn’t. If you are looking to reimagine a web framework from first principles, you’re going to have to solve a whole host of what I think are pretty surprising problems in the process.

For example, the typical problem with “one big controller module” is searchability. i.e how do I go and find the subsection of that code that handles requests from some given route. If I have to read a big pattern match to find the function head/case statement in question then I’m having to load up way more complexity in my brain to find what I’m looking for. If controllers are in their own module, I can fuzzy find files with “<thing I’m looking for> controller” and have a pretty solid hit-rate. So we end up doing things like having a case statement that calls a function on a nicely named module in a nicely named file so we can find the logic in question.

Couple that with the fact that 9 times out of 10 you end up with a controller-per route/group of routes, and the next big idea would probably be to put in your route handling code the ability for it to specify its own destination controller module, that way its super easy to go from route to controller, and then congratulations you’ve built a Phoenix router plus roughly the current controller convention.

I don’t say this to discourage this kind of thinking/work, as someone pushing against the grain myself! My goal is only to point out that it requires, I think, concretely better alternatives to what are out there and also wholistic thinking about why things are the way they are in today’s popular tools. For example, a lot of really simple patterns work amazingly in a small codebase with a small team, and fall apart when you start having 5, 10, or 100() developers working on a large enterprise system.

So to answer your question more specifically:

It is entirely possible that there are alternative architectures to Phoenix that would be easy to reason about. But it isn’t inherently true because Phoenix bears some resemblance to and inspiration from something like rails. We’d have to talk specifics. The ideas of having one Route module and one Controller module do not sound like better alternatives to me on the surface.

While I would generally agree I wouldn’t take it as such an absolute. I think one can surely build something that’s easier to learn and understand than phoenix. However any programming effort is still a matter of tradeoffs. Just because something is simpler to start out with doesn’t mean it’s automatically simpler to grow and keep maintainable in the long term. Phoenix sits in a spot for people trying to be productive and building a system, which is going to be larger than a quickly bootstrapped one, hence coming with more upfront structure and with more pieces of “you’ll likely need this soon anyways”. Striking a balance on that scale is hard.

I don’t think there is anything special about Phoenix itself if we talk about it in isolation. I’m not a big fan of a few magical things that came from Rails but it’s also important to know where you draw the line between declarative programming (that inherently does magic under the hood) and the explicit approach. I think imperative frameworks like express in JS, while having the easiest concepts to grasp, don’t offer a good abstraction level to solve business problems, plaguing them with complexity down the line.

Those who don’t know the past are condemned to repeat it. Unless you take your time to understand where the value of Phoenix comes from, you will never be able to come with a better solution.

Instead of having the attitude that we need to throw everything in garbage and to reinvent everything, why not improve the existing things? I’ve followed all previous conversations related to alternative microframeworks, everyone that is against phoenix failed to formulate a valid argument against using specific features of phoenix (plug, html) nor their alternatives they implemented were even as close to what phoenix provides today.