7 ms·

Ruby Frameworks? Which one? Bye bye Rails.

146 points by DAddYEz 15y ago

fingerprinter 15y ago
100x this. I hope Padrino picks up more steam and people it give it more love. It absolutely kicks ass and I would choose it over Rails everytime now. Now, if someone would write Padrino with Python, I'd be one really happy camper!
timinman 15y ago
I definitely love Sinatra, and I'm impressed by the admin interface, but it looks like there's no support for DataMapper as an ORM. I also wonder if this is just turning Sinatra into Rails. I think for the now I prefer to just build a Sinatra app and add gems and plugins as I need them.
- vidarh 15y ago
  The thing I like the most about it is the part where they demonstrate selectively including certain elements into Sinatra. I like Sinatra exactly because it doesn't come with the kitchen-sink - like you I prefer to just add gems and plugins as I need them (and I rarely find I do), but if I do I might look at Padrino. (As for the admin interface, their site claims it has DataMapper support)
- glassx 15y ago
  Same here. I really like Sinatra's gem ecosystem, and with unobtrusive Javascript I don't have much framework-dependent code on the views, nor helpers like his link_to confirm example, in the presentation... I admit that sometimes I miss generators, but Sinatra's boilerplate code is so minimal that I just don't care much anymore.
  - timinman 15y ago
    Once before starting a biggish app I sat down and wrote my own generators to create controllers with crud actions and views for them.
- base 15y ago
  Padrino supports the following ORMs out of the box: mongoid, activerecord, datamapper, couchrest, mongomatic, ohm, ripple, sequel. Take a look here: http://www.padrinorb.com/guides/generators http://www.padrinorb.com/guides/generators Padrino is just a Sinatra app with a very basic skeleton and some added functionality. Almost all the pieces are modular and doesn't have many requirements from the start.
  - Argorak 15y ago
    On small addition: Padrino is also a Layer that stitches multiple Padrino Apps together, which is the true shiny feature.
  - timinman 15y ago
    Thanks for that. I mistakenly thought it only supported the two listed in the presentation.
- sp4rki 15y ago
  I remember using Datamapper with Sinatra to develop a pretty basic system for some weird user registration needs of a company offering medical assistance in the way of air ambulances in 2010. I don't really know if it's still supported since I've been doing .Net stuff since then... but I can definitely tell you it WAS supported two years ago, and I seriously doubt that they don't now.
johnx123-up 15y ago
Looks like a Xitrum (Scala web framework) to me.
beggi 15y ago
This reminds me of Flask for Python (nb. although more is built in to Padrino, most of the functionality for Flask is provided by plugins). I've recently started using Flask for new projects in favor of Django. I feel that most of the libraries I use are framework agnostic, stuff like ORM (SqlAlchemy), PDF generation, redis/mongodb adapters etc, so being able to pick what fits and leave the cruft out is great. But besides that, I feel that in recent times development is moving much more to the client - and client code like Javascript/CoffeeScript, Java for Android and Objective C, is getting much bigger at the expense of server side code. This is recently evidenced by the new 37signals Basecamp Next app which is 50/50 CoffeeScript/Ruby. So the server side programming is on track to becoming "just" a API endpoint for all these different technologies and I think micro frameworks like Flask and Padrino are very well suited for that.
- tizoc 15y ago
  I'm working on Fiasco, which intends to be similar to Flask but for Ruby. It is still a work in progress, but you can see it here: http://tizoc.github.com/fiasco http://tizoc.github.com/fiasco
- jemeshsu 15y ago
  Have you try Pyramid? It's similar to Flask.
- viandante 15y ago
  Could you go more in detail with your experience with Flask? I am new to web development and I am developing a landing page in Flask. I tried to use Django or Rails in the past but I just hated not being able to understand what I was doing. Flask is really, really, straightforward, I rolled out my own authorization plugin as a decorator and it feels good to be so close to the application. But I keep thinking if I should move to RoR in case my landing page succeeds and I will have to build the real application. Mostly, I am concerned about hosting and scaling...
