Hacker News Reader

Comment by subwindow | Hacker News Reader

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.

View on HN

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

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.

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

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.

Reply on news.ycombinator.com