This thread has been going on long enough that it really makes me wonder if this isn’t a great opportunity for the Phoenix 1.4 roadmap to build in a polished and flexible Auth mechanism (like Ueberauth) as a separate context? Rolling it in as a default would also give something like Coherence a clear integration path.
You’d end up eliminating the questions about auth and examples of context usage all at once, without having to speak in abstract terms. Just thinking out loud.
I’m not sure something like phoenix should come with authentication by default… Isn’t phoenix supposed to be more low level than that?
Also, there are several ways to implement authentication, and it’s not clear that one of them is superior to the others.
Not everybody can just buy books (which are expensive, even though they’re good) – especially when you’re just getting your foot in development – in order to ‘get’ a concept that should be clear to everybody right from the start. The documentation should make it really obvious, without just repeating the catch phrases over and over again. As long as that doesn’t happen, I’ll remain skeptical to the new contexts in Phoenix 1.3 as well.
Of course some of you might say, “well, write the documentation yourself then”, and that’s a valid response. I am experienced enough to say I know the concept and how to utilize it, but I still couldn’t write the documentation I want myself properly, because I haven’t quite grasped how to effectively start a new Phoenix app using contexts myself. Why? Because it’s too easy to mess the structure up and then having to change module references everywhere.
I like everything about Phoenix 1.3 thus far, except contexts. I’ll go with it, because I love Phoenix and Elixir. Seeing the responses here indicates quite vividly that it’s not going to be changed anyway. Nevertheless, I don’t like contexts, because I consider them needless and obtrusive overhead in 90% of all use cases. Unfortunately that’s bound to happen with all popular frameworks and libraries, they’re going to grow more and more opinionated with every release.
My two cents. Please don’t burn me at the stake for it.
I disagree. I think that these things should be kept out of the actual framework in favour of libraries.
Reasons?
Hm… If someone can’t afford an elixir book and wants to “get their foot in development”, they should probably learn something else, something with actual jobs… There are very few jobs in elixir, and the ones there are are not entry level. You’re either learning elixir/phoenix as a hobby or you should already be an experienced developer in which case I really doubt you can’t afford a book.
Books are expensive for all programming languages, so where is the actual argument in saying that if you can’t afford an Elixir book you should learn something else?
Furthermore there are enough jobs for Elixir/Phoenix, if you use it as your programming language and framework of choice, e.g. as a freelancer, like I do. Entry level or not, the actual issue here are contexts in Phoenix, which have been declared by several users here as being a basic (entry level) thing to know, before you start – so why should I have to learn it from a book in the first place?
And that you’re either learning Elixir/Phoenix as a hobby or are a pro user is a false dichotomy par excellence. So people who learn Phoenix/Elixir have a right to learn it only if they have enough money? I thought we were talking about Open Source here? And what about people who switch languages to consolidate their knowledge and make it more future proof?
Sorry, your whole comment doesn’t make any sense.
I do think it makes some sense 
I’ll try to expand on some of the point you’ve raised.
What I meant to say is that if an Elixir book is too expensive for you, maybe you should try something else with more available jobs.
The argument is that if you need a paying job, Elixir is probably not your best choice right now, just that . If you’re already working as a developer you can probably (not always, I’m generalizing here) afford the book. If you can’t, there are probably better options to start a career as a developer. However, if you say that there are enough freelancer jobs where you can use Phoenix as a freelancer, then I take that back. Maybe Elixir is a good choice absolute beginners after all. I shouldn’t have suggested the opposite without having looked into the freelance landscape.
As I remarked in a comment above, contexts are a feature of a release candidate. A release candidate is not supposed to be as well documented as an actual release. Part of the problem is that people with little experience seem to be jumping to the latest and greatest in fear of being left behind, and are naturally surprised to find a new feature that is scarce on documentation. I expect contexts to be documented in the official phoenix online docs before an actual release. I agree with you and think the basics of contexts are not the kind of things you should learn from a book.
Well, yes… I don’t think the Elixir developers should be forced to write and edit documentation for free 
The available docs are already great and way above average compared to most programming languages I’ve tried.
I have a prototype phoenix app which I’ve built without touching and Elixir book and which is way better than the original Python app that came before according to my users (this is not an argument against python, its just that Phoenix fits my use case much better).
People who get paid for using a programming language should not be too shy about spending money to learn another one… This is not to be taken as an absolute moral argument, just my personal opinion. The Elixir/Phoenix core developers already share much of their hard won experience in the form of online docs, blog posts, forum comments and even one-on-one mentoring for some open source projects. It’s not too outlandish to pay for a book to get a little more.
Whether you agree or disagree with me, this is a defensible position.
These points are all independent on whether personally one thinks contexts are a good idea. I respect your opinion, and you might well be right. I’ve built a grand total of 1 Phoenix application, while you seem to have written several.
To me, contexts are an interesting abstraction but I don’t know how useful they are in practice, as everything I’ve done that uses contexts could have been done without them 
I feel like the concept of contexts could be tweaked somehow to allow or better tooling around them (a visual context editor, as I’ve described above), but I’m nowhere experienced enough to work on that right now.
I like Phoenix 1.3 and to me Contexts are akin to Java packages and are a way to organize code. As far as documentation goes it’s an RC, I’m sure the documentation will be there for the actual release.
I think there’s a big problem with expecting people to learn from a book, but it’s not about cost so much as that it’s a poor way of learning for a lot of people. There need to be quality learning materials in all sorts of learning styles.
I think this is a fine point. However, this is a 150 post threadnaught that will never end if it diverges to much from the original question.
There are - the Elixir and Phoenix guides and docs are renowned for being some of the best in the industry.
The only reason there isn’t more on Contexts is because it is part of an RC and possibly because the core team are still ironing out details. In the meantime we have lots of community efforts to help fill in the gap - whether that’s blog posts, confs talks, forum resources or even answers to questions on the forum (and elsewhere).
It’s not about expecting anything - it’s just that I am personally a proponent of using professional material to learn because I feel it is the best way to learn your preference or milage may vary - that’s cool. As said, the Elixir and Phoenix guides are some of the best around 
(If you think the guides or docs are lacking in anyway feel free to start a thread about it.)
No more posts about contexts for me as I said but I’m sorry this is just a pretty standard early adopter fannish kind of thing thats really just utter denial and shoots a young framework in the foot. It just illicits an eye roll and looking for the exit to anyone also active in Javascript/node Python/Django Ruby/Rails or even C#/.net with a multiplicity of books, videos and tutorials on the web with all kinds of styles that dwarf anything Phoenix has or even could have yet as relatively new. Maybe you misunderstood the point. I dunno
I will also comment on the book thing only because I was the one that first brought it up and its been miscontrued at least twice.
A) I don’t care how much money I make. As long as there is a charity and a hungry kid in the world I am not going to buy a book on a subject just to spend money because I can so theres a learning process involved in making that decision to even buy the book
B) Nothing to do with wanting the developers as has been now alleged to do everything for free including in depth training. My point was to the COMMUNITY that points to the book as the end all and be all of understanding the framework as I have read and watched a multitude of places. In my mind developers with that code work and the docs to back it up have already gone above and beyond in any language or framework. Its a community thing to then explain and and inform further not just tell everyone to buy the exact same book as a fall back to answer all/most understanding issues, Claiming or even implying someone should pay for a book to ascertain whether one of its core concepts is for them is NOT the spirit of open source.
C) TBH Many times its the guy that learned it six months ago that is FAAAR better teaching newbies because he can still relate to the potential questions and pain points of learning that are still fresh enough in his/her mind. Developers of the framework often suck at that.
P.S The fact that a framework or language has few jobs doesn’t make it a hobby language or framework. It can be robust professionally because developers are working on their own projects and/or within existing companies/contracts they are already hired in.
That is why the Ueberauth style is nice, it is just an interface for pluggable authentication. It has no templates, no authentication, nothing by default, just gives a unified interface to plug in any form of authentication.
But yeah, doubt it should be in Phoenix.
I feel like one thing this conversation is lacking is that folks assume the core-team didn’t based their decisions around these points. No one here was present for the hours of back and forth discussions on what would be too much for newcomers and where the perfect balance might be for our learning tools. Likewise, I spent many weeks writing different generators and then we would debate the balance of ideas. For example, earlier passes of the generators used Ecto.Multi and Repo.transaction because I wanted folks to learn about transactions early on as it’s something that is overlooked. In the end, we decided it was too much for those just getting started, but no-one in this discussion sees this back-and-forth and instead the discussions have regressed to either 1) contexts are good and not a barrier, or 2) contexts are a barrier, period. There’s a middle ground conversation that really isn’t happening where we can identify what aspects might be a barrier and how to fix them. For example, it’s clear that some folks are getting stuck on coming up with a name, which we’ll add docs and examples to address in the next release.
I don’t agree with this point. I don’t agree that capturing newcomers requires saying or teaching that their code lives inside the controller. I’ve been at this for a while now, and marketing the framework as such has never been part of my plan or something I position for newcomers to latch onto.
To your points about what phoenix needs to help newbies, I agree a wealth of official and community sourced learning materials is the best combination. As with anything, it will take us time to build up the comprehensive resources like the Django community – after all they’ve had a dozen years to get there. We’ll get there, but we won’t do it alone
I’m convinced that guiding newcomers to design their applications with intent is the right choice. I’m also convinced that the generators isolating functionality behind modules and functions is a path that we can successfully navigate for newcomers.
Rather than appealing to the fear of losing newcomers, I’d rather have discussions on how to make this learning process the most successful. Folks need to understand these questions of balance have been part of our decision process from the beginning.
Instead of making derogative sweeping statements it would be more helpful if you can point out where they are lacking. I know that Contexts are not yet covered but as explained this is because the feature itself is still in RC and it’s likely the core team are still finalising the details. (But there is plenty of help/community resources in the meantime.)
If you’re speaking in broader terms, we are incredibly lucky to have some of the best tech publishers involved with Elixir… and some fantastic authors. For the age of the language I’d say its on route to match that of Ruby (which was IMO easily the best for learning material - from my experience anyway).
I don’t get your point. Buying a book isn’t spending money for the sake of it - it’s gaining knowledge from a more experienced person who is taking the time and trouble to write material that is considered and digestible to help you learn as fast and as easily as possible. Writing a (good) book is hard work.
With all that said, I appreciate that currently Contexts is proving difficult to grok for some - that’s why we’ve put up resources and threads on the forum to try and fill the gap until the docs (and books) are ready.
Personally, I just don’t see the upside of contexts. In my opinion, people who understand the benefits of modularizing their code are going to do it anyway, and those who don’t are just going to put everything into some “main” context, which they will then have to reference constantly. There might be some people in the middle, but I think that group will be very small.
It seems to me from this thread that what may be missing is a sort of Phoenix fundamental guiding principles/what it is and what is it not, that clearly draw a line and lay the ground for future development options so that everyone clearly understands the tradeoffs involved.
Everyone knows that as the more an ecosystem grows the more different views and opinions we’ll have. We’ll never have everyone agreeing on all the decisions that are made.
So, my view about Contexts may be different than some other views but as long as IT STAYS ALIGNED with the fundamental principles I know I’ll be aligned with the majority of the Phoenix users because they must be aligned, otherwise they’ll flee.
Honestly, when it comes to open source, I don’t think that appealing to the vast majority of developers must be the number one criteria of making framework or languages. Creators don’t profit directly from that as a company would profit. The driver must be do things as the creator thinks they should be and if that vision proves to be correct then growth and users will come latter.
Usually when creators start to make a lot of concessions the result is not good enough any more.
Again, there’s no right or wrong it the arguments I see here. I’m more inclined to some but I recognise that even myself was once more inclined towards other arguments before. So, we also change and right now Contexts make me more happy than without contexts.
Also, again, and because I think this thread is generically about newbies barrier (not only Contexts) my opinion regarding authentication diverges from Chris McCord’s opinions. If, in the case of Contexts I can see that the more complex the project will become the more benefits I can have from Contexts, with Authentication is the opposite: the more complex the project becomes the more difficulty I’ll have in using Phoenix without a proper authentication system in place and I may be forced to go away because a robust, end-to end authentication system is not something I think I should do. It must be part of a good web framework.
I know that would bring an overhead to Chris McCord, but there are some libraries that they needed to create once and that are not needed any more because we have good alternatives and the effort could shift from them to authentication (I’m thinking about internationalisation, SMTP, HTML helpers,…).
My view regarding authentication doesn’t mean we don’t have libraries that allow us to start a project. It means I think none is robust enough or offers guarantees of being future proof. And that’s only because authentication is a very complex tasks that must be integrated with the framework (I believe in this but off course, others don’t, which again, just means that we need to know how aligned we are with Chris McCord’s own view 
)
Nevertheless, I must confess that THIS IS THE BEST COMMUNITY I’ve ever been involved with and that’s a HUUUUGGE advantage that allow us to overcome lots of road blocks.
Thank you all.
I think this philosophy of finding better ways of doing things is one of Elixir’s and Phoenix’s biggest appeals
I also have no doubt in my mind that you and the core team properly consider concepts before introducing them - in fact everything I’ve seen so far shows that you care deeply about this 
From my anecdotal experience, single file Flask apps with thread locals, no namespaces, non deterministic route matching, no centralized router, morbidly obese controllers and dat sweet, sweet fat ORM with N+1 queries scattered around capture newbies like quicksand. I know because I’ve been there. Actually forget it, most flask apps don’t even call them controlers 
. You can design well structured Flask apps, but that’s not what’s going to get newbies to try the framework. And that’s ok, because they’ll learn about HTTP headers, authentication, DB management, templates, and might even do something useful. Then they’ll get frustrated trying to get websockets to work and try phoenix.
Regarding all your other points: I agree with all of them, and have even outlined some of what I perceive to be the real barriers. As soon as I have the time to blog about it, I’ll try very hard to sell contexts without any of the evil lies you don’t want me to spread about Phoenix
I already have and so has the person you were responding to and I’ve already made it perfectly clear that some of that is to be expected for a new framework. Thats something every new framework community has to live with not be in denial about. Every new framework should be very conscious of the pain point of limited learning material, examples and libraries/packages. that conscious honesty helps it break through that stage. Denial not so much
well I’ll make one last attempt and then just accept you will never get it and let the book thing die as well (it was not tangential in regard to contexts when it was brought up but it is now). Have you bought books about every framework and language you read about that has a published (print or PDF) book? Why not? After all Its “gaining knowledge from a more experienced person” isn’t it? Maybe you have unlimited time. Most developers and would be developers don’t. commit to learning a language and framework until we get a good sense of what it is and the utilty and philosophy of it. We pass on it if we don’t because the programming world is far larger than any one language or framework and fantastic apps are being built with almost all of them. I don’t get whats so hard to get in that point and this thread is in part about barriers to newbies which IS an adoption concern.
© Copyright Elixir Forum | Terms | Privacy & Cookies