nyrb 15y ago
Padrino is really nice web framework for Ruby. I have used it for experimental projects. My work was using latest Padrino framework at work, but extremely unhappy with the its performance (slow response). We had ported the app to Rails 3.1 for better performance. (We will upgrade it to 3.2 soon) In fact, I think Padrino is pretty ideal for personal and small apps. Not really ideal for medium to large apps. Just my opinion and experience.
- DAddYEz 15y ago
  Warn: is opinionated Btw I switched lots of projects from rails to padrino due to the slow performances of rails. I built a small test suite where you can find that Padrino is upto 4x faster than rails. Check it out: https://github.com/DAddYE/web-frameworks-benchmark https://github.com/DAddYE/web-frameworks-benchmark Feel free to show me that Im wrong.
  - nyrb 15y ago
    I am not against the Padrino web framework. I still like it. :-) So your benchmark only have tested against the small "Hello World" app. Maybe that's why I suggested that Padrino framework is pretty ideal for small/personal/API projects for fastest responses. Have you tried benchmarking your one of biggest padrino apps?
    - DAddYEz 15y ago
      That's not 100% true, there are more than `hello world` benchs. Check it out here: https://github.com/DAddYE/web-frameworks-benchmark/tree/more_advanced https://github.com/DAddYE/web-frameworks-benchmark/tree/more... Yep, speed is 4-6x faster, but most important for me is memory usage is much much less. On every Rails project I need to use monit/god to stop/start when for xx cycles memory is > 100mb or so. Without that a rails project can sucks 1-2gb of ram. Isn't quite normal to my standards, in fact generally Padrino doesn't need more than 70mb. But here a lot of work must to be do.
      - nyrb 15y ago
instakill 15y ago
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.
- mattdeboard 15y ago
  Ah the old sunk cost fallacy.
  - davidw 15y ago
    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?
    - mattdeboard 15y ago
      >I'm not sure that's 100% accurate 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."
      - awj 15y ago
        > 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." No, you're using the wrong word here. It isn't a sunk cost when you've invested resources (i.e. can recover value from those resources in the future), it's when you've spent (i.e. cannot recover value from the resources) resources. The knowledge gained from learning Rails is obviously recoverable, and can be directly applied to future work. Throwing that away is not a sunk cost issue.
mickeyben 15y ago
Padrino is great for small apps but for medium to big projects I much prefer go the rails way and remove the parts I don't need. You can remove the big rails modules if you don't need them (activesupport, activemailer, activerecord,. ..) but also the rack middlewares.
silversmith 15y ago
I love the idea. No unnecessary crud, simple, clean. What's not to love? It's the practice that I'm having problems with. Medium-large projects have tendency to actually use big part of the bag of tricks Rails provides. But smaller ones, where Padrino should shine... it doesn't. When running one or two server processes, I don't care that it consumes 30MB more RAM than it should, or renders take two milliseconds longer than they could. If I did, I would use something else instead of ruby. However, when I actually try to use that one neat feature, only to remember that it's Rails-specific, or find out that this gem I'm not familiar with has documentation only as far as Rails-integration is concerned, that's a real and measurable dip in my productivity. These small projects are usually weekend hacks where I would rather not spend time writing boilerplate I know can be replaced by one line by that other framework, or digging through sources of a library before I can start using it. It gets very tempting to just throw in the whole Rails stack and focus on the interesting bits. These problems could be alleviated by more widespread use of other Ruby web frameworks (and I do wish they gain more traction!). But right now, my laziness keeps me from 'being part of the solution'.
janus 15y ago
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.
- instakill 15y ago
  This. I've already expressed similar sentiments, but another point to consider is the ever-changing Rails gem environment. Thoughtbot are now releasing new updates every 2 weeks and their gems like paperclip are invaluable. If you invest your time into a Padrino gem ecosystem in addition to keeping up with things like Devise/Paperclip et al, when will you have time to sleep?
