[ufmace]

I get where you're coming from - when the initial project for the framework you're working with has so much stuff that you don't understand or need yet, it feels like a huge burden to do the simplest thing in it.

You might want to give Ruby Sinatra a whirl. I just helped a friend build a starter site in it. The Hello World for it is 1 file with 4 lines of Ruby, no config files at all. Save that 1 file, run it, and you have a live website.

What I think really makes it cool is that there is a decent amount of sophistication to it, but you only see it when you need it. It doesn't force any particular way of doing things onto you. It's also kind of a cousin of Rails, so if your needs get to that level, you should be able to switch over pretty easily and make use of the enormous ecosystem of gems.

I think express.js on Node has kind of the same idea, might be worth a look also.

[_w3e8]

"It doesn't force any particular way of doing things onto you."

Might as well be

"Your app is spaghetti 1 year after you leave the company."

[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.