This is a weirdly emotional appeal that ignores the fact that Rails is not Struts, is nothing like Struts, isn't standing still, was more or less rewritten not very long ago by assimilating its best competitor, and that the next ORM or gem that isn't popular today on Rails is very likely to be bootstrapped and implemented in the context of Rails --- unless its key distinguishing value is "a not-Rails replacement for something Rails already does", which many people on this thread are pointing out is a seductive trap.

Rails is good. For an alternative to be compelling, it probably needs to be more than just "different"; it needs to be better. What I see people saying here is, yes, "stripped down" is different, but in practice that difference turns out not to be better. The parts of Rails you really can't get around using tend to be parts you're going to need in a Sinatra or Padrino app, and rewriting them just for the sake of it isn't a win.

Aw, come on, nothing I said was critical. It’s a very good thing to be conservative in places. If you’re sitting down to write a new program, how many things ought to be innovative? Where should you be breaking new ground? You can’t pick up a new programming language, roll your own new framework, learn a new programming paradigm, use it to start a new company and go into a new market, all at the same time.

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 "Java web development", you said "Struts".

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.

> We adopted it. It turned out to be poorer than Rails for our use cases.

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 disagree. The main reason I dislike Rails is that it is too complicated. When working with it every day, I regularly come across issues with it that require that I delve into the source code. More often than not that is a depressing venture.

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.

When's the last time you had to dive into the Rails source code? The only bits of Rails I'm consistently familiar with at the source level are the code that maps HTTP parameters to the "params" hash and into AR model attributes, and the session cookie stuff --- and those are professional interests, not "I couldn't figure out how to use it" things.

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.

About a week ago I had a problem with after_commit callbacks not being called. It turns out (after diving into the AR source) that they indiscriminately swallow errors from after_commit callbacks. If you're testing a newly-created callback it is difficult to determine whether it's actually been called or merely just raised an error.

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.

"The after_commit and after_rollback callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block. If any exceptions are raised within one of these callbacks, they will be ignored so that they don’t interfere with the other callbacks. As such, if your callback code could raise an exception, you’ll need to rescue it and handle it appropriately within the callback."

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

"The whole callback chain is wrapped in a transaction. If any before callback method returns exactly false or raises an exception, the execution chain gets halted and a ROLLBACK is issued; after callbacks can only accomplish that by raising an exception."

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

I'm not sure what your point is. He was talking about after_commit callbacks. Your quote is about the callbacks during a transaction, not after it.

Huh. Thanks. I looked for a long time and didn't see that. The closest I got was an extremely old lighthouse ticket where Aaron Patterson suggested that they change the behavior to raise errors, but there was no followup.

i didnt want to write new code each time my data-model changed: migrations, model code, new controllers/views. this meant a Resource class, a uniform controller request/response cycle following web-arch/linked-data standards. at this point, would have had to significantly monkeypatch both rails and its attempts at providing a generic Resource class to override its magic (and/or incur the CPU usage for the magic to do what i didnt want). it was a lot simpler to just start with a Rack handler from scratch.

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

I can second most of this. I haven't needed to dive into the source on Rails 3 at all, except for figuring out why some bit of backwards compatibility wasn't quite working. Considering the project was initially written on version 1.mumble.mumble, I haven't even had to do much of that.

When I started working with Rails, I didn't understand it. I wanted to see how all the magic worked. Then I gave it a second go, and skipped trying to learn how Rails was built, but just assumed the framework worked the way all the code samples said it would work. Success.

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.

Take a look at Ramaze. It's my first choice for doing Ruby Web development and I've found it works really well for projects of any size.

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

I had to learn Rails & Ruby at the same time. Early on I struggled because it was hard to figure out where Ruby stopped and Rails began. It took me about 6 months to get comfortable with both of them.

> If you are resistant to adopting a new framework and having to reinvent a bunch of stuff, congratulations. You may be an early adopter or hacker in other areas of your profession, but as far as web development goes, you’re a conservative.

Then I must eat rocks and ride dinosaurs, because Rails is already too fast-moving for me.

I don't do Rails full-time right now, and my biggest problem is that Rails changes all the time. Rails' documentation is basically a Googleverse full of blog entries, and you have to compare the (often hidden) timestamps to understand which blog entry is more relevant. I often enjoy a Railscast only to find out that nothing of it is applicable anymore.