- karterk 15y ago
  I can see where you are coming from, but ruling something out because another thing is doing it's job (in your opinion) is parochial. Unless you try new things out, you can never improve your existing workflow. You don't know what you don't know unless you explore.
  - janus 15y ago
    Even though I agree with you in trying new things out, I think that never settling with an established tool is pointless. We are trying to get things done here. My point is, I like trying new things, but I prefer to stick with tested and supported tools when working in a job, and leaving these new things to personal projects or hobbies. Rails has not only a huge community, but a huge support of third party libraries that while they may not be the best performance-wise, they allow you to accomplish the project's goals.
bstar77 15y ago
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 problem, but what's presented seems superficial. I would love to know how Padrino lives with mongodb. Will the admin generator work with mongomapper or mongoid?
- tptacek 15y ago
  The asset pipeline you can easy do without. I've forgotten Rails even did Scaffolds. But even though AR is "pluggable", you're working against the grain in Rails if you don't use it.
  - bstar77 15y ago
    So I should pity all the mongodb users out there?
  - jshen 15y ago
    I'm using mongo_mapper with 2 apps right now and it doesn't feel like I'm going against the grain.
  - yxhuvud 15y ago
    I mostly disagree - nowadays it isn't AR that is essential ime. AM on the other hand is utterly essential and I end up implementing parts of it on almost every nonAR-model to get the nice interaction with AS.
keeran 15y ago
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 recreating Rails' structure in my 'lightweight' app and think 'why don't I just use Rails?'.
- tptacek 15y ago
  This is exactly what happens to me, and is also the sense I've gotten the couple times I've had the opportunity to review other people's Padrino apps. 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.
