In that case, let me attempt to make that argument 
The vast majority of people, developers absolutely included, have a very low tolerance for diving into the deep end of a whole new world. People tend to do much better, and feel much better in the process, when they can incrementally move from A to Z rather than jumping over the other 24 letters in between. To the point that they will pass on methods that ask that of them.
No matter how much we would like this to be otherwise, it is a generalized truth about people.
The reason this matters comes from answering the question of why people come to Elixir and Phoenix. I don’t mean why they choose it over other options, but when they are already here … what are they trying to achieve?
I suggest that very very few are here to get a 5 year journey into a more ideal way of thinking about programming. I hope everyone does get that as a happy consequence of being here and using what are some phenomenal tools and getting to work with what is a great community of people. But that’s not what most show up for.
They want to achieve something very concrete, and often relatively trivial, today.
If we give them something that requires either too much learning (and let’s be realistic here: there’s already a lot to learn on the way in that door as it is!) or requires too much effort to put something useful together, they just won’t. We can point to Haskell and similar (great!) functional languages for the former, and Erlang (among others) for the latter as examples of these pitfalls.
We should also be realistic and realize that 90%+ of people using Phoenix will be making something small and simple. They don’t need complex or design perfection, they need a pragamatic tool to quickly get to their destination.
If they are successful with that, they may then move on to something more involved. This, I think, is a key point. How many times did the “we made a stupid prototype in half a day and basically got where we needed to be to make a full project out of it” meme occur in the Elixir Conference talks? I noticed it as a repeating story.
So it is key to have something simple, easy and “batteries included” that can get people walking (again, having to learn to walk in the land of FP, actors, and the rest in the first place). And that is why having something that provides all your pieces in one place is important to get started. Without it, people won’t start and few people will be there for the 5 year journey.
That said … most people don’t know they should be on that 5 year journey … perhaps until they are a year into it. (At least, that’s been my personal experience … ) But it is 100% worthwhile, and honestly the world of software development needs more of us to be on that journey.
So I do agree with you that there should be something better, something of a longer view. For bigger projects it is a requirement, for our personal development as writers of software it would be a blessing. But perhaps it could be delivered as a journey rather than an educational course.
What I mean is that we should perhaps be happy to have people walk in the door even if the anteroom isn’t where we want them to end up. Once they are there, there should be a nice and sensible path from that front door (i.e. Phoenix with Brunch and Ecto and all the other bits thrown together) to a better architecture, something like what you are advocating for.
And to me that is where the tools fall a bit short still: they give a great starting point, and you can go anywhere you want from there, but how amazing would it be if you could start with a simpler-to-grok all-in-one smallish application and evolve it from there, using the tools, to something increasingly more separated by concern and domain … where after some months (or years?) of working your project from a small little flower in the field to a giant rose garden, the tools have taken you down that path.
You can already do this on your own, but it is effort and you leave the tools behind as you go. To umbrella or not is a question we ask people to make at project creation time, and that’s probably not the best moment for most projects or people to make that decision. To separate data storage/retrieval from API access is a good idea, but it makes a hell of a lot more sense when you don’t have a small app (where it honestly makes very little sense: complexity for little realized benefit besides feeling good about your phyrric deisgn win) but now have something bigger. Understanding where the cut lines for smaller, focused applications (“microservices” or whatever other buzzwords one prefers ;)) is often easier for people to understand as they explore the problem space by doing.
Having tools that could help set up projects for later refactoring (and I do think Phoenix 1.3’s contexts could be a first step in that) and then help you automate those steps when they make sense for you could be absolutely empowering. It would be a way to take people on a 5 year journey of discovery, and pick for that given day in that given project where to land.
Put more simply: I don’t think we can realistically start most people down a 5 year path to glory. But we should be trying to lead them there. We can certainly start them somewhere simple, and if the tools are there for project refactoring they can accidentally stumble down the 5 year path.
)
for this approach!
