[ufmace]

There's some truth to that. I think it's all about knowing the right tools for the job. If you spend several dev-years on a Sinatra app, then you probably will have a unmaintainable mess unless you have some good architects enforcing a sensible structure on it.

Sticking with Ruby for examples, if you want to put up a quickie site with 4 routes and no DB, then it seems kinda silly to pull in Rails and deal with all of the complexity and expectations. Throw up a Sinatra site and be done with it.

On the other hand, if you're getting more demand for it and now you want more logic and analytics and a DB after all and some user accounts etc, then you should know when it's time to move over to Rails.

[gjolund]

I've found that it's all about the team.

If it is a small team of close knit developers who communicate well, and expect to work together for a long time. Roll your own setup, loads easier and much more flexible.

If you are a corporation with reasonable dev turnover and good management, you might be able to pull off your own solution too.

If you are using contractors, have high dev turnover, a distributed team, and especially all of the above. Use a framework, any framework, otherwise you will wind up with a disaster within 6 months.

There was a really great talk a couple years ago about Twitter's defunct FlightJS framework. The framework was meh, but something in the presentation stuck with me, "If the shit is in a box, no one can smell it.".

I took that to mean that if your application is structured and organized ( like what a framework imposes ), suboptimal parts of the application will have a smaller impact on the app as a whole, and refactoring those parts is often a matter of just "throwing out the box".

On the front-end React has done a fantastic job of providing lots of boxes for contractors to shit in.