- Xylakant 15y ago
  I do all my production app in sinatra/padrino. I like the fact that I can do pretty much every app from a simple api to a full webapp with the same stack without changing the framework. 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)
  - tptacek 15y ago
    Can you be more specific? I'm curious. What are the bits of ActionView that get in your way? I ask because to me, as far as views go, both Rails and Sinatra are just hosting systems for Haml. If anything, it's Sinatra that got in my way (it doesn't have explicit partial support, so there were minor things I had to tweak). I can't think of many "features" of ActionView I used. I generally agree that Sinatra was an easier sell in the Rails 1.x and 2.x era, before Rails ate Merb.
raganwald 15y ago
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.
lsdafjklsd 15y ago
Yehuda Katz made a good point in this episode of ruby rogues http://bit.ly/w7PJ0o http://bit.ly/w7PJ0o about how he uses rails even for small projects. I use rails for everything, there is so much going on for you behind in the scenes in the way of security and configuration that it doesn't make sense to go back and roll your own on a minimal framework.
automach 15y ago
As someone that has been writing production Rails and Sinatra apps for years, I have to recommend against using Padrino. Rails scales up and down pretty well, and I don't really see a need for Sinatra in anything but very small or single-purpose apps. You can even write a Sinatra clone in very little code on top of Rails: http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rails-3/ http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rai... If you already know Rails, there is very little reason to build a substantial app in anything "smaller". The reality is that for any moderately-sized app, you will end up using many of the parts of Rails that you think are unnecessary in the beginning. Especially as your app grows. I tried using Padrino for an app a year ago, and while the framework has probably matured since then, I moved back to Rails fairly quickly due do a lack of polish/documentation/community/benefit other than being different. There is a common tendency to find a part of a framework that doesn't work exactly the way you want, and in turn throw the entire framework out and seek out or write something new. I still prefer the way Merb and Sinatra handle responses, where the controller action return value is the response sent to the client. But the benefits that Rails provides so outweigh many of these kind of preferences that it's usually best to just embrace the way the framework works and move on to actually building an app that does something. It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails. The presentation makes it sounds as though by using Rails you have to use SASS and Coffeescript. This is not true, you can easily use plain JavaScript and CSS if you want. The majority of developers will be more productive in Rails.
- maxdemarzi 15y ago
  Sinatra has a great use case in Service Oriented Architecture and APIs. One Rails app supported by 4-5 Sinatra/Rack apps.
trustfundbaby 15y ago
I'm sure Padrino has a niche in the Ruby community that it will appeal to, but I wish it brought more to the table than just being smaller than Rails and more full featured than Sinatra. If, say, it was engineered to be completely asynchronous, like node, that would be killer. Its nice and I can see myself using it in very specific instances, but it doesn't feel like the Rails killer that the post title claims it is, but that's just me
jenius 15y ago
The only thing I see wrong with this is lack of coffeescript. I love coffeescript like bill clinton loved getting dome in the oval office, and if anything is without it, i will either cry, build support in myself, or both (at the same time?) Anyway the point of this comment is please give us coffee! It looks like padrino has everything else covered and I really like the idea.
- dmix 15y ago
  Coffeescript was mentioned in the slide, but why does the framework have to support CoffeeScript? Theres plenty of ruby libraries like Guard to autocompile CS files or you could just us the built in CLI.
rlander 15y ago
Padrino is the perfect framework for Djangonauts who want to learn a ruby web framework whilst also learning the language, which was my case 1 year ago. Especially those who don't like the "rails way". It has most everything we love about Django: admin site, mountable apps (which I consider actually better than Django's), speed (it is as fast as Django in my benchmarks) plus a sane and flexible routing sytem, generators, localization, full support for various subframeworks and a much, much better configuration system (no global settings file!). It is everything I wish Django was, but in Ruby.
dblock 15y ago
I believe the problem everybody trying to solve is that Rails is poorly suited to build RESTful APIs. If you love Rails and still want that, mount something like Grape (http://github.com/intridea/grape http://github.com/intridea/grape) inside your Rails app.
gerggerg 15y ago
Ok seriously, why the flamebait title? This deck is about padrino, yet it's no where in the title. We should be enticing discussion not argument in our titles. Also, now I'm not going to be able to find this post in a search. I'm going to have to search through all the negative posts about rails to find it instead of just searching for padrino. If HN had downvotes on submissions, this is one of the rare cases I would find it useful as 'flag' doesn't seem to really qualify.
wikimatze 15y ago
I love Padrino so much that I started to write a book about it and my experience in developing an app with it https://github.com/matthias-guenther/padrino-book https://github.com/matthias-guenther/padrino-book.

146 points by DAddYEz 15y ago

100x this. I hope Padrino picks up more steam and people it give it more love. It absolutely kicks ass and I would choose it over Rails everytime now. Now, if someone would write Padrino with Python, I'd be one really happy camper!

timinman 15y ago

I definitely love Sinatra, and I'm impressed by the admin interface, but it looks like there's no support for DataMapper as an ORM. I also wonder if this is just turning Sinatra into Rails. I think for the now I prefer to just build a Sinatra app and add gems and plugins as I need them.

vidarh 15y ago
The thing I like the most about it is the part where they demonstrate selectively including certain elements into Sinatra. I like Sinatra exactly because it doesn't come with the kitchen-sink - like you I prefer to just add gems and plugins as I need them (and I rarely find I do), but if I do I might look at Padrino. (As for the admin interface, their site claims it has DataMapper support)
glassx 15y ago
Same here. I really like Sinatra's gem ecosystem, and with unobtrusive Javascript I don't have much framework-dependent code on the views, nor helpers like his link_to confirm example, in the presentation... I admit that sometimes I miss generators, but Sinatra's boilerplate code is so minimal that I just don't care much anymore.
- timinman 15y ago
  Once before starting a biggish app I sat down and wrote my own generators to create controllers with crud actions and views for them.
base 15y ago
Padrino supports the following ORMs out of the box: mongoid, activerecord, datamapper, couchrest, mongomatic, ohm, ripple, sequel. Take a look here: http://www.padrinorb.com/guides/generators http://www.padrinorb.com/guides/generators Padrino is just a Sinatra app with a very basic skeleton and some added functionality. Almost all the pieces are modular and doesn't have many requirements from the start.
- Argorak 15y ago
  On small addition: Padrino is also a Layer that stitches multiple Padrino Apps together, which is the true shiny feature.
- timinman 15y ago
  Thanks for that. I mistakenly thought it only supported the two listed in the presentation.
sp4rki 15y ago
I remember using Datamapper with Sinatra to develop a pretty basic system for some weird user registration needs of a company offering medical assistance in the way of air ambulances in 2010. I don't really know if it's still supported since I've been doing .Net stuff since then... but I can definitely tell you it WAS supported two years ago, and I seriously doubt that they don't now.

johnx123-up 15y ago

Looks like a Xitrum (Scala web framework) to me.

beggi 15y ago

This reminds me of Flask for Python (nb. although more is built in to Padrino, most of the functionality for Flask is provided by plugins). I've recently started using Flask for new projects in favor of Django. I feel that most of the libraries I use are framework agnostic, stuff like ORM (SqlAlchemy), PDF generation, redis/mongodb adapters etc, so being able to pick what fits and leave the cruft out is great. But besides that, I feel that in recent times development is moving much more to the client - and client code like Javascript/CoffeeScript, Java for Android and Objective C, is getting much bigger at the expense of server side code. This is recently evidenced by the new 37signals Basecamp Next app which is 50/50 CoffeeScript/Ruby. So the server side programming is on track to becoming "just" a API endpoint for all these different technologies and I think micro frameworks like Flask and Padrino are very well suited for that.

tizoc 15y ago
I'm working on Fiasco, which intends to be similar to Flask but for Ruby. It is still a work in progress, but you can see it here: http://tizoc.github.com/fiasco http://tizoc.github.com/fiasco
jemeshsu 15y ago
Have you try Pyramid? It's similar to Flask.
viandante 15y ago
Could you go more in detail with your experience with Flask? I am new to web development and I am developing a landing page in Flask. I tried to use Django or Rails in the past but I just hated not being able to understand what I was doing. Flask is really, really, straightforward, I rolled out my own authorization plugin as a decorator and it feels good to be so close to the application. But I keep thinking if I should move to RoR in case my landing page succeeds and I will have to build the real application. Mostly, I am concerned about hosting and scaling...

nyrb 15y ago

Padrino is really nice web framework for Ruby. I have used it for experimental projects. My work was using latest Padrino framework at work, but extremely unhappy with the its performance (slow response). We had ported the app to Rails 3.1 for better performance. (We will upgrade it to 3.2 soon) In fact, I think Padrino is pretty ideal for personal and small apps. Not really ideal for medium to large apps. Just my opinion and experience.

DAddYEz 15y ago
Warn: is opinionated Btw I switched lots of projects from rails to padrino due to the slow performances of rails. I built a small test suite where you can find that Padrino is upto 4x faster than rails. Check it out: https://github.com/DAddYE/web-frameworks-benchmark https://github.com/DAddYE/web-frameworks-benchmark Feel free to show me that Im wrong.
- nyrb 15y ago
  I am not against the Padrino web framework. I still like it. :-) So your benchmark only have tested against the small "Hello World" app. Maybe that's why I suggested that Padrino framework is pretty ideal for small/personal/API projects for fastest responses. Have you tried benchmarking your one of biggest padrino apps?
  - DAddYEz 15y ago
    That's not 100% true, there are more than `hello world` benchs. Check it out here: https://github.com/DAddYE/web-frameworks-benchmark/tree/more_advanced https://github.com/DAddYE/web-frameworks-benchmark/tree/more... Yep, speed is 4-6x faster, but most important for me is memory usage is much much less. On every Rails project I need to use monit/god to stop/start when for xx cycles memory is > 100mb or so. Without that a rails project can sucks 1-2gb of ram. Isn't quite normal to my standards, in fact generally Padrino doesn't need more than 70mb. But here a lot of work must to be do.
    - nyrb 15y ago