Minor updates to Rails, Rubygems, Bundler or even Ruby can break everything without warning. And dare you accidentally admit to #rubyonrails that your customer is still using svn or not on 1.9 yet, and you will be publicly ridiculed. It takes some time every month to even keep your existing Rails apps secure but running.

Excuse the rant here, but from a casual Rails hacker's perspective, I actually miss stability and not change.

Yes, I particularly enjoyed applying security fixes from the so-called stable branch and suddenly having all my validation messages corrupted, or form parameters randomly truncated.[1]

[1] http://david.rothlis.net/rails/experience_report/#stable_bra...

I'm all for new ideas and tools, but you have to bring something to the table other than just being different. And just being "smaller" is not enough.

This is the problem with Padrino- it isn't different enough. We don't need a smaller MVC Ruby framework, as there isn't much space between what Sinatra is great for and what Rails is great for.

There is also an assumption that scaling Sinatra up is a good idea. I'd propose that it's likely not.

It actually turns out that being smaller can be worse if it means you're just building a half-assed implementation of something Rails 3 already does well.

I beg to differ.

There is a lot of space to cover between a bare-bones HTTP DSL (which Sinatra is) and an opinionated full-stack like Rails. For example, Padrino allows you to freely choose between a lot of Ruby ORMs _and provides support_ to use them. Try that with Rails.

As another example, Padrino allows you to do Rails-Engine-like things in a very natural way (by hosting multiple applications in one Stack etc.). It is not a Rails rehash on a different base.

The Rails 3 rewrite / MERB integration was supposed to accomplish this by allowing pluggable ORM's and different libraries. Is Padrino trying to be the new MERB? I think extending Rails to be more modular is the way to go, not more frameworks.

What's the support Padrino provides for non-ActiveModel ORMs? How does Rails not provide that support?

You can host arbitrary Rack applications inside Rails with a single line in routes.rb.

Can you host arbitrary Rails applications in other rails applications like you can host arbitrary Padrino applications within another Padrino application? (it should even be possible to host padrino apps in any other rack app, though I've never done that so far, it might need a little hackery)

Yes, they're called Rails Engines:

http://edgeapi.rubyonrails.org/classes/Rails/Engine.html

Rails is a Rack application, so yes a Rails app could play host to more than one sub app. In fact this is such a good pattern, that Rails core added Rails Engines which do just but better.

I'm utterly content with Rails 3. Having used versions 1 & 2, I can definitely say 3 is quite an upgrade and decoupling which is competitive on most of the points in this slide. It's almost like this slide was based on a Rails 2 comparison.

I find rails popularity picking up, but I don't think we're anywhere near comparing it to struts yet (I used to be a j2ee dev and used struts quite a bit... painful).

When I want to play around with the next big thing I mess around in Node.js.

I've known about Padrino for a while now (and built some small apps with Sinatra), and I'm sure it fits some peoples needs and is a great project... but I have yet to become interested enough to bother. It's just not that appealing right now, and I don't think it's because I've become too comfortable or conservative etc. Of course if I start to hear a lot about it I'll spend a little more time playing with it.

>Padrino’s best bet is to appeal to a younger, fresher group of programmers who haven’t spent years learning Rails

Anecdotal contradiction incoming. I started with Rails years and years ago (can't even remember when). I moved to Merb when Merb was the new hotness because I preferred it's modular approach. After Merb was "merged" (i.e. a few of its philosophies were put into Rails and Merb died due to lack of development), I caught on to Padrino and was impressed by it for the same reasons I was impressed by Merb. I program in Rails for a living but use Padrino for my personal projects.

I actually think a potential knock against Padrino is that it's not quite as easy to get into as Rails. When I got into Rails, it was all "create a blog in five minutes" which is what attracted me to it. There was a point where I didn't even understand the distinction between Ruby/Rails -- it was just one big scripting language to my PHP-addled mind. I think Padrino (or even just plain Sinatra) has a slightly steeper learning curve; but it's hard for me to comment on that necessarily because I am no longer a beginner and my perspective is a lot different.

I learned and fell in love with Rails because I was stuck working with Struts and I saw how much easier and better life could be. So, at least for me, the decision to use a different framework didn't follow what you describe. I'm pretty sure if I came across something that allowed me to solve my problem in an easier and better way than Rails would, I'd use that instead.

For example, if I were building a mobile API that I was fairly sure wouldn't require a web interface later on, I'd consider using something simpler and more performant than Rails. It's not a matter of being an early adopter vs. a conservative developer, it's a question of practicality. As it always should be.