Thanks for feedback @AlexMcConnell. In the future, please try to be less negative and more constructive with your feedback 
I would also love to see you edit the title to something more constructive, like “Contexts may be a barrier to entry for newcomers” or something less inviting of inflammatory discussion.
I reject your premise that trying to help newcomers design their app with well defined modules and functions will spell an end to the success of Phoenix.
Since generators are learning tools, it’s exactly our goal to encourage folks how to build applications. Design patterns have no bearing on this and someone’s knowledge of them has nothing to do with their abilities or their potential success with Elixir and Phoenix. I don’t see this part of the argument. Just as our Channel generator doesn’t force folks to first learn OTP to use channels, context generators don’t force people to understand patterns or have a degree in system architecture. When a newcomer sees a generated handle_in(event, params, socket), do: {:noreply, socket}, we aren’t forcing them to know about stateful servers and GenServer reply values, but as newcomers sees this code and experiment with it, they are internalizing concepts that underly the runtime. In that same light, our goals with the context generators aren’t to force folks to be system architects, it’s to guide them along a path where they will internalize ideas about Phoenix as the web interface to “their app” and think about isolation. So when they see:
defmodule Blog do
def list_posts do
Repo.all(Post)
end
end
defmodule MyApp.PostController do
def index(conn, _) do
render(conn, "index.html", posts: Blog.list_posts()
end
end
They’ll start to understand, “oh, this is where I write my code, in modules and functions, not inside the Phoenix web bits”. We aren’t asking them to take a giant leap, rather baby steps along their way to isolated systems. We don’t expect them to get there immediately, but rather nudge them along the path to greater understanding.
Again, as this feature is a learning tool, we indeed are trying to educate newcomers on the virtues of these ideas, but we aren’t forcing anyone to understand or use anything in particular.
The framework is a couple years old now. Let’s agree to set a reminder in our calendars for two years from now and we can evaluate how things played out [quote=“AlexMcConnell, post:1, topic:5929”]
I’ve seen a lot of people saying, “Phoenix is not your application.” Well, stop it! Who are you to tell someone what their application is or isn’t. If they don’t understand the concept, repeating a catch phrase over and over isn’t going to fix the problem, it’s just going to encourage them to move on to something else with a community where people are being helpful rather than condescending.
[/quote]
As a community I think we do a fantastic job onboarding newcomers and avoiding being condescending. I do agree we can do a better job here with that phrase, but in my experience the folks using these phrases aren’t just chanting them, they are helping folks understand the concept. After all, the “Phoenix is not your application” talk by Lance (Phoenix core-team member) was all about the reasons why this is important and how it can help you.
This is what your OTP application is for, so introducing "app would have the opposite effect of what you’re hoping for I think. Also keep in mind that if a user’s app is trivial and named something like “MyBlog”, they could use their MyBlog base module as the “default” context. The generators are aware of existing files, so the context code would be injected in place. Something like that in the guides could maybe be a happy medium?
To be fair, constructive criticism is welcome and I think we’ve had a good bit of decent discussion in other threads, but most of the context feedback so far has been far from constructive. Instead of basing arguments in the abstract about somehow pushing folks away if they aren’t experts, it would be far better to talk around code and actual points of confusion. For example:
Instead of:
Contexts are terrible because newcomers will struggle. IT"S LITERALLY THE DEATH OF PHOENIX
We’d like to see this:
I’m struggling with Phoenix 1.3. I can’t decide where to place comments and votes for my Articles system. Should it live in my current Blog context, or be separate?
I just answered a comment like this on slack, and after asking them about their app, I recommended they create a ContentTracker context for tracing comments, votes, and page view statistics about entities in their system. We also discussed that they could add comments/votes to their Blog and there’s nothing wrong with that, but they were quite pleased with the ContentTracker ideas and it made thinking about boundaries really click for them. They wen’t from frustrated to epiphany and appreciation after just a little bit of help, which is our whole goal with the getting started process in general. It’s easy to argue in the abstract that something is good or it’s bad, but it takes more effort to actually present scenarios and come to a solution together. I’d love to have more of the latter