instakill 15y ago

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.

mattdeboard 15y ago
Ah the old sunk cost fallacy.
- davidw 15y ago
  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?
  - mattdeboard 15y ago
    >I'm not sure that's 100% accurate 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."
    - awj 15y ago
      > 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." No, you're using the wrong word here. It isn't a sunk cost when you've invested resources (i.e. can recover value from those resources in the future), it's when you've spent (i.e. cannot recover value from the resources) resources. The knowledge gained from learning Rails is obviously recoverable, and can be directly applied to future work. Throwing that away is not a sunk cost issue.

mickeyben 15y ago

Padrino is great for small apps but for medium to big projects I much prefer go the rails way and remove the parts I don't need. You can remove the big rails modules if you don't need them (activesupport, activemailer, activerecord,. ..) but also the rack middlewares.

silversmith 15y ago

I love the idea. No unnecessary crud, simple, clean. What's not to love? It's the practice that I'm having problems with. Medium-large projects have tendency to actually use big part of the bag of tricks Rails provides. But smaller ones, where Padrino should shine... it doesn't. When running one or two server processes, I don't care that it consumes 30MB more RAM than it should, or renders take two milliseconds longer than they could. If I did, I would use something else instead of ruby. However, when I actually try to use that one neat feature, only to remember that it's Rails-specific, or find out that this gem I'm not familiar with has documentation only as far as Rails-integration is concerned, that's a real and measurable dip in my productivity. These small projects are usually weekend hacks where I would rather not spend time writing boilerplate I know can be replaced by one line by that other framework, or digging through sources of a library before I can start using it. It gets very tempting to just throw in the whole Rails stack and focus on the interesting bits. These problems could be alleviated by more widespread use of other Ruby web frameworks (and I do wish they gain more traction!). But right now, my laziness keeps me from 'being part of the solution'.

