I think it happens in startups rather a lot, and startups also place the highest priority on a stack being quick and easy to get stuff built, which is one of Phoenix’s selling points.
AlexMcConnell
LostKobrakai
Where did you get that from? On the frontpage of the framework I read the following:
A productive web framework that
does not compromise speed and maintainability.
The latter part is exactly what the recent 1.3 changes do address – not compromising maintainability for a notion of being “faster”. I’m certainly of the opinion that the new contexts are explained/marketed in a bit to complex fashion, but the general idea of moving business logic out of phoenix controllers is a much needed change.
4
nerdyworm
I see a few issues/arguments that pop up and never get resolved in these Context threads.
-
Real examples that have 20+ schemas, 20+ endpoints, real use cases and real business requirements. This is probably the number one thing that will help the community with this problem. It is still early, so I’m sure that this will come in time.
-
Not acknowledging that a large part of web application development is simple crud. The problem is that contexts add ceremony with little value.
-
Pretending that the mess made with contexts will be a better mess.
-
Naming stuff is hard and now we have to name three things the Context namespace, the struct, and then add an interface from the context and the web world.
Most of these are just educational issues that would be better solved by publishing lots of code and blog posts 
However, there is a very real need for a standard “I didn’t know what to name this thing, it doesn’t really matter, stop trying to make it matter, just tell me where to shove the thing so I can get back to shipping features.” I think that providing a good enough guideline for the community would yield the incremental change that we need to move forward.
12
AlexMcConnell
The first word is productive, and not holding people’s hands isn’t compromising on maintainability. If people choose to build non-modular code (which they will still do with contexts anyway), that’s on them, not on Phoenix. Phoenix hasn’t compromised a thing by not trying to steer them to the right place. The right way to get people building better apps is through examples, tutorials, and best practices, not by adding a roadblock to them getting stuff done, even if that roadblock is a very minor one.
If you really feel the need to put something in the actual Phoenix code to encourage modularization, implement something like checking their code whenever a generator is used and spitting out a y/n message to the console along the lines of
Your app looks like it might not be following modular coding best practices.
Check out <some link> to learn more about modularizing your app.
Are you sure you wish to continue? Y/n
0
josevalim
Creator of Elixir
I am having a really hard time with this argument. So over everything they need to learn, code organization is the one thing we are going to move to the end of the queue?
Elixir never shied away of introducing concepts to developers: functional programming, pattern matching, immutability, etc. Since nobody seems to be questioning the merit of contexts, rather its accessibility, then the obvious answer is to make it as accessible as possible, as we did the concepts above.
The way to make this discussion productive is:
-
If developers are acting condescending, let them know about it. The fact different people in this thread have different understanding of what “Phoenix is not your application” means, indicates that you were spot on, and that the “meme” needs to be phased out
-
Developers need to bring cases and evidence of where contexts work and where contexts don’t. When someone says “contexts are terrible, you should remove it”, to me it feels the equivalent of going to the doctor and saying “my leg hurts, you should remove it”. You very likely want the people that lead the open source projects that you use to take informed decisions, so please help us with cases and evidences
In this thread, we have seen some examples of people having positive experiences with contexts and that’s great. But I have found struggles in other threads, such as when to split contexts, how to access data across contexts, what about umbrella applications, etc. Now is the time to collect those struggles and address this in the documentation, guides, books, blog posts, etc. If after a few iterations the concept is still not clear, then it means something more drastic needs to be done, maybe even remove the feature altogether.
So if you or someone you know are struggling with contexts, let’s talk about those cases, rather than jumping to the conclusion that the leg should be removed. Although I disagree with the premise that contexts are terrible for the future of Phoenix, I am always glad to hear about places we can improve.
13
AlexMcConnell
But those things are all part of the language, rather than how you use the language.
I do agree that more conversation and knowledge sharing is key to all of this. Getting some more of that rolling was my main purpose in this thread, and I’m more than willing to be shown that I’m wrong.
4
AstonJ
I’m 100% with José on this.
I would argue that a large number of people came to Elixir and Phoenix for perhaps two reasons in particular:
- Performance / scalability (which we get thanks to Erlang/BEAM)
- A better way of doing things (which we get thanks to ideas and conventions that José, Chris and others are introducing and incorporating into core areas)
I also believe these are some of Elixir’s best selling points.
While there are quite a lot of early adopter ‘newbies’ (all power to them!) currently the language is most attracted to developers with a little more experience… but this is working out really really well, and not only bodes well for the future of Elixir and Phoenix but will ultimately benefit newbies in the long run.
So personally I am all for contexts and other best practices being incorporated or promoted so long as they are clearly explained; whether via books, guides, talks etc - which the community has already said it’s committed to.. we just need a little patience 
0
josevalim
Creator of Elixir
Check Hex source code for an example application that is migrating from 1.2 to 1.3. It is a very interesting example because in some places it is in a mixed state, with logic still in the “models/schemas”, which is what you would expect a real world application to look like. We definitely need more examples though.
My intuition is that crud is actually nicer with contexts than without contexts. That’s because even when crud-ing, the resources are still related, and the context keeps this relationship together. In the scenario you are mindlessly generating stuff, then the only extra input that contexts require is the context name. CRUD still works.
I am confused. Aren’t those two? The context and the struct? Except by the context name, all names are inflected from the struct.
0
josevalim
Creator of Elixir
Isn’t that exactly the problem contexts are trying to solve? How do you go from pattern matching and functions to building actual software?
1
AlexMcConnell
I dunno. It just seems to me like it’s a situation for best practices. Should the code refuse to compile if a function is over X lines or uses nested ifs?
0