Say hello to Padrino
updated over 7 years ago; latest suggestion over 7 years ago
(Someone proposed that they'd like to see a talk on Padrino, this is my take on that)
Rails showed us the power of the full-stack framework. It was good, but some of us felt the power was at the expense of lightness (and joy?).
Sinatra showed us the joy of simple. The bare essentials to start working with http requests gave us back some of the Zen of creating a codebase that did exactly what it should and nothing more. Sadly, this Zen meant reinventing wheels that Rails had already rolled in production for some time. For example, if you're writing an Auth system from scratch you are doing it wrong...
Padrino came after both of these projects and the developers learnt from them. They re-imagined the full stack using Sinatra as a base and building from there. Sinatra++ you might think, but it takes in some good ideas of it's own;
- Agnostic - Work with ActiveRecord or DataMapper or MongoMapper, ERb or HAML, shoulda or RSpec etc.
- Performance - rps performance comparable with node.js
- Generators (Admin interfaces a la Django)
- Interoperability with many Rails gems - WillPaginate, Kaminari, Carrierwave and many others
- Mounting multiple apps (like Rails Engines but maybe better)
- Built in auth system
- Concurrency out of the box with EM-Synchrony
- JRuby ready
In the talk, I'll demo all the above and I'll bring benchmarks where I'm making claims about performance. I'll show what creating an app from scratch looks like, how we deal with mounting multiple apps that share models and code. I'll try and show how you can lean towards Sinatra or Rails depending on your preference.
If you build apps that need a better balance between fast to develop and cheap to maintain Padrino could be the Goldilocks framework - not too heavy, not too light but just right.
I've heard good things about Padrino before, but never got round to trying it, so I'd like to hear more about why I maybe should.
In particular, I'm interested in whether Padrino helps avoid some of the design problems that are easy to sleepwalk into with Rails projects (poor separation of concerns, bloated models, tight view–controller–model coupling, poor test isolation etc).
I'd like to hear about this. In particular I'd like to hear an argument about why the problems Padrino is trying to solve require a whole new framework. (After hearing what problems Padrino is trying to solve, obviously.)
Noted - I'll bring along a couple of sample apps for people to discuss. Unfortunately it's still a young framework so I don't have many examples of older/well established apps but I'll do my best to give a representative sample.
Would love to see this talk, as relatively new to Ruby and Rails has been the only web framework I've used so far...
when all you have is a hammer...
I'd love to come away from this knowing which situations Padrino really shines in and any gotchas that new developers should be aware of