<story><title>Why I Hate Frameworks</title><url>http://discuss.joelonsoftware.com/default.asp?joel.3.219431</url></story><parent_chain><item><author>dools</author><text>The most important statement in this article is near the beginning, and it&apos;s still relevant today:&lt;p&gt;&lt;i&gt;&quot;I&apos;ve done small woodworking projects before, and I think I have a pretty good idea of what I need: some wood and a few basic tools: a tape measure, a saw, a level, and a hammer.&quot;&lt;/i&gt;&lt;p&gt;The reason I hate frameworks (even things like Django which is very easy to get started with) is that, at some point, I&apos;m asked to re-learn a different way of solving a problem that I&apos;ve already solved in the past.&lt;p&gt;I&apos;ve been doing lots of thinking about this having written the Great American PHP Framework myself, and worked with other people&apos;s frameworks, and also worked a lot in the CMS space and the biggest conclusion that I&apos;ve come to is that the best tools are those that enable you to do things faster or more conveniently but don&apos;t actually provide any abstraction.&lt;p&gt;For example, when deploying a website there are any number of tools to &quot;abstract away&quot; the HTML layer - templating engines, markups, markdowns etc. etc. but the best way to build HTML is using HTML and testing in a web browser, always.&lt;p&gt;When you need to write some code in whatever web framework you&apos;re using to handle a POST request, you want to be as close as possible to the HTTP layer without a bunch of arcane systems in between you and what you and the underlying technology.&lt;p&gt;Sure it&apos;s handy to have tools which automate some repetitive aspects, but if you understand the underlying principles and you know the syntax of the language you&apos;re working with, you should at all times be able to just &quot;get it done&quot; however you know how without reading endless documentation and shoehorning your knowledge through a bunch of layers of abstraction.&lt;p&gt;The same goes for ORM - I want convenience of access to my data, and some automation to handle some of the more boring aspects of writing SQL, but I need to be able to mix and match (yes I know most ORMs allow you to use raw SQL, but it&apos;s always one or the other - the ORM or the SQL - I&apos;ve never used a tool that has a simple method for me to extend the ORM bits halfway through the query building process with some custom SQL).&lt;p&gt;This is my zeitgeist now and it pervades all the projects I&apos;m working on.&lt;p&gt;[1] &lt;a href=&quot;http://www.decalcms.com/&quot; rel=&quot;nofollow&quot;&gt;http://www.decalcms.com/&lt;/a&gt;</text></item></parent_chain><comment><author>dasil003</author><text>&amp;#62; &lt;i&gt;The reason I hate frameworks (even things like Django which is very easy to get started with) is that, at some point, I&apos;m asked to re-learn a different way of solving a problem that I&apos;ve already solved in the past.&lt;/i&gt;&lt;p&gt;Yes but it cuts both ways.  The reason people hate maintaining &lt;i&gt;your&lt;/i&gt; code is because they have to learn the way you did things which is buggier and half-baked compared to the way that any number of battle-tested open source frameworks did it.  Not because your way isn&apos;t good, but because it just doesn&apos;t have the mileage yet.&lt;p&gt;&amp;#62; &lt;i&gt;the biggest conclusion that I&apos;ve come to is that the best tools are those that enable you to do things faster or more conveniently but don&apos;t actually provide any abstraction.&lt;/i&gt;&lt;p&gt;An interesting conclusion, but not nuanced enough.  There&apos;s no escaping the need for abstractions, obviously there are some that you&apos;re taking for granted here such as high level programming languages and operating systems.  Fair enough to set those aside.&lt;p&gt;But then once you get into serious application-level territory you still have to decide where to abstract.  Some abstractions are more leaky than others, some are more restricting than others.  The art of it is figuring out which make sense in what scenarios.  A really good framework hits the right abstractions for a wide range of applications, but even within your custom application you have decisions to make.&lt;p&gt;For instance, you&apos;re one-helper = one-html tag rule of thumb might be a good idea if you have 5 forms on your website.  On the other hand if you have 500 CRUD forms all with a bunch of repeated composited HTML structures then it&apos;s probably not such a good idea.&lt;p&gt;I think what&apos;s underlying your conclusion is that you&apos;ve seen too many frameworks that are way too complicated for the problem at hand.  That&apos;s clearly what the OA saw, and that was really the selling point that launched Rails rise to prominence in the J2EE era.  Modern web frameworks have really learned this lesson.  Granted, Rails has gotten more enterprisey over the years—but not gratuitously—Rails core has demonstrated remarkable restraint over the years, and kept the focus on solving the 80% problems elegantly.&lt;p&gt;But if something like Rails really is too much then you have micro-frameworks like Sinatra that really just give you the barebones structure to wire some code to a web server.  Heck, due to the modularization of Rails and the extraction of libraries where applicable (eg. Rack), you can now avoid a formal framework entirely and still utilize a massive amount of code that was originally written in frameworks, now in stand-alone library form.&lt;p&gt;When programmers trot out the old adage &quot;use the right tool for the job&quot;, one of the main points is to avoid the human tendency to over-generalize.  To be the best programmer you can be, you should be constantly re-evaluating your opinions about the &quot;right&quot; and &quot;wrong&quot; way to do things.  Rather than forming concrete opinions, it will serve you better to understand the pros and cons of any approach so that you can effectively apply your knowledge new situations.</text></comment>
<story><title>Why I Hate Frameworks</title><url>http://discuss.joelonsoftware.com/default.asp?joel.3.219431</url></story><parent_chain><item><author>dools</author><text>The most important statement in this article is near the beginning, and it&apos;s still relevant today:&lt;p&gt;&lt;i&gt;&quot;I&apos;ve done small woodworking projects before, and I think I have a pretty good idea of what I need: some wood and a few basic tools: a tape measure, a saw, a level, and a hammer.&quot;&lt;/i&gt;&lt;p&gt;The reason I hate frameworks (even things like Django which is very easy to get started with) is that, at some point, I&apos;m asked to re-learn a different way of solving a problem that I&apos;ve already solved in the past.&lt;p&gt;I&apos;ve been doing lots of thinking about this having written the Great American PHP Framework myself, and worked with other people&apos;s frameworks, and also worked a lot in the CMS space and the biggest conclusion that I&apos;ve come to is that the best tools are those that enable you to do things faster or more conveniently but don&apos;t actually provide any abstraction.&lt;p&gt;For example, when deploying a website there are any number of tools to &quot;abstract away&quot; the HTML layer - templating engines, markups, markdowns etc. etc. but the best way to build HTML is using HTML and testing in a web browser, always.&lt;p&gt;When you need to write some code in whatever web framework you&apos;re using to handle a POST request, you want to be as close as possible to the HTTP layer without a bunch of arcane systems in between you and what you and the underlying technology.&lt;p&gt;Sure it&apos;s handy to have tools which automate some repetitive aspects, but if you understand the underlying principles and you know the syntax of the language you&apos;re working with, you should at all times be able to just &quot;get it done&quot; however you know how without reading endless documentation and shoehorning your knowledge through a bunch of layers of abstraction.&lt;p&gt;The same goes for ORM - I want convenience of access to my data, and some automation to handle some of the more boring aspects of writing SQL, but I need to be able to mix and match (yes I know most ORMs allow you to use raw SQL, but it&apos;s always one or the other - the ORM or the SQL - I&apos;ve never used a tool that has a simple method for me to extend the ORM bits halfway through the query building process with some custom SQL).&lt;p&gt;This is my zeitgeist now and it pervades all the projects I&apos;m working on.&lt;p&gt;[1] &lt;a href=&quot;http://www.decalcms.com/&quot; rel=&quot;nofollow&quot;&gt;http://www.decalcms.com/&lt;/a&gt;</text></item></parent_chain><comment><author>wvenable</author><text>&amp;#62; templating engines, markups, markdowns etc. etc. but the best way to build HTML is using HTML and testing in a web browser, always.&lt;p&gt;I disagree with this.  Completely abstracting away HTML is a mistake but some level of abstraction like a template engine is highly useful.  I can hardly work without some &quot;control&quot; abstraction for form elements to handle setting the attributes and ensuring the form values persist between requests.  Template engines can vastly improve the security of your code by making value substitutions safe by default.&lt;p&gt;The problem with most frameworks, in my opinion, isn&apos;t the abstraction part at all.  It&apos;s that they&apos;re over-engineered.  It seems like many frameworks approach Turing completeness as they attempt to solve more and more problems and you end up writing framework programs from within your program.  Sometimes you even get to use XML for this purpose.</text></comment>