<story><title>Write Libraries, Not Frameworks</title><url>https://www.brandons.me/blog/libraries-not-frameworks</url></story><parent_chain><item><author>userbinator</author><text>&lt;i&gt;A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls.&lt;/i&gt;&lt;p&gt;The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;web.archive.org&amp;#x2F;web&amp;#x2F;20141018110445&amp;#x2F;http:&amp;#x2F;&amp;#x2F;discuss.joelonsoftware.com&amp;#x2F;?joel.3.219431.12&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;web.archive.org&amp;#x2F;web&amp;#x2F;20141018110445&amp;#x2F;http:&amp;#x2F;&amp;#x2F;discuss.joe...&lt;/a&gt;&lt;p&gt;(Sadly, that site is gone, but the memories live on...)&lt;p&gt;Addendum: to see this in practice, one needs to look no farther than Spring, the famous Java framework:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc-api&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc-api&amp;#x2F;org&amp;#x2F;springframework&amp;#x2F;aop&amp;#x2F;framework&amp;#x2F;AbstractSingletonProxyFactoryBean.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc-api&amp;#x2F;org&amp;#x2F;springframework&amp;#x2F;web&amp;#x2F;servlet&amp;#x2F;support&amp;#x2F;AbstractAnnotationConfigDispatcherServletInitializer.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc...&lt;/a&gt;</text></item></parent_chain><comment><author>niftich</author><text>Spring class names are the stuff of legend, but most of those classes you wouldn&amp;#x27;t deliberately use in your application. They&amp;#x27;re there so Spring can layer up its own functionality feature by feature. The &lt;i&gt;only&lt;/i&gt; problematic part about this is when these class names leak into error messages, and the level of indirection becomes difficult to follow.&lt;p&gt;The way you use the core inversion-of-control framework people often just call &amp;quot;Spring&amp;quot; is you take your homegrown, doesn&amp;#x27;t-depend-on-Spring business logic, you make a config file, and if you&amp;#x27;re not executing it a servlet container, you make one entry-point class to start it all up [1].&lt;p&gt;There other projects under the Spring umbrella, and some of them are meant to be called from your code. Like Spring JDBC for database access, whose framework-like nature is apparent, yet in terms of its usage pattern, it resembles a library [2].&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;spring-framework-reference&amp;#x2F;core.html#beans&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;spring-framework-...&lt;/a&gt; [2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;spring-framework-reference&amp;#x2F;data-access.html#jdbc&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;spring-framework-...&lt;/a&gt;</text></comment>
<story><title>Write Libraries, Not Frameworks</title><url>https://www.brandons.me/blog/libraries-not-frameworks</url></story><parent_chain><item><author>userbinator</author><text>&lt;i&gt;A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls.&lt;/i&gt;&lt;p&gt;The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;web.archive.org&amp;#x2F;web&amp;#x2F;20141018110445&amp;#x2F;http:&amp;#x2F;&amp;#x2F;discuss.joelonsoftware.com&amp;#x2F;?joel.3.219431.12&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;web.archive.org&amp;#x2F;web&amp;#x2F;20141018110445&amp;#x2F;http:&amp;#x2F;&amp;#x2F;discuss.joe...&lt;/a&gt;&lt;p&gt;(Sadly, that site is gone, but the memories live on...)&lt;p&gt;Addendum: to see this in practice, one needs to look no farther than Spring, the famous Java framework:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc-api&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc-api&amp;#x2F;org&amp;#x2F;springframework&amp;#x2F;aop&amp;#x2F;framework&amp;#x2F;AbstractSingletonProxyFactoryBean.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc-api&amp;#x2F;org&amp;#x2F;springframework&amp;#x2F;web&amp;#x2F;servlet&amp;#x2F;support&amp;#x2F;AbstractAnnotationConfigDispatcherServletInitializer.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.spring.io&amp;#x2F;spring-framework&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;javadoc...&lt;/a&gt;</text></item></parent_chain><comment><author>sidpatil</author><text>&amp;quot;If you wish to make an apple pie from scratch, you must first invent the universe.&amp;quot; —Carl Sagan</text></comment>