I agree Rails has evolved to become many of the things that DHH first complained about in so-called Enterprise frameworks. But that's because a wider audience has wider problems to solve than Basecamp 1.0. At the end of the day, Rails 3.2 for all its complexity still "gets" server-side web development better than the antiquated Java frameworks that it replaced ever did.
What Rails really never got was client-side development. Even as it ushered in the era of easy AJAX support in 2005, it was based on a poor fundamental understanding of how to do good client-side development (to be fair, no one really had that understanding for javascript apps back then because we were lost in the weeds of browser compatibility). Over the years it's improved only in fits and starts, with bandaids and ancillary features like the asset pipeline and coffeescript (RJS was probably one of the worst ideas ever hyped).
So to me what the new crop of frameworks bring to the table is rethinking things from a deep understanding of client-side development, in much the same way that Rails rethought things from a deep understanding of server-side web development. I don't hold much hope for Rails to get good at client-side development due to the fact that DHH doesn't really like client-side development (as indicated by some of his commentary in the Basecamp Next caching article). He likes coffeescript because it's more like ruby and thus less painful, but the fertile ground of client-side development techniques will never be tilled by someone with this attitude. Javascript may not be the prettiest language, but it is powerful and paradigm-shifting when embraced to its fullest.
All that said, server-side ain't goin away, and Rails is still one of the best ways to develop server-side apps. If Rails was fast I would happily stick it on the server as I explored client-side development independently. Unfortunately I'm really starting to feel like Ruby performance is holding me back and that it will be impossible to fix regardless of how seriously Ruby and Rails core get about performance. Who was it that said "everything can be fixed with another layer of indirection, except performance"?
> All that said, server-side ain't goin away, and Rails is still one of the best ways to develop server-side apps.
I'm not sure. You only need a server-side if you have users, there are a lot of apps that don't need users. For those that do there's no reason why your server-side code needs to sit next to your web server as it does today. What you need is a good API framework, which Ruby does well today, but perhaps should be its primary focus in the future.
What Rails really never got was client-side development. Even as it ushered in the era of easy AJAX support in 2005, it was based on a poor fundamental understanding of how to do good client-side development (to be fair, no one really had that understanding for javascript apps back then because we were lost in the weeds of browser compatibility). Over the years it's improved only in fits and starts, with bandaids and ancillary features like the asset pipeline and coffeescript (RJS was probably one of the worst ideas ever hyped).
So to me what the new crop of frameworks bring to the table is rethinking things from a deep understanding of client-side development, in much the same way that Rails rethought things from a deep understanding of server-side web development. I don't hold much hope for Rails to get good at client-side development due to the fact that DHH doesn't really like client-side development (as indicated by some of his commentary in the Basecamp Next caching article). He likes coffeescript because it's more like ruby and thus less painful, but the fertile ground of client-side development techniques will never be tilled by someone with this attitude. Javascript may not be the prettiest language, but it is powerful and paradigm-shifting when embraced to its fullest.
All that said, server-side ain't goin away, and Rails is still one of the best ways to develop server-side apps. If Rails was fast I would happily stick it on the server as I explored client-side development independently. Unfortunately I'm really starting to feel like Ruby performance is holding me back and that it will be impossible to fix regardless of how seriously Ruby and Rails core get about performance. Who was it that said "everything can be fixed with another layer of indirection, except performance"?