
Why Rails is total overkill and why I love Rack - nickb
http://www.hokstad.com/rails-is-total-overkill-and-why-i-love-rack.html
======
benreesman
My biggest complaint about Rails is that it doesn't seem to solve any of the
hard problems encountered by serious web developers. Routing is easy,
selecting and applying templates is easy, organizing related action handlers
into the same file or logical grouping is easy. There's nothing impressive
about this, and DHH's arrogance only further frustrates me with Rails'
shortcomings.

Flow control on the other hand is hard. Complex web applications are hard
because HTTP is basically stateless. If I'm filling out a form and I want to
do some multi-step modal flow for selecting an image from a number of
galleries and return to the form I was working on then I need continuations or
at least closures. Rails doesn't give me anything here, and the Rails answer
(AJAX for anything more complicated than 'fetch a row and stuff it in a
template based on a sequential integer ID') is still quite unsatisfying. AJAX
is wonderful but your application should work whether or not it is available.

Seaside and to a lesser extent Arc and Rhino-In-Spring offer you a lot more,
but Seaside and Arc don't seem to have much of a story when it comes to
clustering, and Rhino-In-Spring (while beautifully executed) suffers from the
same 'over-arching warm embrace' framework syndrome described in the article.

If someone wrote a web framework as a set of high-cohesion, low-coupling
components that gave me high level flow control abstractions but got out of
the way when all I wanted to do was stuff a row into a template, and
furthermore could credibly scale out to a large horizontal cluster they would
probably take over the world.

I've started prototyping such a tool, also using Rhino. It adds package
management and a few other things to JavaScript 1.7 to make it suitable as a
general-purpose programming language (i.e. it makes sense to use it for
command line scripts as well as web applications). It also offers, a la carte,
a mod_perl like facility that simply invokes your module with the request and
response objects and gets out of your way. On top of this there's another
layer that takes care of routing, template application, and flow control. This
last component is still in the early stages but is coming along nicely. It can
serialize continuations and closures out of process and consume them another
machine, using techniques borrowed from Rhino-In-Spring, so it can be
clustered.

If this is interesting to anyone please let me know, I would love some
feedback and help with it. I plan on open-sourcing it once it reaches a level
of stability that makes it suitable for production use.

