That’s kind of what happens in Dave Thomas’s Empex 2018 Keynote
This post is a reflection on an article from Uncle Bob.
I’d say it’s more about some of the “sequels” to that article:
Before you commit to a framework, make sure you could write it.
Phoenix is an (application) framework and the issue is around the perils of framework use in general (not Phoenix in particular).
To a large extent frameworks revolve around “commonality/variability” - the framework provides you with the commonality so you don’t have to create it (over and over again) and you can just focus and implement the parts that vary.
So as such it should be obvious that your framework defines and sets in stone that part of the architecture (or lack of it) that it is providing the commonality for (many people assume “application framework” when they hear “framework” but there are “view frameworks”, “persistence frameworks” etc. So when people claim that React isn’t a framework because it isn’t an “application framework”, I counter that it is a “view framework”.)
Frameworks are supposed to make you more productive when you create a certain type of thing that the framework is representative of (to some degree they also make individual developers more fungible). But there is a lot that can go wrong.
-
Some frameworks may not provide enough commonality to be worthwhile
-
Some frameworks apply to only a very narrow set of use cases, defeating the productivity gain ROI of learning it.
-
Some frameworks try to cover too broad a set of use cases, creating complexity that isn’t warranted for the projects they are being used for.
-
How are you going to pick the right framework for your particular problem? The most common outcome is that the “standard one” is chosen - which could simply be a “golden hammer”. So framework’s can be used in situations where they are an ill fit and consequently aren’t carrying their weight, overcomplicating things.
-
Given that framework use is often about “productivity” there is little incentive to invest in keeping your “application logic” separate - it’s more about getting something functional out of the door ASAP.
And from a developer skill building perspective frameworks can be dangerous.
- Seems some people are perfectly happy remaining “framework users” (or library users for that matter) - i.e. they acquire the bare minimum of skill use the framework but never get to the point of understanding why it is structured the way it is. So when the next framework comes along they start from zero, never being able to recognize which parts of the framework their solutions are actually benefitting from, much less being able to recognize what kind of framework would be ideal for their particular problem space and build that instead.
So using Phoenix is a choice. But ultimately any choice has to fit the problem and the tradeoffs between the benefits gained and constraints accepted have to make sense. For example Phoenix is built around Plug and there are some use cases where Plug’s tradeoffs aren’t acceptable - which is why Raxx was created.
Then how you use Phoenix is also a choice. Accepting “Phoenix as your Architecture” may give you a short time-to-initial-success but that may create some pain in the future (which is only relevant if the project has a future - before being replaced). But there are other ways to use it to keep it from “being your application” and “defining your architecture” but optimal decoupling requires some work up front.
