3 ms·

Why Rails is total overkill and why I love Rack

3 points by nickb 19y ago

benreesman 19y ago
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.

3 points by nickb 19y ago

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.