Contexts - a barrier too high for newbies?

I dunno, we’re busy refactoring a massive .Net application into modular contexts, and it’s 10x easier for new developers because instead of having to understand the entire application all at once, they only have to understand a small part, and can use basic C# knowledge rather than extremely domain-specific knowledge because each part is just a standard module rather than being tied into every other part of the app. Contexts gives you that.

I’m not talking about newer developers coming into an environment where things are modular. That’s obviously much better for them. I’m talking about newer developers understanding how to architect that modularity. The expansion of popularity for Phoenix framework, if it happens, comes from newer developers becoming interested on their own and nurturing that interest by building their own personal apps. That’s where you get the voices in companies bringing up Phoenix as a possibility for a new project.

Modularity is definitely a good thing that I’m very much in favor of. That’s not the point of this post.

Dude, it’s just files being in different directories. People will get it.

So its a good thing, but they shouldn’t have to learn it? What you’re saying seems to be a contradiction. Phoenix really isn’t very complex, and the way contexts have been implemented really doesn’t add much complexity. And you can still build a monolithic Phoenix application, having contexts doesn’t preclude that. I just fail to see how it not working exactly the same way as Rails is a terrible thing

So between learning programming, databases, html, css, and javascript, where developers will really have trouble and struggle is in organizing functions into modules? I recommend folks to stop making contexts more than they are. Why are design patterns even being brought into the discussion?

If you tell me PHP is easier to get started because I can just print something in the page, I will definitely agree with you. But saying contexts is what is going to block users from progressing with Phoenix has no basis in reality.

It reminds me when Rails 1.2 came with REST and everyone started screaming that it would be the downfall of Rails because oh-the-complexity. Once the details were ironed out, everyone just moved forward happily.

What is it about contexts that you think is difficult?

I think once Programming Phoenix is updated to cover contexts people will ‘get it’.

First and foremost, Phoenix 1.3 is not forcing you to use contexts. Where I think Phoenix really shines over most other frameworks out there, is its modularity and, relates to that, its introspect-ability.

Also, I would like to point out that I have yet to witness someone in the community to state something like “Phoenix is not your application” without explicitly explaining what exactly is meant and leaving the actual decision to follow something or not up to you.

The Phoenix framework is not complected, and because of that it is refreshingly different to a framework like Rails where ‘something’ happens automagically, but nobody is sure what. If you dont follow Rails’ conventions, you fight against the system every step of the way.

I really believe that there is room for a framework that is structured, rather than complex. I also believe that there are companies that value the soundness of the engine under the hood of the proverbial car, rather than only its carroserie.

Bandwagoning can be seen as an indication that something might be working, but should never be used to prevent or reject a possible course of innovation.

Context generators are a greatly appreciated addition to Phoenix. We see over and over that code organization patterns in a given application have inertia, and often go unchanged even when developers recognize they are problematic or were intended to be temporary.

It’s great that Phoenix is approachable for new developers, but I think it’s super important that good design decisions aren’t sacrificed as a popularity grab. We don’t need to compete to be the lowest hanging fruit for adoption, but a solid tool that gently nudges people in a direction that might help them down the line.

I’ve already shared some of my thoughts about this in another thread which received some replies you might be interested in reading.

At the risk of coming across as the person who just likes to complain I would like to add my opinion hasn’t changed and still think contexts are a bad idea. A lot of work goes into this framework and I don’t want to sound ungrateful but I think the maintainers are missing the big picture.

There are many (probably too many) languages to chose from these days and if Elixir wants to increase in popularity, or even stay relevant, it needs a “killer app”. For a language that excels at network things Phoenix is the perfect showcase for the possibilities.

Contexts are clearly a barrier to some people and I’m sure it’s turning people away but instead of thinking how to improve it we have a sort of echo chamber where most criticism is met with instant dismissal. I keep on reading they’re not complex and we’re not forced to use them which misses the point.

My suggestion would be to have another folder alongside “web” called “app”. This could work exactly like a context but just be a the default if no other one is specified when using the generators. It separates your app from the web app and sets people up for contexts in the future. I would also recommend removing the table prefix but I can see that leading to a similar discussion.

Having said that I’m using Elixir/Phoenix in my next project and I’m loving it. I’m using the structure as above because I love generators (why do people keep on dismissing them as only learning tools ) and it provides the maximum amount of separation for minimum effort.

I promise not to be as negative in any other topics but this context discussion really gets me going.

I think that not the context per se is the barrier. But rather the need to think about the app before starting to write it. I for once don’t have any issue with context, they are great, because they almost force you to modularize you app. On the other hand no one force you anywhere to use them, my Phoenix 1.2 app works flawlessly on 1.3. And when I started to move logic to contexts out of controller I was forced to think of what are the contexts in my app, and I saw that I have just a big mess of code, without boundaries. The first thing contexts forced me to do, well, my understanding of context in regard to my app, was to extract all the authentication out to it’s own context, and that is first big step to make my app much more maintainable.

And I think I should be grateful for those context in Phoenix, because of them I can see more clearly how to architect my future applications, be it rails, phoenix, or anything else. And because of those phoenix context I have better idea how to refactor my first production rust app, that has nothing to do with networking or web.

I think it’s really good that Phoenix force you to use good practices (same as Rust compiler basically enforces on you good practices by not compiling bad code). For instance at work we have few big rails apps, and when we needed to write small app to test some things some people insisted on extracting simple maps to YAML and load them (no IDE can tell you what the variables from yaml are), autoload some files from few other directories so we have a big messy namespace, and basically model rest of app after rails (I am to blame for that too). After getting back to that Sinatra app after half a year to add something, I need long time to even grasp what the hell is going on in there. I don’t think I’ll ever have that problem with apps modeled after phoenix architecture.