3 ms·

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 feel

by ufmace 11y ago

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.

gjolund 11y ago
"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 11y ago
  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 11y ago
    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.

by ufmace 11y ago

gjolund 11y ago

"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 11y ago
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 11y ago
  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.