Can you share your thoughts on Why ROR for the web application development?
The scaffolding is not effective enough. I think we cannot give high weightage for this. There are other advantages like active record model, in built testing framework and migration framework. But, I don't find clear answers on Why ROR? Please provide the straight forward answers.
Ayyanar from Aspire Systems wrote:
Can you share your thoughts on Why ROR for the web application development?
The scaffolding is not effective enough. I think we cannot give high weightage for this. There are other advantages like active record model, in built testing framework and migration framework. But, I don't find clear answers on Why ROR? Please provide the straight forward answers.
As I stated in another forum, someone programing in RoR can complete the same application as three or four other people using another framework but in half the time. Even providing security measure for my apps has been a breeze. Also the fact that interaction with the DB is so simple makes my job a lot easier.
Second to Shandy.
RoR is fun to work in and produces great results in a matter of hours.
If one is building a database-driven web application, it's hard to
beat. Wake up, lay out an app, build it, test it, have lunch. 
As for scaffolding, I haven't used it since doing Cookbook.
Straight forward answer to Why is that "it depends" -- it depends on where you're coming from and what problems you're tring to solve. Why I chose may be very different than why somone else chose, and different from why you might choose it.
For people trained on Java, building "small-ish" sites/apps is inefficient compared to Rails. So many Rails people gush about how productive it is. Compared to similar frameworks in reflective, dynamic languages, I would expect Rails tobe about the same (I find it about the same as my own web framework). So the whole "4x and 10x faster" business is very relative to your previous experience. It is quick to develop with when you stick to the core things it was designed for. When you have to deviate from that path, well, then it's about the same as anything else you have to do from scratch.
Rails is batteries included, but some assembly stil required. Rails does have some nice things "in-the-box" such as testing, migrations, integration with rake, your basic MVC system all ready to go, and ActiveRecord. However, there is no built-in tools for user authenication, multi-language interfaces, and if you're building lots of similar apps, Rails isn't very modular (relatively awkward at sharing share code between projects). However, there's quite a few plugins to fill in some of the blanks.
Rails is well-liked by a lot of today's programming pop-icons from the XP/Agile/Pragmatic crowd. This is because Ruby is a lot like their first love SmallTalk, because Rails sought to embody a lot of the XP/pragmatic philosophies right from the start, and because the Ruby and Rails communities are pretty good about teaching good habits (according to the XP/Pragmatic philosophies). So, if XP/agile and the Pragmatic approach to things resonates with you, the you'll find Rails to be very fluid and at one with The Force.
Ruby. Pretty cool language. Though hampered by arcane, old-school command names it's relatively free of syntactic junk which makes for fairly clear reading. I don't get too whipped up about the DSL frenzy that's going on, but good object and variable naming along with Ruby's syntax does seem to make the code brief and readable compared to other languages. I recently had some code done in 6 languages to makes available as SDKs, and Ruby is generally very easy on the eyes.
However, Rails is relatively new, so some spit & polish are still needed in some areas (production deployment is still awkward compared to other systems), but the good news is that there's a lot of energy being put into making Ruby and Rails an equal player on the big stage.
Why should you choose Rails? Well, mostly because it a) does what you need it to do, b) you appreciate the style and philosophies it promotes, c) it is supported by a community of like-minded developers, and d) you can find worthy people to work on projects with/for you using it. If these things are all yes, then they're good reasons for choosing Rails.
Anything that is web-pagey. Seriously, IMO Rails, and just about any other thoughtfully designed framework that's been around a while regardless of style, is suitable for just about every type of web site you've ever seen. It's not a matter of being suitable, but rather being productive. I've been involved with very data oriented sites, brochure sites, and sites in between. I just don't see a difference relativeto suitability--it's all pages and data retrieval.
IOW, purpose shouldn't be part of the definition, but rather scope of demand on the network and computation are probably good considerations for determining if Rails is suitable.
I wouldn't use Rails as the primary platform to calculate actuary tables, but I'd use it to show the results.
I wouldn't use Rails (or any web framework) as the primary UI for accounting, but I'd use it to search for specfic details from the accounting records.
I doubt I'd use Rails to create something like eBay (auctions require some tight threading control I'm not sure Rails would be up to, but I could be wrong), but I'd probably use Rails to do something like Expedia (someday that refc will make sense
Maybe one framework has some tools optimized for certain data collections or UI experiences over another (Rails was an early player in boxing Ajax functionality), and you could argue that framework is "better for X type of sites" because it has some specific tools that are productive for that, but really, I think you'll find 3rd-party solutions (plugins, modules, etc) will balance out what's available in total amongst the frameworks that have been around a while. Though some will definitely be more elegant than others. Is one inelegant wart tolerable in the light of the other benefits? Only you can decide which warts are intolerable. (I avoided Ruby due to some things that really annoyed me, but eventually I just forced myself to get over it in order to take advantage of what was good about it).
Again, I think it comes down to style, philosophies, upward vs downward trend in support/growth, and being within the middle 80% of the bellcurve of mainstream web-type functionality.
People say that we can reduce the 30% to 40% of the development cost if you do the same application in other languages. Is it the fact?
As CTO at a previous startup, I had the chance for a direct comparison of Ruby and Java. For several reasons, we built a web product in Java first and released it. Eventually, our reasons for staying Java went away, and I tried an experiment. My team volunteered to rewrite everything in Ruby while maintaining the Java site. There were no changes to the model, and the feature set was the same. In fact, the Ruby version ended up with a few additional features, but my rule was a direct port to start with. Some things we found:
- The Ruby code base was about 2/5 the size of the Java code base. - We built it 5x faster. This one isn't fair though because I had a hard rule that no feature changes could be made. The goal was that the end-user had no idea anything changed. - The dev team was a whole lot happier not dealing with all the extra "stuff" you have to deal with in a Java, Hibernate, and Spring app. - What a surprise. Ruby executes a whole lot slower than Java.
Since we used Scrum to track projects, it was pretty easy to compare our velocities. After a couple of sprints, the dev team's velocity improved by close to 40%. I expected some gains, but close to 40% was beyond expectations.
If you have a well-architected web application, I see no reason not to use Ruby. You may need a few more CPUs to scale well, but that cost is nothing compared to the development savings. The key is "well- architected." You can develop junk in any language or framework.
-Dave
Hi Dave,
Thanks for your input. Just one big question. I believe, you used the same database used by java in Ruby application, right? Did you face any difficulties in using the existing database like primary key issue?
I've had no issuse with legacy database schemas. I used conventions quite different than Rails, but have managed to do things just fine using that same db. Rails has ability to declare your differences.
-- gw
We had no problems at all using our existing MySQL database. The conventions used in the Java app were very close to what Ruby expects. Even it is wasn't, Rails makes it pretty easy to identify the primary and foreign keys if necessary. Convention over configuration doesn't mean you can't configure if you need to. That's one of the beauties of RoR -- keep it simple unless you can't.
Thanks for all your comments