<html><head></head><body><div><div><div style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden; visibility: hidden;"><img src="https://r.superhuman.com/QYeZBt75F9SJ5JiLczQeFhauKACZUgNfDDcDucXQuxdzS0Llva2nkv_oYq3xX2r2k-LCB_XRYNtAollki0QbPQHuu5b9EO7LLS-9c0Q3PrmcQY74OZL4vcOp-GDvuFfJp1bVz1O5T0vhGVpSy6UmhCYpetmjwOLSU8J_1qneJNoa-wO9ZukB16KfOLzAxUbwIIFQ4g.gif" alt=" " width="1" height="0" style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden; visibility: hidden;"/><!-- --></div><div><div><div>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.<br/></div><div><br/></div><div>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.<br/></div><div><br/></div><div>So how do we reduce the coupling? Two things need to happen. <br/></div><div><br/></div><div>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.<br/></div><div><br/></div><div>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.<br/></div><div><br/></div><div>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. <br/></div><div><br/></div><div>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.<br/></div><div><br/></div><div>Thoughts?</div><div><br/></div><div>[1]: <a href="http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html">http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html</a><br/></div><div>[2]: <a href="https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)">https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)</a><br/></div><div>[3]: <a href="https://www.goodreads.com/book/show/85041.Refactoring_to_Patterns">https://www.goodreads.com/book/show/85041.Refactoring_to_Patterns</a><br/></div></div><br/><div class="gmail_signature"><div><div dir="ltr"><div><div><div><p><font size="2" face="arial, helvetica, sans-serif">M. Scott Ford<br/>Co-Founder & Chief Code Whisperer<br/>Corgibytes, LLC<br/>804.596.2375 x701<br/><a style="color:rgb(17,85,204)" href="mailto:scott@corgibytes.com" target="_blank" rel="noopener noreferrer">scott@corgibytes.com</a><br/><a style="color:rgb(17,85,204)" href="https://corgibytes.com/" target="_blank" rel="noopener noreferrer">https://corgibytes.com</a> </font></p><br/><p><span style="font-family:arial,helvetica,sans-serif">Have you read our </span><i style="font-family:arial,helvetica,sans-serif"><a style="color:rgb(17,85,204)" href="http://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth/" target="_blank" rel="noopener noreferrer">First Round Review</a></i><span style="font-family:arial,helvetica,sans-serif"> article about paying off technical debt? </span><br/></p><p><font size="2" face="arial, helvetica, sans-serif">Our CEO was named one of <a style="color:rgb(17,85,204)" href="https://lists.linkedin.com/2016/next-wave-top-professionals-35-and-under-20161011/software" target="_blank" rel="noopener noreferrer">LinkedIn's Top 10 Software Professionals under 35</a>. How cool is that?! </font></p><p><font size="2" face="arial, helvetica, sans-serif">Love refactoring and TDD? Join us at <a style="color:rgb(17,85,204)" href="http://LegacyCode.Rocks" target="_blank" rel="noopener noreferrer">LegacyCode.Rocks</a> for masterminds, podcasts, and more. </font></p></div></div></div></div></div><br/><div style="clear:both">Sent via <a href="https://sprh.mn/?vip=scott@corgibytes.com" target="_blank">Superhuman</a></div><br/></div></div><br/><div><div class="gmail_quote">On Mon, Jun 01, 2020 at 9:10 AM, Bastien <span dir="ltr"><<a href="mailto:bzg@bzg.fr" target="_blank">bzg@bzg.fr</a>></span> wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote sh-color-black sh-color" style="null" id="null"><p class="sh-color-black sh-color">Dear all,
</p><p class="sh-color-black sh-color">
I hope this email finds you well!
</p><p class="sh-color-black sh-color">
I've discovered and read about <a target="_blank" rel="noopener noreferrer" href="https://frameworklessmovement.org/">https:/<wbr/>/<wbr/>frameworklessmovement.<wbr/>org</a>
</p><p class="sh-color-black sh-color">
I find this interesting. Of course, this opens up the discussion
rather than closes it, and I see many plausible ways to disagree.
</p><p class="sh-color-black sh-color">
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.)
</p><p class="sh-color-black sh-color">
That said, the text also seems to make a point *against* libraries
<br/>
(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.
</p><p class="sh-color-black sh-color">
In general, I'm happy to see these discussions among developers,
it shows that maintainance issues are getting more attention.
</p><p class="sh-color-black sh-color">
All best,
</p><p class="sh-color-black sh-color">
--
<br/>
Bastien
<br/>
_______________________________________________
<br/>
Themaintainers mailing list
<br/>
<a target="_blank" rel="noopener noreferrer" href="mailto:Themaintainers@lists.stevens.edu">Themaintainers@<wbr/>lists.<wbr/>stevens.<wbr/>edu</a>
<br/>
<a target="_blank" rel="noopener noreferrer" href="https://lists.stevens.edu/mailman/listinfo/themaintainers">https:/<wbr/>/<wbr/>lists.<wbr/>stevens.<wbr/>edu/<wbr/>mailman/<wbr/>listinfo/<wbr/>themaintainers</a></p></div></div></blockquote></div></div><br/></div></div></body></html>