janus 15y ago

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.

instakill 15y ago
This. I've already expressed similar sentiments, but another point to consider is the ever-changing Rails gem environment. Thoughtbot are now releasing new updates every 2 weeks and their gems like paperclip are invaluable. If you invest your time into a Padrino gem ecosystem in addition to keeping up with things like Devise/Paperclip et al, when will you have time to sleep?
karterk 15y ago
I can see where you are coming from, but ruling something out because another thing is doing it's job (in your opinion) is parochial. Unless you try new things out, you can never improve your existing workflow. You don't know what you don't know unless you explore.
- janus 15y ago
  Even though I agree with you in trying new things out, I think that never settling with an established tool is pointless. We are trying to get things done here. My point is, I like trying new things, but I prefer to stick with tested and supported tools when working in a job, and leaving these new things to personal projects or hobbies. Rails has not only a huge community, but a huge support of third party libraries that while they may not be the best performance-wise, they allow you to accomplish the project's goals.

bstar77 15y ago

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 problem, but what's presented seems superficial. I would love to know how Padrino lives with mongodb. Will the admin generator work with mongomapper or mongoid?

tptacek 15y ago
The asset pipeline you can easy do without. I've forgotten Rails even did Scaffolds. But even though AR is "pluggable", you're working against the grain in Rails if you don't use it.
- bstar77 15y ago
  So I should pity all the mongodb users out there?
- jshen 15y ago
  I'm using mongo_mapper with 2 apps right now and it doesn't feel like I'm going against the grain.
- yxhuvud 15y ago
  I mostly disagree - nowadays it isn't AR that is essential ime. AM on the other hand is utterly essential and I end up implementing parts of it on almost every nonAR-model to get the nice interaction with AS.

keeran 15y ago

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 recreating Rails' structure in my 'lightweight' app and think 'why don't I just use Rails?'.

