From: Marek Janukowicz Date: 2004-07-26T05:11:54+09:00 Subject: Re: rubyonrails and cgikit comparison On Sun, 25 Jul 2004 19:53:55 +0900, Florian Weber wrote: >> There seems to be a lot of excitement about rubyonrails even before >> the announcement of version 0.5. >> >> What makes rubyonrails 0.5 more attractive than cgikit 1.2.1? I'm >> under the impression cgikit offers MVC and has an architecture similar >> to WebObjects (which is well-regarded) but I've no experience with >> these tools. It's a bit weird for me to advocate CGIKit, as I am developing a competing framework (SWS/SDS), but I'll try to avoid bias :) > i think following things make rails much more attractive: > > - rails is much more than just a mvc framework: +activerecord. So is cgikit (together with tapkit). > - cgikit seems to have way more overhead that rails. i mean, just > compare a simple hello world. i admit its kinda silly to compare > frameworks via the most simple hello world, that doesnt show > their real power. I agree with you - there is no point in comparing framework via the most simple application (how simple it would be to write "hello world" as a regular CGI script :). > but i've used frameworks which are similiar to cgikit before.. and > believe me, it can turn into a pure nightmare when you have to create > components for the smallest little things. I also used frameworks that are similar to cgikit (mostly Java ones - WebObjects, Tapestry) before and I find them very powerful for REAL LIFE applications ("hello world" is NOT one). I disagree it is difficult to create components for small things, if you have good dev tools. And without decent dev tools even a very powerful framework will inevitably turn into nightmare, when the application grows complicated enough. > i really believe into using ruby as a view language. the whole > 'every view can be described in xml'-thing is totally utopian and > will never be happening. sooner or later you run into situations > where things become terrible akward. what for example if you > wanna change the style attribute of a xhtml tag based on some > condition? And I don't like messing programming language with HTML, like rails do. IMHO the perfect MVC framework should have pure HTML templates, so the HTML & graphic guys could edit them not even knowing the framework or underlying programming language. I admit cgikit is not very good at it (as it introduces tag, mimicking WebObjects' tag), but eg. Tapestry is much better at this point (and SWS too, but Tapestry is better - yet:). As for your example - I hope you realize the example is awkward itself :) No matter which framework you choose, the solution will always be complicated and ugly. And yes, you can do this in cgikit :) > - rails is pragmatic. it makes simple things simple, and hard > things possible (yes! i bet you never heard this sentence > before ; ) but with rails its totally true. if you believe in components > in the view, its possible to add that.. I don't care if it makes simple things simple. In the company I work for, we use WebObjects for complicated applications and simple Ruby FastCGI scripts for simple ones. For simple things you don't need a MVC framework, you can print the HTML code directly. > basically you really start to appreciate that you dont have to > write tons of config files for everything. cgikit could also do that. > it would be so much nicer if there would be some name specifications > for your component class. like naming methods which return attributes > in a special way. then you could get rid of the whole binding file. (i > might be wrong, since i just quickly browsed the docs =) Yes, and then you would encounter the situation, when you REALLY can't follow this convention (the same goes for O/R mapping frameworks and mapping SQL columns to attributes of the same name - think about "ID" and what "id" attribute is used for in Ruby :) and you are stuck. I really like the freedom of cgikit-like frameworks. Disclaimer: I really didn't intend to bash rails, so if anyone gets an impression I DID bash it, I apologize. IMHO rails got a bit overhyped (sorry, but I don't care it is a 1KLOC framework - I could decrease the size of any of my libraries, but at cost of code quality. I rather chose to avoid eval and other evil constructs instead) and I just wanted to point out there are other solutions at least as powerful and elegant as rails. -- Marek Janukowicz