This may be a rumor but Techcrunch is reporting that Twitter is abandoning Ruby on Rails due to scalability issues. I have read a few articles a while back about people having problems with Ruby on Rails. That is why I was hesitant to use Ruby on Rails on some of my web applications (at work). I was hesitant so therefore never got to learn it either :(.

Personally, I think the best bet for Twitter would be PHP. I would trust my life with PHP especially with scalability issues. Techcrunch also mentioned Java, but I doubt Java would work for them. Remember Friendster a few years back? It had a .jsp extension in the URL and it was almost unusable. It was dead slow.

The developers of Twitter can write a clone within a day and no one would notice it. They should use the Zend Framework Anyways, PHP is FTW!

I found this:

jRails is a drop-in jQuery replacement for Prototype/script.aculo.us on Rails. Using jRails, you can get all of the same default Rails helpers for javascript functionality using the lighter jQuery library.

jRails provides drop-in functionality for these existing Rails methods.

o Prototype
o form_remote_for
o form_remote_tag
o link_to_remote
o observe_field
o observe_form
o periodically_call_remote
o remote_form_for
o submit_to_remote

o Scriptaculous
o draggable_element
o drop_receiving_element
o sortable_element
o visual_effect

o RJS
o hide
o insert_html
o remove
o replace
o replace_html
o show
o toggle

Click here.

An article where a couple of guys decided to use Ruby on Rails instead of Java and Google Web Toolkit. I would encourage everyone who is learning RoR to read the entire article. Don’t skip the last part of the article - it should give us RoR newbies a heads-up.

Snip. Snip. Snip.

We had a great introductory ride on Ruby on Rails. We didn’t know Ruby or Rails at all before we started, and we were able to launch a pretty sophisticated web app in a short amount of time. But of course, as with all things, there were mistakes we had to make — mistakes that we would rather avoid in the future.

Design First in HTML + JS
Our biggest mistake: we didn’t complete our interface design before we started programming in rails (Getting Real did teach us to Design Interface First). This was completely understandable, because we didn’t really know what (design & interface-wise) was really hard, versus what was easy to implement in rails. We had to play around with the programming and implementation before we completely designed our app. If we hadn’t, we might have designed our way into an impossibly difficult interface to implement in rails.

But now we know what rails can and can’t do. And we really can’t stress this enough - WE WILL DESIGN OUR INTERFACE FIRST - COMPLETELY! This means we will sit down together and draw every page out on paper together (we like to do this over meals). Once the paper mockups are in order, we will then create full HTML mockups with javascript. Once we settle on the user interface, we’ll go back and “fill in the blanks” with server side code. The beauty is that in Rails, it really is fill-in-the-blanks, and it makes design first a breeze.

Good Javascript Libraries
There were a few painful points that we thought took a long time when writing our app. One of them was surely javascript. Although prototype and scriptaculous are a good start (particularly because there are great helpers to interface with them in rails), there is so far to go in this department. Before we try to write a lot of javascript, we’ll be sure to write additional helpers between rails and our JS code to make it drop-dead-easy to create features.

Use Fixtures Sparingly
When we started testing fixtures provided a way to quickly setup test data. However as our models became more complex and the relationships between them more involved, maintaining fixture data quickly became a headache. Going forward we will be using Mocha to create mock objects for our tests where there is a need to setup relationships between models.

Caching
When we started coding we had discussed implementing caching, but as deadlines approached we kept putting it off. Sure enough when the Beta launched, we didn’t take advantage of caching. In the future we know that we will need to implement caching, but it will probably require a good bit of refactoring to be effective.

Grab the article here.

A very interesting post since I have been keeping an eye on RoR for sometime now.
Some snippets below…

There are rather significant syntactical differences between PHP and Ruby. For example PHP requires semicolons at the end of lines and generally requires curly brackets to enclose blocks of code. Ruby, on the other hand, uses newline characters to denote the end of a line of code and many code constructs such as function definitions, and various loops are ended with the word “end” rather than being surrounded by curly braces.

And their similarities?

Before getting started, I know that PHP and Ruby have very significant syntactic differences and different people may prefer one over the other. So it may be harder to implement certain features in one language over the other. Nevertheless both languages can do almost the same things. Both languages have try/catch/throw style exception handling. Exceptions are new to PHP5 as PHP4 does not have them. Both languages can be used in an object oriented way. Ruby has more powerful object oriented features but most developers probably won’t notice a difference in a normal web application. Both languages have additional functionality that can be added through libraries. In general, when developing web applications, I have not yet run into a time when I was working with one language and hit a road block where the language I was using was not capable of expressing the functionality I needed. Sometimes things are easier in one language versus the other but both PHP and Ruby have been able to “do” the same things.

And then the author’s conclusion…

I suspect very few people will argue that PHP is a more elegant language or is more powerful than Ruby. Frankly, Ruby is probably may favorite language that I have ever worked with and I have worked with Classic ASP, ASP.NET, VB.NET, C#, Java, and Perl all rather extensively over the years. Ruby is both highly expressive and concise which is rare and refreshing.

Rails is a very comprehensive and effective web development Framework and there’s nothing exactly like it in PHP. You get a huge amount of functionality for free. Developing in Ruby on Rails is also a very fast process because Ruby is a very concise language requiring much less typing than any other language I’ve worked with. CodeIgniter is a really nice PHP framework. It will give you a great boost when developing your next PHP application.

The hosting and deployment struggles with Ruby on Rails is a major sticking point for me though. As the owner of a web development company many of our smaller clients do not have the budget for their own VPS account and even if they did, we don’t have the staff to manage a large number of VPS accounts or dedicated servers. Keeping the security updates current, managing any issues that may occur with email, and all the other headaches that go along with managing your own VPS or Dedicated server is more than we care to take on for the relatively small, practical dfference between PHP and Ruby. For large projects, it may be worth the trouble, but for small to medium sized projects, PHP is much easier to deploy, less expensive to host, and the language is capable of taking on everything those types of sites require. For our projects, development time with PHP is not noticeably longer than with Ruby on Rails. Ruby on Rails integrates a lot of things for the developer.

There is ActiveRecord for managing the link between models and the database, migrations for keeping development and live databases in sync, built in testing, the ajax – prototype javascript library is included, and you get a well defined file system structure. While it may not all be packaged together as well, PHP can do all of the above.

Click here for the entire post.