|
At that point, I wonder what the benefit of using rails is? Rails shines most when you do things as intended. Even though I wouldn't have designed rails the way it is (remote forms and .js.erb views anyone?), it works really well for a large class of applications. Of course you may eventually hit a wall, but that happens when software outgrows it's original requirements. That doesn't mean you have to build a system for millions of concurrent users from day one. Especially not, when you're making accounting software or a crm or some other run-off-the-mill webapp. In my experience, rails "improvements" are often suggested, when a developer is faced with a large mudball of a rails application that doesn't do things according to convention. This can quickly happen, because rails is deceptively easy to learn. Many developers I know (myself included), started writing a serious app in Rails, without learning a lot about it. Heck, if you're a rails developer and honest with yourself, you probably didn't even read all of the rails guides. In addition to that, I recommend reading a book such as "The Rails Way" front to cover, joining the mailing list, following the core team's blogs and potentially even going through the code. I also DON'T recommend taking your patterns from random blog posts or stack overflow. Rails is very well documented and you can generally find what you need in the docs. As infuriatingly dismissive as his tone sometimes is, I've actually found it best to follow dhh's advice. Not only because I generally agree with it, but also because it's likely to be the best supported design in future rails versions. |