El mundo del desarrollo Web está un tanto convulsionado. Indudablemente algo esta cambiando, y muy fuertemente, en la concepción de los mismos. AJAX, XHTML y Web 2.0, Firefox o Internet Explorer; XML, XSLT, SGML.

La W3C con sus cada vez mas numerosos estándares; Web Services, Metodologías Ágiles y Frameworks por doquier; PHP, JSP, ASP… y entre todo, 3 palabras que asoman con fuerza: Ruby On Rails (RoR).

Mucho se ha hablado, y se esta hablando de esta nueva tecnología, sobre todos de sus bondades a la hora de encarar proyectos Web. Este artículo se trata principalmente de una opinión, de mi opinión respecto a un tema de esos que necesitan ser debatidos. Comencemos.

La verdadera medida de Ruby On Rails

Primer punto, fundamental por cierto: Ruby On Rails es la conjunción de dos componentes. Por un lado tenemos Ruby (un lenguaje de programación orientado a objetos), y por el otro lado tenemos Rails (un Framework más para dicho lenguaje, como Nitro/Og o RubyEventMachine), que implementa los patrones de diseño MVC y ActiveRecord, entre sus principales características.

Parecería ser que la polémica de moda es: ¿PHP o Ruby On Rails?

Analizando distintas opiniones sobre el tema concluí con que parecería ser, no está del todo claro este punto.

No podemos comparar un lenguaje de programación con un framework para un lenguaje de programación

¿Por qué se genera esta falsa comparación?

La respuesta parecería estar en la misma empresa desarrolladora de Rails. 37signals se encarga de venderlo como la solución a los complicados, extensos y tediosos proyectos utilizando tecnología J2EE.

De solo recordar la ya famosa foto publicitaria “RoR VS. J2EE” (debajo) entendemos claramente a lo que 37signals apunta. Entonces, acomodando los tantos: Por la misma razón que no es válida la comparación RoR vs. PHP, no es valida la comparación RoR vs. J2EE (aunque tiene un mayor sentido).

En este caso, habría que hilar un poco mas fino en J2EE, tomando lo que concierne estrictamente a desarrollos Web (Servlets, JSP, Struts, etc.).

De todas formas, le doy más crédito a esta comparación debido a que J2EE engloba muchas tecnologías: el lenguaje Java junto a otros componentes (Struts e Hibernate entre ellos, buenos puntos de comparación para el MVC y el ActiveRecord de RoR).

La necesidad de un Framework de facto para PHP

Justamente la principal causa del error de comparación de PHP con Ruby On Rails es que al último se lo ve casi como a la misma cosa, favorecido por una baja popularidad de Ruby y una gran explosión de Rails.

Por el contrario, la situación de PHP es muy distinta. La propia naturaleza de PHP como un lenguaje extremadamente liberal, no lo ata con ninguna tecnología extra. Sin embargo, la mejora del modelo de OOP en PHP5 trajo aparejado un número importante de Frameworks (Cake, PRADO, Symfony, etc.) que se van agregando al lote del Zend Framework, aunque a decir verdad, ninguno logra imponerse fuertemente sobre el resto.

El claro objetivo del Zend Framework es desembarcar para quedarse en el mundo Enterprise, y poco a poco se va perfilando como el Framework de referencia.

Dada esta situación, correctas comparaciones podrían ser:

  • PHP On Zend Framework vs. Ruby On Rails
  • PHP on Cake vs. Ruby On Rails
  • PHP on Symfony vs. Ruby On Rails… etc.

Por otro lado, el concepto de Rails como Framework MVC + ActiveRecord, ideal para el desarrollo ágil de sitios Web 2.0 (palabras de los autores), no es la panacea universal ni la solución definitiva, y encontramos soluciones similares en otros lenguajes:

  • Cake (PHP). Anteriormente citado
  • Django (Python)
  • Trails (Java)
  • entre otros…

Que funcionan tan bien o inclusive mejor que RoR, dependiendo del sistema con el que estamos lidiando.

La batalla publicitaria

La realidad es que 37signals en su campaña publicitaria no sale a atacar agresivamente a PHP, como si lo hace con J2EE. Evidentemente, no lo tiene como competidor, o no deja entreverlo según lo que pude apreciar personalmente.

Por el lado de PHP, Andi Gutmans tampoco considera a RoR como un competidor directo, aunque hace una, a mi entender, muy interesante apreciación: “Sentimos que PHP con Zend Framework es superior a RoR, y mientras otras personas lo vean de otra forma en cuanto a sus funcionalidades, definitivamente significa que Ruby estuvo siendo mejor publicitado.

