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.<p>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.<p>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.<p>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.
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.<p>You can even write a Sinatra clone in very little code on top of Rails: <a href="http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rails-3/" rel="nofollow">http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rai...</a><p>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.<p>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.<p>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.<p>It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails.<p>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.<p>The majority of developers will be more productive in Rails.
I love the idea. No unnecessary crud, simple, clean. What's not to love?<p>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.<p>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.<p>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.<p>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'.
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.<p>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.<p>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.
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.<p>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.
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".<p>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!).<p>It is everything I wish Django was, but in Ruby.
Would like to hear from people who have taken a user-facing Padrino/Sinatra app all the way through production and into maintenance.<p>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.<p>At some point I notice myself essentially recreating Rails' structure in my 'lightweight' app and think 'why don't I just use Rails?'.
Padrino is really nice web framework for Ruby. I have used it for experimental projects.<p>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)<p>In fact, I think Padrino is pretty ideal for personal and small apps. Not really ideal for medium to large apps.<p>Just my opinion and experience.
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.<p>As long as the fly is dead, Rails did its job.
Yehuda Katz made a good point in this episode of ruby rogues <a href="http://bit.ly/w7PJ0o" rel="nofollow">http://bit.ly/w7PJ0o</a> about how he uses rails even for small projects.<p>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.
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.
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.<p>You can remove the big rails modules if you don't need them (activesupport, activemailer, activerecord,. ..) but also the rack middlewares.
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.<p>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.<p>I would love to know how Padrino lives with mongodb. Will the admin generator work with mongomapper or mongoid?
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.<p>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.
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.<p>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
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?)<p>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.
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 (<a href="http://github.com/intridea/grape" rel="nofollow">http://github.com/intridea/grape</a>) inside your Rails app.
I love Padrino so much that I started to write a book about it and my experience in developing an app with it <a href="https://github.com/matthias-guenther/padrino-book" rel="nofollow">https://github.com/matthias-guenther/padrino-book</a>.
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.<p>Now, if someone would write Padrino with Python, I'd be one really happy camper!