Comment by bwilliams | Hacker News Reader

Comment by bwilliams | Hacker News Reader

I've used Rails for a long time, and Phoenix since early versions (0.6 or something like that?).

Phoenix is amazing but productivity wise I haven't seen it get near the productivity levels you can get with Rails. Other developers I've spoken to say the same thing. This is even more true with the more recent release of Phoenix 1.3 encouraging the use of contexts. I think it's a good pattern to extract to once you have more knowledge about your application but trying to think about it up-front has slowed development speed down and has been hit or miss on whether or not the context was "correct". https://hexdocs.pm/phoenix/contexts.html

I think Rails and Phoenix have a heavily overlapping place in web development but my personal tl;dr is that Rails is great for getting shit done and Phoenix is great for scaling, especially when it comes to websockets.

> Rails is great for getting shit done and Phoenix is great for scaling

I think thats a fair assessment. Rails is super productive - but if you're building say, a financial exchange, Phoenix would probably serve you better.

Yes! Contexts are the equivalent of building a greenfield rails app with a bunch of properly namespaced and isolated Rails engines. You end up with some really awkward names and boilerplate code that just doesn’t feel right. You can get that sense while reading the Phoenix context documentation.

The Phoenix story should include an area where the app can evolve, and as it matures and becomes more well understood, pieces of it could be moved into contexts.

100% agreed. I see what the Phoenix team was trying to accomplish, but I don't think it will pan out in projects how they expect. It reminds me a lot of fat model and skinny controller when that was popular.

I think the underlying issue I have with contexts is that it's forcing us to predict the future. We have always had to predict/plan but I think contexts push it a bit further that we can reliably predict/plan. This is especially true for new apps which tend to change rapidly.

Like I said before I think it's a great pattern to extract existing code into but it's feels too heavy to start with.

Would you have any thoughts on how they compare in maintainability?

I do, I think it all boils down to the team. I'll admit Rails apps are a bit harder to untangle but poorly written code is poorly written code.

A lot of clever metaprogramming tricks can make that poorly written code a lot more painful though. :)

Reply on news.ycombinator.com