You pick and choose your battles, you pick and choose where you’re going to trade a little risk for reward. For the things Rails does well, there’s very little attraction in replacing it with something that is not-Rails if you already use Rails. Ergo, something not-Rails has to either do somethingRails doesn’t do well or appeal to people who don’t already know Rails.

Rails isn’t standing still but neither is Java web development. My ex-colleagues are constantly boasting of the great new things going on in my old ‘hood. But even so, the great new things are centered around the old things it already did well. Same with Rails, it does a particular thing well and “not standing still” doesn’t mean it will magically turn into node.js one day.

If we were talking about startups, nothing I am saying would arouse the slightest controversy, it’s the old “crossing the chasm,” “disruptive innovation,” or “innovator’s dilemma” mechanics, only for a free tool instead of a business or service.

You didn't say "break new ground", you said "younger developers".

You didn't say "pick and choose", "risk and reward", you said "resistent to adoption" and "conservative".

And you said it on a thread mostly populated with people who used Sinatra --- we weren't "resistent" to Sinatra (I was seduced by it). We adopted it. It turned out to be poorer than Rails for our use cases. Given two options, one of which was better than the other, we used the better option; that's engineering.

Yep I had this exact revelation with a project I was working on. About half way through implementing my own general-purpose validation function and REST/CRUD routes for my models I admitted to myself that I was wasting time. These things are solved problems. I have a much greater appreciation of Rails as a result.

I use Sinatra as a quick way to put a web interface on top of Ruby code, Rails for any non-trivial CRUD paradigm web application.

I would love something more simple, that operated with less magic, and had code that was easier to understand. I'm not sure if Padrino is the answer, but it certainly merits a second look.

I'm asking seriously, because I spend about 20% of my work time writing Rails code for a bunch of different Rails apps, and --- at least since Rails 3 --- I never have to do this. And I'm a C programmer, so "diving into the code to figure shit out" is a first instinct for me too.

I couldn't have figured that out without reading the source- it's not documented. From the developer level that behavior is indistinguishable from magic, and the callback code in AR tries to act like magic as well. It's extremely difficult to follow, let alone understand.

http://guides.rubyonrails.org/active_record_validations_call...

― http://guides.rubyonrails.org/active_record_validations_call...

ive been using my web framework for 5+ years for personal and professional projects, and as far as i know there are no other users. Ry Dahl was churning out all sorts of 'concurrent' web-frameworks and servers in Ruby building on EventMachine and so on for years, and im pretty sure i was one of the only people using his code. eventually he scored a hit as node.js when finally rewriting one of the concepts in Javascript

Rails definitely makes specific assumptions about how things should work and especially how database operations should work. If you're always looking under the hood, you're probably right -- it's not suited to your style.

What I especially like is that I can start with a single-page static HTML "app" and evolve it out as needed, and refactoring or moving things about are never an issue.

I don't worry about having to turn stuff off or tripping over someone else's conventions.

(For the latter: I do not like the convention of grouping all models in folder, all views i another, and controllers off some place else. I prefer to treat related MVC components as a "tuple" and keep them together. This is how, for example, it's done with Monkeybars; I find it much more logically coherent, and this is how I organise my Ramaze projects.)