I've rewritten this entry because I was told by multiple people not the least of whom was my wife (a person who can actually write sentences that make sense) that an instant message chatlog between myself and Don Thorp didn't make for a readable weblog entry.
It all started when Don pointed me to this entry about what should and should not go into Ruby on Rails: http://www.loudthinking.com/arc/000407.html. The way he put it, it gave him heartburn.
I read it and agree. The position of the author is that higher level constructs have no place in Rails and that in general it's futile to try and construct higher level software components for websites. I consider that to be a big mistake. They are missing is that the underlying model of, for example, ZWNews and MovableType and Wordpress is fundamentally the same. Most blogging software, forums, comment software, link counting, polls, etc. can be reduced to a basic subset of features which are in just about any of the software that various sites are using. If there's that much commonality then you can produce that subset of functionality, offer a few simple hooks into it so it can be extended in a couple of places and it'll probably serve the needs of 80% of the people who are building sites.
I would argue that they make this mistake because:
- They don't spend their time building one weblog after another or five or six forums in succession so they don't see the common elements which underly all of them. This is similar to the fallacy of so many game developers who start off by building a "reusable" sprite library or 3D engine before they begin their first game. They either fail completely or they succeed at building something but pronounce it impossible when they cannot then reuse it themselves later for another project or persuade anyone else to reuse it. It's a poor fit because they didn't grow the API based upon the needs of multiple projects, they instead attempted to divine the interface and capabilities based upon what they thought it would need.
- They imagine both a model and a UI which goes with it. That never works. You can have a UI which is a starting point or an example but the focus of the code has to be on the model and the administration for that model.
Kasai is an excellent example of this. It's design is a good one for an authentication and authorization system which will serve the needs of 80% of all web applications. I know what I've needed in the past and I can look at it and assess whether this would have met the needs of a large number of sites I've worked on and the answer is yes. In fact it really could stand to be reduced or simplified in a few areas and it would still have served my needs.
I think what most people fail to see is what is really a reusable component in real life. In the world of IC components a digital micromirror is a reusable component. It's not a TV all by itself. It has no tuner, memory, light source, etc. etc., yet it's a reusable piece. It's going into all manner of TVs today, all different in subtle or large ways, and for all I know somebody is building a huge array of them for a high resolution video wall.
So when I switch to the world of software, specifically, web applications I should be able to identify reusable pieces that occur over and over again with variations. In the world of websites you frequently have comment systems that have the following characteristics. There are a large number of unique conversations. The conversations are not linked to each other. Each one is a straight linear series of comments. Each comment needs to be attributed to an individual which could easily be referenced via a unique ID. Each comment may have some numeric rating associated with it or a pointer to another set of properties. That is a reusable component. I can build it and you could drop it into the user ratings at the bottom of Amazon products or the file comments at Stock.Xchng or Fark or half a dozen other places and you wouldn't notice that it had changed. Even if the first generation of the component isn't a great fit and needs work (like Kasai) the second or third will be because it was adapted to the real needs of a lot of users.
It's good that there is a major emphasis on making the infrastructure solid in Rails but saying that there shouldn't be a set of libraries that go with it to provide some reusable components for counting links clicked on, comments, authentication/authorization, etc., etc. is like saying that Java would have been better off being just like C++. A language without its huge supplementary library. That library, a well designed one which provided pieces we use every day for things like collections, XML parsing, regex, etc. determined well what some "high-level" components were which could be widely reused. Rails doing the same would only strengthen the framework not weaken it.
I'm not going to post any more game development or Big Villain news on my personal blog anymore. I've got a new one devoted only to that subject at 
When I started reading the series of blog posts on the site 