[Themaintainers] frameworklessmovement.org

[M. Scott Ford]

I can totally empathize with the desire to reduce the pain of being tightly coupled with a framework. I worry that throwing out the frameworks completely would be a mistake. A framework typically includes a battle tested set of tools which are just plain hard for one team to be able to build well on their very own. Issues of security and performance are the first aspects that come to mind in that respect.

However, I feel strongly that the root cause of the frustration stems from the tight coupling between the framework and the application. I have been seeing interest during the last decade in trying to figure out how to better decouple applications from the frameworks that they use. One that comes immediately to mind is blog post titled "Rails is Not Your Application"[1], which was published back in 2011.

So how do we reduce the coupling? Two things need to happen.

1) I think there is some work that can be done on the framework side to make a decoupled approach the standard way of building apps using the framework. When the easiest implementation path is close to the "best practice" path then the "best practice" path will be followed more often. This means that frameworks need to take into consideration how current users are going to be affected with when the framework needs to be inevitably upgraded. Framework designers can start designing to intentionally make framework upgrades painless.

2) For frameworks that are always going to be hard to upgrade, then we need to adopt a design that insulates most of code from the framework. Different metaphors come to mind for this. One is a firewall or a shim. Stick it between your app and your framework. When the framework needs to change, the code that is most affected in on the side of the firewall that touches the framework. Hexagonal architecture[2] is another way to achieve this insulation. And with Hexagonal architecture, you're able to establish repeated patterns across your design that can be repeated as new frameworks are added to solve new problems.

A super big challenge here is that few apps start out "needing" this level of sophistication in it's design. The more pressing challenge early in an application's development is whether or not is going to actually solve the problems that it's attempting to solve. This creates pressure to establish tight feedback loops so that user feedback can be received and responded to. If your app is in that state, then following the easiest path to solve the problem makes the most short-term financial sense. And then after the problem space is better defined, then you can start moving your application in the direction of more maintainable patterns.

I really like the language that's presented in "Refactoring to Patterns"[3], because it talks about making changes to an application's architecture to move it away from it's current patterns and towards a better one. I think this is what most applications that are currently tightly coupled with their frameworks need. They need to move away from this tight coupling approach and start moving towards an approach with reduced framework coupling.

Thoughts?

[1]: http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html

[2]: https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)

[3]: https://www.goodreads.com/book/show/85041.Refactoring_to_Patterns

M. Scott Ford
Co-Founder & Chief Code Whisperer
Corgibytes, LLC
804.596.2375 x701
scott at corgibytes.com
https://corgibytes.com ( https://corgibytes.com/ )

Have you read our First Round Review ( http://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth/ ) article about paying off technical debt?

Our CEO was named one of LinkedIn's Top 10 Software Professionals under 35 ( https://lists.linkedin.com/2016/next-wave-top-professionals-35-and-under-20161011/software ). How cool is that?!

Love refactoring and TDD? Join us at LegacyCode.Rocks ( http://LegacyCode.Rocks ) for masterminds, podcasts, and more.

Sent via Superhuman ( https://sprh.mn/?vip=scott@corgibytes.com )

On Mon, Jun 01, 2020 at 9:10 AM, Bastien < bzg at bzg.fr > wrote:

> 
> 
> 
> Dear all,
> 
> 
> 
> I hope this email finds you well!
> 
> 
> 
> I've discovered and read about https:/ / frameworklessmovement. org (
> https://frameworklessmovement.org/ )
> 
> 
> 
> I find this interesting. Of course, this opens up the discussion rather
> than closes it, and I see many plausible ways to disagree.
> 
> 
> 
> But, as a Lisp/Clojure developer, it resonates with a lot of other
> discussions in our communities: the accepted "wisdom" in Clojure is that
> frameworks, while useful, are often *too* useful and always end up
> preventing your project to move on (e.g. we don't have a killer framework
> for web applications.)
> 
> 
> 
> That said, the text also seems to make a point *against* libraries
> (as mini-frameworks?) which shows the limit of this argument: even in
> Clojure, we don't discard libraries as well-calibrated ways of solving
> small problems, we praise them.
> 
> 
> 
> In general, I'm happy to see these discussions among developers, it shows
> that maintainance issues are getting more attention.
> 
> 
> 
> All best,
> 
> 
> 
> --
> Bastien
> _______________________________________________
> Themaintainers mailing list
> Themaintainers@ lists. stevens. edu ( Themaintainers at lists.stevens.edu )
> https:/ / lists. stevens. edu/ mailman/ listinfo/ themaintainers (
> https://lists.stevens.edu/mailman/listinfo/themaintainers )
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stevens.edu/pipermail/themaintainers/attachments/20200603/ea9a8616/attachment.html>