> This is my main problem with this line of thinking. Developers aren't actually developing anymore. They are mashing together frameworks.
Usually you have one framework and then you mash together a bunch of libraries. The framework exists as a way to abstract the most common functionality of your chosen platform. A good framework eliminates a lot of boilerplate without getting in your way when you need to go beyond the common functionality.
The ironic thing about your post is that PHP itself has a bit of a nascent framework quality to it. It was developed before web frameworks of course, at a time when everyone was writing Perl CGI scripts using a bunch of libraries. The revolutionary aspect of PHP and mod_php in particular, was that it had automatic hooks into all the common aspects of the HTTP cycle, including the page metaphor, which meant you could change a static page into a dynamic page with no effort. PHP was state of the art when websites were mostly still just pages. Serious programmers laughed of course, how could you build a serious application in this glorified templating language? So they continued to develop their "proper" frameworks like Struts, Zope and countless others rooted in the experience of GUI developers from ages past.
However as web development experience and understanding matured, there was a widening gap between PHP and the enterprise frameworks. And this gap is squarely where Rails was dropped in 2004. There are so many things that are common to all web applications that PHP doesn't handle. DHH's brilliance was not so much in the details of the original Rails code, but in picking and choosing best practices and unifying them in one package in a minimal way. I think this was instrumental in web framework developers from all languages re-evaluating what was really necessary and what cruft could be eliminated.
Nowadays Rails is pretty enterprisey in capability, but it still avoids most of the overhead present in enterprise frameworks of 10 years ago. The minimalist torch has been carried forward by upstarts such as Merb and now Sinatra.
The strength of these various frameworks is that they do things that tens of thousands of developers need to do every day in a standardized way that's had massive input and refinement over time. When you use these frameworks you can hire people and they hit the ground running. When you use your own personal library then every new developer has to get up to speed on your dime, and you foot the bill of maintenance yourself rather than gaining the advantage of a large open-source community.
Usually you have one framework and then you mash together a bunch of libraries. The framework exists as a way to abstract the most common functionality of your chosen platform. A good framework eliminates a lot of boilerplate without getting in your way when you need to go beyond the common functionality.
The ironic thing about your post is that PHP itself has a bit of a nascent framework quality to it. It was developed before web frameworks of course, at a time when everyone was writing Perl CGI scripts using a bunch of libraries. The revolutionary aspect of PHP and mod_php in particular, was that it had automatic hooks into all the common aspects of the HTTP cycle, including the page metaphor, which meant you could change a static page into a dynamic page with no effort. PHP was state of the art when websites were mostly still just pages. Serious programmers laughed of course, how could you build a serious application in this glorified templating language? So they continued to develop their "proper" frameworks like Struts, Zope and countless others rooted in the experience of GUI developers from ages past.
However as web development experience and understanding matured, there was a widening gap between PHP and the enterprise frameworks. And this gap is squarely where Rails was dropped in 2004. There are so many things that are common to all web applications that PHP doesn't handle. DHH's brilliance was not so much in the details of the original Rails code, but in picking and choosing best practices and unifying them in one package in a minimal way. I think this was instrumental in web framework developers from all languages re-evaluating what was really necessary and what cruft could be eliminated.
Nowadays Rails is pretty enterprisey in capability, but it still avoids most of the overhead present in enterprise frameworks of 10 years ago. The minimalist torch has been carried forward by upstarts such as Merb and now Sinatra.
The strength of these various frameworks is that they do things that tens of thousands of developers need to do every day in a standardized way that's had massive input and refinement over time. When you use these frameworks you can hire people and they hit the ground running. When you use your own personal library then every new developer has to get up to speed on your dime, and you foot the bill of maintenance yourself rather than gaining the advantage of a large open-source community.