tptacek 15y ago
This is exactly what happens to me, and is also the sense I've gotten the couple times I've had the opportunity to review other people's Padrino apps. 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.
Xylakant 15y ago
I do all my production app in sinatra/padrino. I like the fact that I can do pretty much every app from a simple api to a full webapp with the same stack without changing the framework. 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)
- tptacek 15y ago
  Can you be more specific? I'm curious. What are the bits of ActionView that get in your way? I ask because to me, as far as views go, both Rails and Sinatra are just hosting systems for Haml. If anything, it's Sinatra that got in my way (it doesn't have explicit partial support, so there were minor things I had to tweak). I can't think of many "features" of ActionView I used. I generally agree that Sinatra was an easier sell in the Rails 1.x and 2.x era, before Rails ate Merb.

raganwald 15y ago

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.

lsdafjklsd 15y ago

Yehuda Katz made a good point in this episode of ruby rogues http://bit.ly/w7PJ0o http://bit.ly/w7PJ0o about how he uses rails even for small projects. I use rails for everything, there is so much going on for you behind in the scenes in the way of security and configuration that it doesn't make sense to go back and roll your own on a minimal framework.

automach 15y ago

As someone that has been writing production Rails and Sinatra apps for years, I have to recommend against using Padrino. Rails scales up and down pretty well, and I don't really see a need for Sinatra in anything but very small or single-purpose apps. You can even write a Sinatra clone in very little code on top of Rails: http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rails-3/ http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rai... If you already know Rails, there is very little reason to build a substantial app in anything "smaller". The reality is that for any moderately-sized app, you will end up using many of the parts of Rails that you think are unnecessary in the beginning. Especially as your app grows. I tried using Padrino for an app a year ago, and while the framework has probably matured since then, I moved back to Rails fairly quickly due do a lack of polish/documentation/community/benefit other than being different. There is a common tendency to find a part of a framework that doesn't work exactly the way you want, and in turn throw the entire framework out and seek out or write something new. I still prefer the way Merb and Sinatra handle responses, where the controller action return value is the response sent to the client. But the benefits that Rails provides so outweigh many of these kind of preferences that it's usually best to just embrace the way the framework works and move on to actually building an app that does something. It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails. The presentation makes it sounds as though by using Rails you have to use SASS and Coffeescript. This is not true, you can easily use plain JavaScript and CSS if you want. The majority of developers will be more productive in Rails.

maxdemarzi 15y ago
Sinatra has a great use case in Service Oriented Architecture and APIs. One Rails app supported by 4-5 Sinatra/Rack apps.

trustfundbaby 15y ago

I'm sure Padrino has a niche in the Ruby community that it will appeal to, but I wish it brought more to the table than just being smaller than Rails and more full featured than Sinatra. If, say, it was engineered to be completely asynchronous, like node, that would be killer. Its nice and I can see myself using it in very specific instances, but it doesn't feel like the Rails killer that the post title claims it is, but that's just me

jenius 15y ago

The only thing I see wrong with this is lack of coffeescript. I love coffeescript like bill clinton loved getting dome in the oval office, and if anything is without it, i will either cry, build support in myself, or both (at the same time?) Anyway the point of this comment is please give us coffee! It looks like padrino has everything else covered and I really like the idea.

dmix 15y ago
Coffeescript was mentioned in the slide, but why does the framework have to support CoffeeScript? Theres plenty of ruby libraries like Guard to autocompile CS files or you could just us the built in CLI.

rlander 15y ago

Padrino is the perfect framework for Djangonauts who want to learn a ruby web framework whilst also learning the language, which was my case 1 year ago. Especially those who don't like the "rails way". It has most everything we love about Django: admin site, mountable apps (which I consider actually better than Django's), speed (it is as fast as Django in my benchmarks) plus a sane and flexible routing sytem, generators, localization, full support for various subframeworks and a much, much better configuration system (no global settings file!). It is everything I wish Django was, but in Ruby.

dblock 15y ago

I believe the problem everybody trying to solve is that Rails is poorly suited to build RESTful APIs. If you love Rails and still want that, mount something like Grape (http://github.com/intridea/grape http://github.com/intridea/grape) inside your Rails app.

gerggerg 15y ago

Ok seriously, why the flamebait title? This deck is about padrino, yet it's no where in the title. We should be enticing discussion not argument in our titles. Also, now I'm not going to be able to find this post in a search. I'm going to have to search through all the negative posts about rails to find it instead of just searching for padrino. If HN had downvotes on submissions, this is one of the rare cases I would find it useful as 'flag' doesn't seem to really qualify.

wikimatze 15y ago

I love Padrino so much that I started to write a book about it and my experience in developing an app with it https://github.com/matthias-guenther/padrino-book https://github.com/matthias-guenther/padrino-book.