5 ms·

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

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

tptacek 15y ago
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.
- raganwald 15y ago
  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.
  - tptacek 15y ago
    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.
    - tkahn6 15y ago
      > 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.
- subwindow 15y ago
  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.
  - tptacek 15y ago
    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.
    - awj 15y ago
      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.
    - subwindow 15y ago
      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.
automach 15y ago
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.
- tptacek 15y ago
  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.
- Argorak 15y ago
  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.
  - tptacek 15y ago
    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.
    - Xylakant 15y ago
      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)
rapind 15y ago
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.
gurkendoktor 15y ago
> 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.
- drothlis 15y ago
  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_branch http://david.rothlis.net/rails/experience_report/#stable_bra...
lyudmil 15y ago
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.
Eleopteryx 15y ago
>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.

tptacek 15y ago

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.

raganwald 15y ago
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.
- tptacek 15y ago
  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.
  - tkahn6 15y ago
    > 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.
subwindow 15y ago
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.
- tptacek 15y ago
  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.
  - awj 15y ago
    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.
  - subwindow 15y ago
    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.

automach 15y ago

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.

tptacek 15y ago
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.
Argorak 15y ago
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.
- tptacek 15y ago
  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.
  - Xylakant 15y ago
    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)

rapind 15y ago

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.

gurkendoktor 15y ago

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

drothlis 15y ago
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_branch http://david.rothlis.net/rails/experience_report/#stable_bra...

lyudmil 15y ago

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.

Eleopteryx 15y ago

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