Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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

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.

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.

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

Reply on news.ycombinator.com