

Ruby Frameworks? Which one? Bye bye Rails. - DAddYEz
http://www.slideshare.net/zhesto/padrino-the-godfather-of-sinatra

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

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

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

~~~
jshen
"The after_commit and after_rollback callbacks are guaranteed to be called for
all models created, updated, or destroyed within a transaction block. If any
exceptions are raised within one of these callbacks, they will be ignored so
that they don’t interfere with the other callbacks. As such, if your callback
code could raise an exception, you’ll need to rescue it and handle it
appropriately within the callback."

[http://guides.rubyonrails.org/active_record_validations_call...](http://guides.rubyonrails.org/active_record_validations_callbacks.html)

~~~
rohitarondekar
"The whole callback chain is wrapped in a transaction. If any before callback
method returns exactly false or raises an exception, the execution chain gets
halted and a ROLLBACK is issued; after callbacks can only accomplish that by
raising an exception."

―
[http://guides.rubyonrails.org/active_record_validations_call...](http://guides.rubyonrails.org/active_record_validations_callbacks.html#halting-
execution)

~~~
jshen
I'm not sure what your point is. He was talking about after_commit callbacks.
Your quote is about the callbacks during a transaction, not after it.

------
automach
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-
rai...](http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rails-3/)

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
Sinatra has a great use case in Service Oriented Architecture and APIs. One
Rails app supported by 4-5 Sinatra/Rack apps.

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

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

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

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

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

------
keeran
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?'.

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

~~~
Xylakant
Sorry, I didn't want to imply that ActionView gets in my way - I just don't
miss it. Padrino uses the excellent Tilt templating library and it loads
pretty much all template engines I could wish for and it does add explicit
partial support to sinatra. That's about all I could want from ActionView. I
don't like or use form-builders for instance, I prefer not to use the js/ajax-
helpers etc.

I guess it boils down to a matter of preference: I prefer my stack to be built
from the ground up on a solid foundation by adding pieces I want and need in
my app - and that's what I can do with padrino. If I'm writing a pure API it's
sinatra plus the padrino router, tilt, maybe an orm and that's about it. If I
need something more comprehensive I can add components on top of that that add
the required functionality (render-helpers such as partials etc.)

~~~
tptacek
Yeah, I haven't used the form helpers in ages, I just write normal jQ
Javascript code and pretend Rails doesn't have "ajax" support, and I hardcode
my links instead of using link_to. You're right, there's a bunch of stuff
ActionView does that I've had to opt out of using.

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

Feel free to show me that Im wrong.

~~~
nyrb
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
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...](https://github.com/DAddYE/web-frameworks-
benchmark/tree/more_advanced)

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
Sorry if I have to ask, what part is not 100% true? You mean that padrino app
can be still faster with large app?

You said there are more than "Hello World" benchmarks? I looked at the link
that you provided and then looked at this source code of the Padrino app and
its still "Hello World":

[https://github.com/DAddYE/web-frameworks-
benchmark/blob/more...](https://github.com/DAddYE/web-frameworks-
benchmark/blob/more_advanced/padrino/app/controllers/main.rb)

I expected to see something more than just Hello World app.

I am trying to see why you are suggesting me that Padrino is better than
Rails. :-) Sounds like you are completely against Rails. Maybe I am wrong.

~~~
DAddYEz
It's quite complicated make a full featured app for all webframeworks, btw
look at here: [https://github.com/DAddYE/web-frameworks-
benchmark/blob/more...](https://github.com/DAddYE/web-frameworks-
benchmark/blob/more_advanced/padrino/app/controllers/main.rb#L7)

Which is: [https://github.com/DAddYE/web-frameworks-
benchmark/blob/more...](https://github.com/DAddYE/web-frameworks-
benchmark/blob/more_advanced/padrino/app/views/index.haml)

With a layout: [https://github.com/DAddYE/web-frameworks-
benchmark/blob/more...](https://github.com/DAddYE/web-frameworks-
benchmark/blob/more_advanced/padrino/app/views/layouts/application.haml)

Not a very very complex use case but a bit more than a `hello world` app.

I love Rails, Im using i.e. ActiveRecord in 90% of my projects. Beside that I
ported 162 apps over Padrino not because I've free time to spend but because I
need decent performances (without kongfu with mem/redis caching) with less
memory usage.

Try to browse rails (minus ActiveRecord) source code and padrino source code
to understand what I mean.

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

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

------
lsdafjklsd
Yehuda Katz made a good point in this episode of ruby rogues
<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.

------
instakill
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
Ah the old sunk cost fallacy.

~~~
davidw
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
> _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
> 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.

~~~
mattdeboard
I stand corrected then. In my defense, however, I was talking about the time
invested being a sunk cost, as the time is not recoverable -- and that's what
the person I was responding to mentioned. The time.

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

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

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

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

~~~
base
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>

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
On small addition: Padrino is also a Layer that stitches multiple Padrino Apps
together, which is the true shiny feature.

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

------
dblock
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>) inside your Rails app.

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

------
fingerprinter
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!

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