El diseño ingenioso del sitio de RoR y el marketing viral usado por 37signals le dio a RoR un mejor boca a boca que a PHP. Afortunadamente, esto ayuda a elevar la imagen de Zend y a incitar aun mas el uso de su Framework.”

En este momento de la lectura, podemos estar de acuerdo con lo leído, o simplemente pensar que es una opinión muy parcializada. Como habrás podido observar, no hemos hecho más que simplemente “filosofar” un poco sobre si corresponde tal o cual comparación. Es el momento de evaluar otros puntos.

Flexibilidad vs. Organización

Muchos desarrolladores caen en la trampa de decir que mientras RoR es más organizado y fuertemente estructurado a la vez de rígido, PHP es más flexible a la vez de desordenado.

Se podría decir que esto es cierto si estuviésemos comparando lo mismo, pero a la vista de los argumentos anteriormente expuestos, esta comparación es inválida.

Tanto Ruby como PHP son lenguajes de scripting con propósito similar. La principal diferencia son sus enfoques, siendo Ruby de naturaleza OOP, mientras PHP es de corte más estructurado. La organización que le dota Rails a Ruby bien se la puede entregar cualquier Framework a PHP, como ser algunos de los citados anteriormente.

Performance

Definitivamente, una debilidad de Ruby poco conocida (o poco publicitada), es su baja performance en velocidades de ejecución.

Los benchmarks en diversos equipos y con distintas rutinas señalan a Ruby como un lenguaje lento, en comparación con PHP4, y más lento aun en comparación a PHP5. Como contrapartida, posee una excelente gestión de memoria, superior a las 2 versiones de PHP en el mercado actual.

Popularidad y Cantidad de Sitios

Si Ruby On Rails es la mejor solución para el desarrollo de sitios Web 2.0, como nos intenta vender 37signals, lo mínimo que le deberíamos pedir son ejemplos. Y cuando digo ejemplos no digo el ya famoso “Construya un blog en 15 minutos”, sino algo mas enterprise.

La realidad al día de hoy es que los pocos ejemplos de sitios Web utilizando RoR son mayoritariamente de la misma empresa que lo fomenta.

Repasemos algunos sitios Web 2.0:

Repasemos algunos sitios construidos utilizando RoR:

Por otro lado, el ranking TIOBE TOP 20, que mide popularidad de lenguajes de programación, indica un claro ascenso para Ruby On Rails, pero se encuentra actualmente muy por debajo de PHP, y aun por debajo de Python y Perl.

¿Los programadores de PHP están interesados en migrar a Ruby On Rails?

Para contestar esta pregunta tendríamos que plantearnos:

  • ¿Qué nos puede dar RuBy On Rails que no nos puede dar PHP?
  • ¿Se justifica elegir un lenguaje de programación solo por una herramienta que nos proporciona?
  • ¿Se justifica elegir Ruby solo porque tiene Rails?

La respuesta creo que esta en cada uno de nosotros. Dependerá de muchos factores, de las experiencias adquiridas y del grado de satisfacción que se tenga usando PHP.

En mi experiencia personal, viniendo de varios años programando en PHP y probando Ruby On Rails, he tenido una grata impresión, sobre todo en lo referente al startup del desarrollo y en la velocidad que se puede alcanzar desarrollando módulos tediosos, como generalmente son los ABM`s, entre otros.

De todas formas, en general estas mismas tareas pueden ser agilizadas también a través de PHP, usando algún Framework de este estilo, o simplemente para los desarrolladores más experimentados poniendo en práctica las “best practices”, o los principios básicos del diseño de sistemas, antecesores a cualquier Framework.

Respecto de la sintaxis de Ruby, esta claro que al ser un lenguaje influenciado por Perl, Smalltalk, Python y Eiffel, poco tiene que ver con la sintaxis que utiliza PHP, totalmente influenciado por C.

Evidentemente, hay muchos nuevos desarrolladores que se sienten atraídos por esta nueva tecnología y sus bondades. Si eres uno de ellos, y si RoR satisface las necesidades de tu proyecto y maximiza tu productividad, ¡excelente elección!

Mi misión, u objetivo es decirte que no es la única solución ni mucho menos. Para finalizar voy a utilizar la frase recurrente de este tipo de situaciones:

A cada tipo de problema, la herramienta correspondiente. La elección es tuya!