21–30 of 93 posts
As someone that's just crossed a year or Ruby/Rails learning, having scaled the majority of the now massively steep learning curve, I'll stick with the complexity that is Rails.
Ah the old sunk cost fallacy.
It could be a choice-supportive bias, possibly irrational escalation, and maybe a bit of ostrich effect, but it's not a sunk cost fallacy.
Thanks but no thanks. Having just become a productive Rails programmer and grasped a lot of complexities, use cases and diversity of the framework, I'd rather use the shotgun that Rails is to kill any fly that stands in my way. As long as the fly is dead, Rails did its job.
Would like to hear from people who have taken a user-facing Padrino/Sinatra app all the way through production and into maintenance. I have a few tiny services and extremely specific apps running on Sinatra, but any time I've needed to expose any kind of richness to the user I've ended up reimplementing in Rails as I kept reaching for things in ActiveSupport / ActionView etc. At some point I notice myself essentially…
It's not that there's anything wrong with Sinatra and Padrino. The problem is twofold: the idea behind those two frameworks is seductive, but Rails 3 is really good. It's just not a stupid framework.
Thanks but no thanks. Having just become a productive Rails programmer and grasped a lot of complexities, use cases and diversity of the framework, I'd rather use the shotgun that Rails is to kill any fly that stands in my way. As long as the fly is dead, Rails did its job.
Not sure why the author of the slides presents rails as a confusing mess. If you don't like the asset pipeline then don't use it. If you don't like the scaffolds then don't generate it. If you don't like active record, then don't use it. I love the fact that these new frameworks are popping up, but why try to pull down rails in the process? If this addressed legitimate issues rails has, then I would not have a proble…
Earlier quoted context omitted.
Ah the old sunk cost fallacy.
I'm not sure that's 100% accurate. "sunk costs are retrospective (past) costs that have already been incurred and cannot be recovered", says Wikipedia. However, investment in Rails can be "recovered", because it's a useful, marketable skill. Switching to something else will incur costs as well, so the benefits would need to be both high and certain to really make it a 'sunk cost fallacy', no?
It is. You're conflating several different notions. A sunk cost fallacy is the idea that because you've invested a certain amount of resources (time, in this case) in a particular approach, it would be foolish to switch because all the resources you've already expended would be "wasted."
Earlier quoted context omitted.
Ah the old sunk cost fallacy.
It's not a sunk cost fallacy. It could be a choice-supportive bias, possibly irrational escalation, and maybe a bit of ostrich effect, but it's not a sunk cost fallacy.
Would like to hear from people who have taken a user-facing Padrino/Sinatra app all the way through production and into maintenance. I have a few tiny services and extremely specific apps running on Sinatra, but any time I've needed to expose any kind of richness to the user I've ended up reimplementing in Rails as I kept reaching for things in ActiveSupport / ActionView etc. At some point I notice myself essentially…
I never miss ActionView, but sometimes include parts or all of ActiveSupport, so I don't miss that either. I love the simplicity of the sinatra stack and I've never been much of a rails fan (too tightly integrated for my taste, the 1.x and to a lesser extend the 2.x version were too magic sometimes etc.) Most middleware is rack-based anyways.
For me the winner is that a padrino app is a full, mountable rack application so I can mount any padrino application anywhere inside any other application. I can actually implement complete components as a padrino app and mount and reuse them anywhere I wish. (The padrino admin works that way)
Padrino’s best bet is to appeal to a younger, fresher group of programmers who haven’t spent years learning Rails, just as Rails appealed to a younger, fresh generation of programmers who hadn’t spent years learning Struts. Those folks will find applications for it where Rails actually gets in their way. As they reinvent parts os Rails, they’ll invent new things that fit their model domain better than Rails does.
I’d bet that if Padrino becomes successful, it will do so with ORMs and other gems that aren’t popular on Rails because they haven’t been invented yet.
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.
I empathize with the comments from the folks who are already heavily invested in Rails. It’s so easy to “just throw the whole stack at a problem” or “kill a fly with a shotgun.” This is always the way, and it’s why new ideas rarely displace the old ones directly. Instead, they have to appeal to a younger, nascent “market” that are not attached to the old product. Padrino’s best bet is to appeal to a younger, fresher…
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.