Don't forget the D) option, use sinatra, ramaze or merb. ;)
bryanl
· 8 months ago
Of course this applies to other frameworks as well. Smart-Aleck... ;)
alexch
· 7 months ago
Sinatra is not a framework. It's just a library. Who needs frameworks?
See http://github.com/alexch/vegas for my lame lightning talk attempt at proving you can have an app with all the power of Rails without any Rails in it.
bryanl
· 7 months ago
I would be to differ. Sinatra is a web framework. Calling it "just a library" is playing semantics.
alexch
· 7 months ago
I don't think I'm playing semantics. Call it what you like, but Sinatra's scope is vastly smaller than Rails'. Sinatra just does routing. Rails does routing plus views plus ORM plus a whole lot else. Personally, I find that extra stuff oppressive rather than liberating, for several reasons:
(a) personal aesthetics about design (e.g. why aren't views objects?)
(b) too much invisible magic (i like convention, but what's so bad about configuration as long as it's concise?)
(c) Rails' absence of clean or consistent APIs (see my reply to graysky, and also all the many different and undocumented semantics for view helper methods)
An analogy -- admittedly imperfect -- is Sinatra is to Rails as Servlets are to J2EE.
With Rack and Sinatra and enough good gems, and just a little bit of glue code, anyone can write their own little framework. So... what's the point of Rails again?
Sean
· 8 months ago
I think we both have some experience with ISTR given our time together at RHG so without going into too much detail, you hit the nail on the head with this one. It was a valuable lesson though in that I will never again venture so far off the 'rails' as we did all too often there.
graysky
· 8 months ago
I agree in principle, but without a Rails API in practice this can be difficult.
For example, we use the "multi_db" plugin (like masochism) to transparently load balance between a master and slave(s). AFAIK, there is no way to have a plugin to do this without reaching into the guts of Rails and change the behavior of the db connection. This is fragile, and doesn't always make upgrading easy but what's a better alternative?
Even as a plugin author it can be tricky to know what is fair game to reference. Obviously, methods that are private or protected are likely to change, but about public methods? Are those all API?
You're certainly right that there are very unnecessary ventures into "C" territory, but even when trying to stay on the golden path, it isn't always very well marked.
alexch
· 7 months ago
Absolutely. By far the majority of our time spent coding Erector was figuring out how to plug a new View type into the godawful mess of spaghetti that is ActionController. And then doing it again and again whenever there was a new release of Rails.
All Comments
See http://github.com/alexch/vegas for my lame lightning talk attempt at proving you can have an app with all the power of Rails without any Rails in it.
(a) personal aesthetics about design (e.g. why aren't views objects?)
(b) too much invisible magic (i like convention, but what's so bad about configuration as long as it's concise?)
(c) Rails' absence of clean or consistent APIs (see my reply to graysky, and also all the many different and undocumented semantics for view helper methods)
An analogy -- admittedly imperfect -- is Sinatra is to Rails as Servlets are to J2EE.
With Rack and Sinatra and enough good gems, and just a little bit of glue code, anyone can write their own little framework. So... what's the point of Rails again?
For example, we use the "multi_db" plugin (like masochism) to transparently load balance between a master and slave(s). AFAIK, there is no way to have a plugin to do this without reaching into the guts of Rails and change the behavior of the db connection. This is fragile, and doesn't always make upgrading easy but what's a better alternative?
Even as a plugin author it can be tricky to know what is fair game to reference. Obviously, methods that are private or protected are likely to change, but about public methods? Are those all API?
You're certainly right that there are very unnecessary ventures into "C" territory, but even when trying to stay on the golden path, it isn't always very well marked.