Some author wrote a column “Moving on from Rails” (I strongly dislike self important authors who attribute their publications to their “handle” instead of their actual person). It’s mostly a well written article, however, the author did not not allow for feedback or comments.
My only complaint about the article is that it seems that this person does not have the perspective of having been through the “history repeating itself” or “waterfall” that is our industry.
For example: as servers were more expensive and more powerful “we” shifted the processing to the server. And as memory and personal computers became cheaper and more powerful “we” moved processing to the client-side. Additionally the core of the application has shifted. At one time there was a single database and now there are farms … and so the core application has shifted and the layers are stacking.
Actually, the layers are not stacking at all. They are the same as they have always been. They are simply more granular in some cases. The OSI network model still stands as a description of what we have architected.
As to why the author is moving on from RoR (Ruby on Rails) has probably more to do with “me too” rather than any real technical justification. This behavior typically happens when a programmer is starting to burn out (either with the framework or the job) and so it is not an inditement of the technology but the person.
me thinks he doth complain to much
As to the conclusion that RoR answers fewer questions is not much of a conclusion. The same can be said of any language or framework and it is terribly subjective. It is also based on the weighted important by the author and not any real metric. Which is why I think the author is unhappy.
As for me and my projects, languages and frameworks. I’m mostly client driven. I like to guide clients toward technology that I like or I’m familiar with, however, they are all general purpose enough that they could complete the job easily enough. For me the question has less to do with the tools than it does the architecture. And with that in mind it’s a better idea to have more tools in the toolbox than one tool you think is crappy.