Hacker News new | ask | show | jobs
by malyk 4736 days ago
That's definitely a decent list, but the problem for me is that you are also forced to have EVERYTHING ELSE! It's all nicely required in the for you in your app and there aren't straightforward ways to remove 90% of the stuff you don't want.

I work with rails every day for the last 6+ years and it was a revelation when I started. Now I still think it works decently well for large web-apps, but it's just grown way to big over the years. Basecamp is awesome and a great proving ground, but I'd wager the vast majority of apps written in RoR come no where close to needing most of what's included today.

1 comments

I'm curious as to why having that stuff available is a bad thing?
memory overhead (both for the machine and human), modifying core classes unnecessarily, complexity of third party software, setting defaults to on that aren't applicable to 90% of apps (see turbolinks which breaks the way the web and browsers work).

I'll admit to being on a hard-core minimalist, simplicity, explicit coding kick recently, so I'm already biased against behemoth frameworks. Rails is wonderful if you need that level of complexity/features. I don't think most apps do and we're "forcing" everyone to write basecamp when that is overengineering for most apps.

I'd add security to that list. Rails' most notorious vulnerability was the result of an on-by-default feature that 90% of developers never even needed. I'm not suggesting that Rails is inherently insecure or that Sinatra/Rack cannot be exploited, but less unnecessary code leaves less potential for vulnerabilities; this is especially true in the Ruby world where many developers are eager to `gem install` anything with a few stars on github.