Contexts don’t go far enough IMO. They give you the worst of both worlds.
net
sztosz
Maybe not compiling it a bit too harsh, but a warning would be nice 
Still Phoenix do exactly nothing when you don’t use context, it does allow you to not use them. So it’s not comparable.
0
AstonJ
Please be more constructive. If you feel they have shortcomings, please explain what you feel those shortcomings are. If you feel they can be improved, please lay out your proposals on how that can be achieved, thanks.
8
josevalim
Creator of Elixir
andre1sk
Even if we take this statement at face value one would hope that at a decent number of entities the decisions at least in part are driven by experienced developers so there is nothing wrong with having a framework that is better understood by people with some experience.
0
sasajuric
Author of Elixir In Action
I could also point out that there are no technical reasons for endpoints, routers, controllers, and views. You could have all of this functionality implemented in a single module. Surely grasping a “hello world” web app powered by one module would be easier, due to less moving parts. If short-term productivity (which I personally like to call seductiveness) was the only goal, Phoenix would be failing consistently from the day 1.
Moreover, my experience is that one can frequently gain short-term productivity by sacrificing maintainability, so to some extent there are trade-offs here. As a bystander and merely a user of Phoenix, my understanding is that the Phoenix team is aiming to find a good balance between the two. So, while the productivity is certainly a goal of Phoenix, it’s not the only goal.
Personally, I think that the new version strikes a better balance. I base that conclusion on my team’s real-life experience with Phoenix 1.1/1.2 where the defaults proposed by the framework helped us produce a less maintainable code. The fault for that was ours, but contexts would have pointed us in the right direction. Given that the mental overhead of contexts is IMO very low, I think that the gain is well worth it.
10
nerdyworm
I’ll be peeking at the hex example: GitHub - hexpm/hex: Package manager for the Erlang ecosystem. · GitHub didn’t know that was a phoenix app 
For some things, absolutely it’s been super nice and clean to work with, credit where credit is due.
For other things, it feels like one layer too deep from the web app. It’s like I’m forced to wrap every call to Repo.update with NotARepo.update. It’s clean when it’s needed, but when it’s required it’s tad overly formal.
Get rid of create/update/delete/list/get/exists function names and replace them with names that are meaningful to the context. For example, Scheduler.meetings_this_month Post.submit_reply Calendar.add_reoccuring_event. By my count that is a context name, the database struct or whatever the context trying to abstract, and the function that defines the interface to the rest of the application.
It’s those none crud things which bring the most value to contexts, however, only a small percentage of my application really benefit from them.
The most concrete issue that I deal with is when the database table is just a database table.
In my little project, I have about 60 schemas and growing. 20 of them are purely just a schema/database table. The fun part is that any of those 20 schemas are fair game for any other part of the app to depend on, have reference to, and have collections of. I guess the app is the context for these things?
The second issue is when I start a new project that is when I know the least about it. It is pretty hard to divvy up an app into meaningful parts when you are not exactly sure where things fit. Some sort of blessed dumping ground like lib/core or lib/schemas and some tools to refactor to contexts would be very welcome.
Thanks for all of those participating in these threads. They can get heated but I know it’s because everyone deeply cares about the tools they are using. I’d be worried if everyone just went with the flow around here.
Cheers!
3
LostKobrakai
That one is an issue I noticed as well. While I feel it’s good to have people think before diving deep into details it surely feels like a blocker as well. But in the end everybody is free to simply use the context “Core” or “App” for as long as the contexts are not clear enough.
That’s one reason why I’m hardly using the generators anymore. Creating the modules manually is often as fast as (remembering the correct cli syntax and) deleting all the generated crud stuff.
4
josevalim
Creator of Elixir
I wonder how much cheating would it be to do something like mix phoenix.gen.html Posts Post "posts" ... for those cases. Although I can see that if you are going in this direction, then contexts definitely feel like boilerplate.
0
massimo
If I understand this correctly, the problem is that newbies don’t get best practices and find somewhat hard to comply.
But isn’t it that the reason why they are newbies and we set up best practices ?
When I first bumped into Rails I was already an experienced programmer, but I had been working on .net and weborms for years and it was really confusing for me at first.
Rails wasn’t easy at all for newbies, but it was opinionated and that made feel other’s people code familiar and helped expanding the knowledge.
What’s easy now has been hard at the beginning.
Practice makes you perfect, I strongly believe in the value of enforcing good behaviours instead of being too permissive and allowing the big ball of mud to prevail.
6