The reason that Rails is as popular as it is is because it’s very easy for relatively inexperienced developers to get a lot of work done. Is that work a poorly designed mess? Yes, yes it is. And so what? That’s just the nature of the beast at the moment. It doesn’t reflect on Rails, it’s just the current state of software development. The demand for developers is such that someone fresh out of a code school with no college can be making six figures within a year or two, even outside of Silicon Valley. Their work is going to be a poorly designed mess no matter how you slice it.
But even if it’s a mess, companies would rather have apps that are poorly designed, buggy, and going to be difficult to expand later than no apps at all. It’s a nice idea to encourage people to build better apps, but it’s horribly impractical to expect it in the current ecosystem. We live in a world where developers with 4 years of experience and a poor understanding of design patterns are considered ‘senior,’ and that’s not changing in the next 5 years.
In another thread, Chris McCord said, “we are asking folks to isolate functionality behind modules and functions.” And I say, no, you’re asking folks to understand the concepts and importance of isolating functionality before being allowed to build a Phoenix app. You’re making it so that someone who doesn’t have a solid foundation in design patterns is going to run into a brick wall of confusion before they can even make a Hello World app. Anyone who understands and appreciates the values of these concepts is going to implement them without needing to be steered into it. All you’re really accomplishing is to doom Phoenix to being a niche framework. Maybe that’s what the community wants. If it is, I can only hope that someone builds another framework in elixir that I can use.
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.
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.
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.
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.
I love Rails, because of it awesome guides! For me as an inexperienced developer, Rails taught me how to do beautiful things, how to work with MVC and AR. I like rails because as an inexperienced developer, I can just follow the guides, and be sure that I use best practices.
In Rails, no one forces me to place views in a separate file, I can just put a bunch of text in a controller. No one forces, to use separate actions, for a separate route, I can just use one action for every route I have. No one forces me to use rest conventions.
But following guides, I see how my code become clearer to understand.
Phoenix generator, just as Rails generators, a bootstrap for start, or a learning example. No one has to follow to an idea of separation domain logic from web-framework, but we should provide good examples, that can give insight to novices, or can be usable for experienced users.
I have spent a lot of time thinking about bounded contexts, in elixir and other languages. It is often difficult to work out exactly what they will be up front. When start a new project I often have two namespaces. one called www (not web because most services are likely to be available over the web) and one called operations. Projects then evolve often gaining an admin and/or analytics context. After that stage is when the ‘operations’ context starts breaking down into useful services and perhaps vanishing all together.
And the reason Rails has awesome guides is because of all the people who found it, fell it love with it, and made those guides awesome before you came along.
The fact that they need to focus on learning all of those things is exactly why more shouldn’t be added to it, although I doubt that many, if any, people are finding Phoenix currently that are completely unfamiliar with html, css, and javascript. And it’s not really about them struggling with it, it’s about the fact that they simply aren’t going to want to learn that before they learn to do “cool things.” The expectation for proper organization and use of modules is fine for people who have already committed to using Phoenix. Selling new people requires letting them see what they can do with minimal effort.
Still, no one forces you to use them. And when learning new framework yo’re better off without them anyyway, because instead of answering some questions they just raise more.
I think that Phoenix is not aimed at people that want to do just “cool things”. Phoenix and Elixir is rather aimed at people who understand terms like distributed and fault-tolerant. And to know them, and understand value of distributed and fault tolerant software, you really have to do some real world programming. And if you done that, you know you don’t want sot that’s cool, but rather software that is easy to maintain.
I really, really don’t understand why there is a need for phoenix to give up teaching good practices just because some people can’t or don’t wan’t to spend some time (very little actually) to understand where does those practices come from, and why they may be important.
About a year ago, my team started working on a Phoenix app. We all had experience with Erlang, building web servers, and software development in general. None of us had experience with Phoenix, though, so we followed patterns encouraged by the official docs, generators, and other independent blogs. We started with Phoenix 1.1, so there were no context, and there were still models. We moved quickly, and produced a lot of code in the next few months. Unfortunately, that lead us to a quite interleaved code with unclear boundaries and responsibilities. It became increasingly harder to maintain and extend such code. Some six months after we started, we agreed to clean up our controllers, and move other concerns to “service” modules (which I feel resemble the official contexts being introduced with 1.3). To this date, our code is still not completely there.
My takeaways from this experience are:
Framework plays an important role in determining the code organization. Even as experienced devs, we simply stuck to defaults promoted by Phoenix at the time.
It’s much harder to refactor the code post-fact. Having worked on some terrible legacy (and sadly produced some of my own), I strongly feel that your only chance of keeping the control of your code is to pay attention to it from the very start.
Keeping the Phoenix part of the code (controllers, sockets) focused only on HTTP related tasks, basically making it just the interface to the rest of the system is a very good way to structure any production app.
Therefore, there’s no doubt for me that contexts are a very good idea which will push developers in good direction, promoting better code organization patterns. I agree that this will make things slightly more confusing for newcomers, because it’ another idea they have to grasp. However, I think that this is a good trade-off. A bit of approachability is sacrificed to get much better code organization.
I’m somewhat worried about this mantra myself. I have a feeling that for some people it means “Phoenix is not your OTP application”, and that we should always organize our system as umbrella apps. I definitely don’t share that view. For me, the core idea here is that Phoenix is an http/ws interface to your system. You take the input, validate it, and then invoke some other part of your system (i.e. some function from some module in some other namespace), and finally convert the result of that function into desired output (html, json, …). That’s a clear separation of responsibilities, and can lead to much more readable code. And a readable code is a win for everyone, especially for newcomers.
I think the bridge between his comment and yours is that newer developers shouldn’t be the ones getting paid to architect a new environment for a company’s systems. If they are then they more than likely had a choice in deciding what language to use and if they chose Elixir and Phoenix, you would assume it’s because they knew it already and not that their employer let them pick something and then spend a while learning it.
If a more senior developer chose it then your concerns are largely laid to rest and you get the benefits of a more modular environment for future new hires to come into.
I have rarely seen much beyond “I need a website” type work entrusted entirely to new developers. If somebody with an actual development budget did that for a business application, it would be a shock.
) and it provides the maximum amount of separation for minimum effort.
