Is Ruby on Rails for you?
From WhyNotWiki
See also:
Contents |
[edit] The author of Rails on how the framework got its start
Ruby on Rails: An Interview with David Heinemeier Hansson, 2005-08-30:
- I got into Rails in the summer of 2003. 37signals was about to embark on the development of Basecamp—which would ultimately turn the company from a consulting firm to product development. We had been using PHP for years, and I had tried as hard as I could to arrive at a reusable framework that would make my life easier. And I actually had a very early and at least somewhat decent reminiscence of Rails running in PHP at the time, but I wasn't happy.
- And it was one of those "love it or leave it" moments. I realize that if this was going to be my working life, developing web applications, I had to be using tools that I loved, not tools that I merely tolerated. So I was open for alternatives.
- Then my influences conspired. I am a big fan of both the Pragmatic Programmers and Martin Fowler, and I was seeing Ruby popping up time and time again from both of these sides. And a friend of mine had given it a cursory overview and challenged my reasons for staying with PHP.
- So for a short while, I went into apologetic mode and built up all the stable arguments for why to reject change. We wouldn't be able to find programmers knowing Ruby for 37signals, PHP probably had more and better libraries, and on it went. But that thankfully didn't last too long because I decided to actually give Ruby a try.
- It took one day to say, "I really like this." It took one week to say, "I'm never going back to PHP again." And it took one month before my proficiency with Ruby made me run circles around my former programming capabilities in PHP. It was just such an incredibly powerful fit. Ruby fit my brain perfectly. I was having so much more fun and getting so much more done.
- I realize that this makes PHP sound bad, but it's really not about that. I'm grateful for PHP. It got me started with programming because of its incredible immediacy. It served me very well for a long time. I just arrived at a place that was outside what I would consider the sweet spot for that language. And Ruby proved to be exactly what I needed to get into the sweet spot again.
[edit] In favor of Ruby on Rails
Testing in integrated frameworks, Part 1
Migrating to Ruby on Rails and PostgreSQL: An Interview with CD Baby, 2005-11-02
Ruby on Rails: An Interview with David Heinemeier Hansson, 2005-08-30
[edit] Development companies/people that use it
http://www.thoughtworks.com/ruby.html
[edit] Keeps the application logic in one place
Tomas Jogin on September 27 (http://www.loudthinking.com/arc/000516.html):
- I, for one, am glad that, using Rails, I get to deal with the application and business logic only in my code, not in the DB. Databases are good at storing relational data, and Ruby is good for describing and working with application and business logic. Your mileage may vary, and Rails might not be for everyone, but the way it is now, it definitely is for me.
[edit] Opposition to Ruby on Rails
ActiveRecord - Achilles Heel of Ruby on Rails?
[edit] Complaint/question: How do you ensure data integrity?
[edit] Is anything important lost with Rails' attempt at database independence?
Christopher Petrilli voices his concerns in this article: Least Common Denominator, 2005-09-27
[edit]
Daniel F. Savarese (2007-03). Rails: A Development Gem: Ruby on Rails speeds development with Oracle Database. (http://www.oracle.com/technology/oramag/oracle/07-mar/o27rails.html).
Ruby on Rails (Rails, for short)—one of the more popular alternatives that has emerged in recent years—offers the most commonly used functionality of Java Web application frameworks, but with less complexity. Rails shines where rapid development takes a higher priority than distributed transaction management, application monitoring, and all the bells and whistles Java EE provides for mission-critical application development.
[edit] Comparison to [PHP (category)]
7 reasons I switched back to PHP after 2 years on Rails (http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html).
1 - “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap. I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be [darned]. But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much. Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed. Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so.
2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members’ Login Area, and dozens of cron shell scripts were ALL going to have to change. 85 employees re-trained. All customers and clients calling up furious that One Big Day, with questions about the new system. Instead, I was able to slowly gut the ugly PHP and replace it with beautiful PHP. Launch in stages. No big re-training.
3 - DON’T WANT WHAT I DON’T NEED
I admire [...] the Rails core gang that actually understand every line inside Rails itself. But I don’t. And I’m sure I will never use 90% of it. With my little self-made system, every line is only what’s absolutely necessary. That makes me extremely happy and comfortable.
4 - IT’S SMALL AND FAST
One little 2U LAMP server is serving up a ton of cdbaby.com traffic [really] fast with hardly any load.
5 - IT’S BUILT TO MY TASTES
I don’t need to adapt my ways to Rails. I tell PHP exactly what I want to do, the way I want to do it, and it doesn’t complain. I was having to hack-up Rails with all kinds of plugins and mods to get it to be the multi-lingual integration to our existing 95-table database. My new code was made just for me. The most efficient possible code to work with our exact needs.
6 - I LOVE SQL
Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me.
...
Rails vs. PHP: MVC or view-centric? (http://www.megginson.com/blogs/quoderat/2005/06/11/rails-vs-php-mvc-or-view-centric/).
...
[...] the two are drastically different: PHP encourages a page-oriented architecture and makes you do a lot of extra work to get any kind of model-view-controller (MVC) setup; Rails enforces an MVC architecture with pre-defined naming conventions for database tables, etc., and makes you do a lot of extra work to design your application any other way.
I’ve long been an MVC and Java servlet fan. I love object-oriented programming, use REST as a web architectural style, and tend to think of XML-encoded data in entity-relationship terms. So why did I like PHP so much better than Rails?
I think that the answer has to do with the fact that web applications — whether producing HTML for people or XML for machines — are really about views, not objects. In anything but the most trivial cases, the views involve information from many different types of objects merged together to create a new object type. The most common way to generate these views is through SQL queries joining together different tables, and the columns in the result set define the properties of the new object type. I’ve spent a lot of time trying to use and trying to write object persistence layers for web applications, but they never made sense — my models always progressed quickly through the simple CRUD steps (X.create, X.read, X.update, X.delete) but then fell apart as soon as I tried to make my app do anything other than manage its base data. Should I define a new Java class for every possible kind of query result? How do I handle results that do not involve full objects? If I’m not getting full objects in query results, what’s the point of a persistence layer in the first place?
After all that soul-searching, prototyping an app in PHP was like a cool breeze on a hot day. I wrote a few helper functions to automate escaping values to avoid SQL or HTML insertion attacks, but I managed to fight off the temptation to write a persistence layer in PHP. Instead, each page has some PHP code at the top that makes one or more SQL queries, followed by HTML markup with only minimal PHP added to insert dynamic results. It works, it actually seems scalable and maintainable, it’s easy to deploy (just about all ISPs already support PHP, so you just upload the *.php files), and debugging is trivial, because the query is right there on the page with the HTML that will display its results. Bugs are not buried deep beneath 20 layers of abstraction, and the database and filesystem are the only shared state.
Rails, on the other hand, was a disappointment. It tries to make my database invisible so that I think I’m dealing only with objects, but my database, and its query capabilities, are what will make my application more than just a collection of objects with a simple search box. I ran into a bug during one of the tutorials and it was almost impossible to trace the problem due to the deep layering. And the only thing that Rails seems to simplify is the basic CRUD operations, which are the easiest part of any web app. Rails also tries to tell me exactly how to set up my database and page hierarchy — I know that I can change it, but by the time I’ve learned to do that, would Rails still be any easier?
I don’t know if I’m ready to jump to PHP for serious development yet. [...] At the very least, though, I’m going to stop worrying about abstracting away the database and will try to learn to love it, whatever environment I use.
Of course, it’s totally possible that the framework is just not for you, but to me, Rails’ architecture actually makes me more likely to think in terms of “how should this view really work, ignoring how I’ll have to implement it.” because there is so much less friction doing something like user.neighbors.magic_data rather than writing a bunch more
$query = “SELECT *…” $result = mysql_query($query)… while ($line=…
At the very least, though, I’m going to stop worrying about abstracting away the database and will try to learn to love it, whatever environment I use.
I hear ya. I’m over in Perl-land, but there too, all abstraction layers have failed to really let me use a database as much more than an object persistence layer. SQL is a powerful way to combine and recombine data; all the persistence layers I’ve tried simply force me to clumsily reimplement the work the database can already do for me, and do so much better than anything I can write in the time willing to [spend] on it.
Wouldn’t a better comparison be PHP vs. Ruby or maybe Blue Shoes vs. Ruby on Rails? Comparing a scripting language to an application framework doesn’t seem like the best way to go.
I have to agree with Keith. You are comparing apples and oranges. It’s like comparing PHP with Strus + Tapestry + Hibernate. Which one would you say it’s easier? Still, you would have to admit that Rails is a lot easier that such a Java combo. Personally I make a living developing in PHP and have used different MVC PHP frameworks (and built my own) and now I’m starting to use Rails. I’m making my company switch to Rails for some large projects and I’m not looking back. Good luck with straight PHP.
Its not a question of objects *or* views, the real answer is both. Rails provides that balance very nicely.
PHP vs rails might be apple to oranges, but In my own experience there is much more than a grain of truth in the concept that most MVC/application frameworks are (1) not really needed in building 99% of web apps, and (2) tend to be more complex than the problem they aim to solve.
Separating SQL from html is usually a best practice that will give you 80% of code reusability and maintainability.
SQL-to-object layers will usually be: (1) - harder to debug: is the local cache copy of the data in sync with the db? (2) - slow: you are giving away the best features your DBMs gives you. You are usually better off writing a stored proc than a query anyway. And what about objects that map to n tables? You will have to write views first, that map into objects. (3) - much less widely known and accepted than plain SQL. Next coder in the project is likely to have had sql experience, not necessarily experience with db-abstraction-layer-of-the-month
Templating languages are nice, but things get complicated very quickly as they evolve into full fledged languages (see Smarty for a behemoth). In the end a simple language is a better bet than a good framework!
I had many of the same concerns with Ruby on Rails - until I moved passed the prototype and started developing real applications with the framework.
The #1 reason I’ll never code in PHP again (and try get out of J2EE) is that RoR makes it easy to do things the right way. I reuse far more code and I find it drastically easier to track down bugs, conduct unit tests, use continuous integration, and refactor.
These are things you won’t experience in a weekend prototype - they are brought to light when you deliver an easily expandable, well-tested, and working application to clients.
PHP fanboys are failing to see a very important distinction here - Rails is for building scalable web *apps*, not for building a quick data-driven website.
My own site is 100% PHP, and I will not likely change that. My newest project, however, will be in Rails, because it’s simply far easier to build an object-based web application in a framework like Rails, than coding in PHP. I should know, this is my 5th attempt at building this project. I’ve tried Perl and PHP, and am finding that 2 months of rails work is already surpassing 3 months of PHP work, and the system is far easier to debug and extend.
Making the database invisible shouldn’t cost speed. Rails creates the SQL and you can view it all in the logs to see what’s going on. I’m not going to claim the SQL is as good as if I had hand-written it, but it’s not something I’m concerned about causing speed issues. The backend seems to be pretty well-written, and continues to improve.
Another consideration is that all RAD tools come with a cost in speed. VB is a language I despise, but I can’t deny that people with vision have been able to throw together an app in a short time, and provide a valuable and useful product that fills a hole somewhere. At my previous job, we originally aimed for Visual C++, scoffing at our competitor who used VB. The competitor constantly outdid us, building new features faster (and with more stability) until we switched to Delphi.
What was my point… oh yes, speed tradeoffs. In most cases, if you use a RAD tool properly, you’ll lose a small bit of performance and cut down the development cycle drastically. For most web apps, the query performance isn’t the problem - it’s the bandwidth. And with rails’ architecture, using proper page/action/fragment caching is a breeze, so you can optimize *later* if you need to, without any code redesign.
Final thought: don’t rag on rails if you don’t spend a good deal of time playing with it. It may claim to be easy to learn (and it is, mostly), but there are things that make a lot of PHP/Java/Perl people change their minds when they dig deeper than the first layer. It’s really easy to use non-traditional database table and field names if that’s what you want to do, or if you’re connecting to a legacy database, for instance. Many-to-many relationships are expressed so easily it’s almost criminal. Hierarchical data structures, which are usually a pain to implement in a relational database, are a breeze. AJAX functionality, as of 0.13.1, is extremely powerful and still easy to use.
Dig deeper; you may be surprised at what Rails can do.
The problem here stems from the incorrect definition of what a web application is — it is not about views, nor is it about objects. A typical web application is centered around the state.
The MVC metaphor (or pattern) is solely concerned with the state as well. This is why it is a very natural fit for the web application paradigm. As the user/community interacts with a particular web app, it changes its state. That change governs how is the web app going to behave, which in turn facilitates various behavior from the end-user/community. All these changes in state need to be detected/processed/communicated by the web app.
Rails is by far the most sophisticated platform for enabling developers to articulate the above described dynamics. Placed next to Rails, J2EE and/or .NET platforms look like a very elaborate simultaneous translation session during a rock concert for the hearing impaired. Yes, it is possible to ’sort of/kind’ of communicate in real time what’s going on at the concert stage using the sign language, but the real thing is to actually plug in and experience the performance directly.
...
My system is homegrown so it isn’t anywhere near as configurable as some of the open source models. But you’re comparing Rails to the absolute worst way of coding within PHP. Only newbies program in php by shoving php code (and sql commands! Ugh!) in the middle of an html page.
I’m sorry but this article is very irresponsible. You played with the two languages for a couple days and then you write an apple-to-oranges comparison with nothing more than a cursory first impression.
First of all, you haven’t spent enough time building PHP apps to realize that you end up doing a ton of repetitive work. Sure it feels faster than the ever-verbose J2EE, but combine a dynamic language like PHP with a good MVC framework and you’ll triple your productivity again.
As for Rails, you claim that it tries to hide the database, is difficult to debug, and only helps with CRUD. You are wrong on all counts.
First of all, RoR is very careful to give you hooks to any level of abstraction you want, from the common find and find_all queries through custom joins and where clauses, down to raw SQL. Why is this better than raw SQL? Because 90% of queries are the simple ones. Just because you are familiar with SQL doesn’t mean a simpler syntax isn’t better.
As for debugging, Rails is slightly weaker than PHP in terms of raw print lining, but it excels with features such as the breakpointer and logger. Not to mention you can debug the model completely separately from the command line. The ruby console allows you to modify instances of objects, not only changing methods, but modifying and creating singleton methods on the fly. This opens up debugging doors that users of almost any other language can only dream of. Debugging rails is actually pretty easy, but of course it will be hard when you are a complete beginner to ruby and rails.
The whole CRUD thing is a typical argument by people who make a snap judgement after watching the 15-minute video. Scaffold is not even 1% of Rails. It’s practically an afterthought. What makes Rails special is how it utilizes Ruby’s advanced features to set up a framework where you can truly Not Repeat Yourself to the maximum extent possible. Look into routes, flash, helpers, filters, callback, validation, and observers before making these kinds of snap judgements.
...
http://www.killerphp.com/articles/will-ruby-kill-php/.
...
Ruby has a long way to go, I can’t argue for the programming details as I still like my Perl but from the SysAdmin side Ruby and Rails for the matter are an absolute nightmare.
Ruby in itself is slow, doesn’t understand threads like every other language out there so it doesn’t integrate into apache like PHP or Perl or Python or the other hundreds of web scripting languages.
Until Mongrel came out you were forced to use fast_cgi, which is a dead method of rendering pages, apache’s mod_fcgi is crap and lighttpd’s fcgi is better but the server itself is not stable enough for production.
Ruby has to start by modernizing it’s preprocessor before it even has a small chance in hell of overtaking PHP and even then Rails has a long way to go before it’s ready for the primetime, the ease at which a programmer can cause Rails to leak memory is astounding.
I have a shared server with 40 Rails sites running and I have to restart them every week or the box swaps and that’s with 4G of memory, most of these sites aren’t even that intense. On the other hand one of my mod_perl servers has over 100 ecomm type sites and they run just fine of 2G.
So the answer is no, Ruby will not overtake PHP in the distant future.
