Este post va en respuesta a la opinión expresada en mi Facebook por un gran amigo que trabaja en Microsoft de Estados Unidos como editor director de la MSDN Magazine, Diego Dagum.

Estos últimos días se ha discutido bastante acerca del futuro de Ruby on Rails en vista de lo que indicó la última lista publicada por Tiobe de los lenguajes de programación más populares del año, comparando los resultados de este año con años anteriores. El lenguaje Ruby ha bajado dos escalones en la lista anual así como Java bajó uno.

Yo no pretendo tener ninguna bolita de cristal ni tampoco clamo poseer una gran visión futurista tecnológica. La verdad es que no tengo idea si es que al framework Ruby On Rails le irá mejor o peor en el mercado durante los próximos años. Pero sí tengo claro algo:

Ruby On Rails insertó en la industria de software y en la academia un estilo de Framework que será (y ya ha sido) copiado y mejorado muchas veces, en distintas plataformas, con diferentes lenguajes de programación, inclusive para variados propósitos, durante los próximos 5 años a lo menos y probablemente varios más.

Recordemos por qué se creó RoR originalmente. Por ahí por el año 2003/2004, David Heinemeier Hansson, un joven programador danés, sabía lo que significaba desarrollar correctamente una aplicación web:

Él sabía por ejemplo que todo proyecto debe partir con el modelamiento de los objetos del dominio de la solución a construirse. Que luego el modelo de datos se debe crear para soportar dicho modelo de objetos. Que existen hoy en día excelentes frameworks de persistencia que se hacen cargo de toda la lógica que implica sincronizar los mismos objetos mencionados con la base de datos que los respalda. Que un patrón de diseño que simplifica enormemente la organización de la lógica CRUD (Create, Read, Update y Delete) de un objeto es el patrón Active Record. Que para evitar el acoplamiento entre los objetos existen igualmente excelentes frameworks de inyección de dependencia. Que el patrón de diseño que mejor separa la lógica de renderizado de la vista de la lógica de invocación del dominio de la lógica del flujo de la aplicación es el patrón MVC (Modelo-Vista-Controlador). Que existen grandiosos frameworks MVC disponibles. Que de igual manera se hallan al alcance general poderosos frameworks AJAX que mejoran significativamente la experiencia de navegación de los usuarios. Que el patrón de publicación de contenido y funcionalidad que mejor se adapta a la arquitectura web instalada y que más aporta a la Web Semántica es REST (REpresentational State Transfer). Que todo software debe generar información operacional (logging) para su monitoreo y detección de errores. Que existen buenas herramientas de logging gratuitas. Que cada objeto del dominio y cada controlador de la presentación debe contar con Tests Unitarios y de Integración que eviten sorpresas en ambiente de producción.

David sabía todo esto. No obstante sabía también lo complejo que es implementar cada uno de los frameworks indicados así como las técnicas y patrones mencionados. Hoy en día el tiempo es bastante escaso para desarrollar software y por lo tanto incorporar tantas buenas prácticas y calidad a un proyecto puede ser en muchas ocasiones prohibitivo. Además, si bien tantas herramientas y librerías le ahorran mucho al programador en cantidad de código a escribir debido a toda la lógica que ya contienen, por otra parte demandan que el programador aprenda a configurar correctamente cada una de ellas. Implementar en un proyecto todo lo anteriormente descrito, implica por lo general mantener docenas de archivos XML de configuración, cada uno con su propia forma de hacerlo. Es más, a veces es más complejo mantener esta configuración que programar la funcionalidad desde cero.

De modo que David pensó: ¿cómo no puede haber algo que orqueste todo esto y proponga una configuración por defecto? Si en realidad lo único propio y exclusivo de una aplicación es su modelo de objetos de dominio, y para todo lo demás, es decir, tanto la lógica de acceso a datos como la de presentación como los aspectos transversales (inyección de dependencia, seguridad, logging, etc.) hay herramientas y frameworks que orientan de manera prácticamente mecánica en la forma de implementarlos.

De hecho, precisamente de eso se trata el patrón arquitectural Naked Objects: una vez completados los objetos del dominio (estructura y comportamiento) tanto la lógica de persistencia como la presentación deben reflejar fielmente los atributos y métodos de esos objetos. ¿Por qué no podía haber un framework de desarrollo de aplicaciones web que implementara este patrón arquitectural y generara todo automáticamente a partir de los objetos del dominio? Y que además incorporara todas las herramientas, técnicas y buenas prácticas esperadas de un buen software.

Pues en ese momento un framework de desarrollo así no existía. Y David lo construyó. Basado en la filosofía de la Convención por sobre la Configuración y en el concepto de Naked Objects, David creó el primer Framework de Desarrollo Web orientado exclusivamente al Modelo del Dominio y que generaba automáticamente código estándar abierto (en contraste con el código propietario, críptico y dependiente de algún engine como los antiguos RAD) para la presentación y la persistencia haciendo uso igualmente de herramientas y librerías libres y estándares, patrones de diseño sofisticados, técnicas avanzadas y buenas prácticas.

Pero en el proceso de construcción de este framework, David aprendió muchas cosas. Aprendió por ejemplo que para lograr la generación de código debía implementar alguna técnica de metaprogramación. Fue cuando conoció Scaffolding, técnica sobre la cual me gustaría escribir en otra oportunidad. Descubrió asimismo que para lograr el comportamiento dinámico que requería, un lenguaje de programación estáticamente tipeado solo lo limitaba. Fue cuando conoció y luego se enamoró del lenguaje dinámicamente tipeado de autoría de Yukihiro Matsumoto (Matz) llamado Ruby.

Sin embargo, así como aprendió y acertó en muchas decisiones, también cometió sus errores, especialmente en lo que tiene que ver con la forma de integrarse RoR con código legacy y en la falta de un modelo de componentes reutilizables (por motivos de filosofía de David).

Pese a lo anterior Ruby On Rails se hizo popular. Miles de seguidores en todo el mundo abrazaron este movimiento, comenzaron a desarrollar con RoR y se pusieron a programar con este lenguaje hasta ese momento poco conocido. Hoy existen cientos de empresas de desarrollo y de hosting para aplicaciones RoR.

La industria se vio atraida a este framework que realmente aceleraba la productividad. Pero también se dio cuenta rápidamente de las limitaciones recién nombradas. De ahí que muchos cuestionaron: ¿si este muchacho lo pudo hacer por qué nosotros no? Y lo hacemos a nuestra manera, para nuestra plataforma, con nuestro lenguaje. Así fue como empezaron a surgir este último par de años nuevos frameworks implementando las mismas ideas de Ruby On Rails pero en nuevas plataformas y con diferentes lenguajes.

En el mundo Java apareció un excelente framework “estilo Rails” 100% integrable con librerías legacy Java y que copiaba perfectamente todo el espíritu de RoR: Grails basado en el lenguaje también dinámicamente tipeado Groovy. Por otra parte se creó una migración completa de RoR a JRuby. En la comunidad Python surgieron los frameworks TurboGears y Django entre otros. Sobre Scala nació Lift. De la comunidad PHP han surgido symfony, CodeIgniter, CakePHP, Zend Framework, Seagull y más recientemente Akelos. Para el reciente llegado MacRuby de OS X, se ha creado NewCocoa. Para la creación de aplicaciones de escritorio Linux siguiendo los principios de RoR nació Quickly. En Ruby mismo han nacido otros frameworks como Sinatra y Waves. Para Clojure se ha creado y está creciendo Conjure. Y hasta para .NET, que ahora ya tiene soporte para IronRuby desde Visual Studio 2010, se ha creado IronNails para el desarrollo de aplicaciones WPF y Silverlight.

Aunque todavía no hay nada soportado directamente por Microsoft, asumimos que pronto surgirá algo sobretodo teniendo presente que Microsoft contrató al creador de Subsonic, una herramienta Open Source que, junto con ASP.NET MVC, brindaban un subconjunto importante de todos los servicios brindados por RoR.

Pero probablemente el salto más importante que en mi humilde opinión ha ocurrido hasta ahora en la evolución de esta clase de frameworks (estilo Rails) es el estreno muy reciente del nuevo framework Roo por parte de SpringSource, los mismos creadores de Spring y de Grails.

Roo es un framework que logra los mismos objetivos de RoR pero sobre el lenguaje tradicional fuertemente tipeado Java. El comportamiento dinámico lo logra gracias a su implementación de AspectJ. Cuenta con la consola de comandos que hubiesen deseado todos los demás frameworks estilo Rails. Si bien es un framework de desarrollo muy nuevo, está montado encima de proyectos open source con años de madurez. Mediante la arquitectura JPA, permite utilizar los principales Frameworks de Persistencia del mercado (entre ellos Hibernate), utiliza Spring como inyector de dependencias, Spring MVC como framework MVC, log4j para el logging, Acegi para la seguridad, JUnit para los tests unitarios y de integración, entre otros proyectos.

Sea cual sea el framework de todos estos que desees aprender y utilizar, descubrirás que en solo minutos podrás tener ejecutándose una aplicación con persistencia (toda la lógica CRUD por cada uno de tus objetos), con elegantes pantallas predefinidas, validaciones avanzadas en la capa web, seguridad y todas las técnicas y buenas prácticas de las que hemos hablado tanto hasta ahora. Probablemente la aplicación que obtengas en minutos no sea tu aplicación final, pero te aseguro que será un prototipo funcional espectacular que te habrá dado un salto gigantesco en el desarrollo de tu software. Ya no partirás desde cero, sino que de una base muy avanzada con todo lo que se supone que una aplicación “correcta” debe implementar.

Descubrirás que ya no querrás volver a desarrollar una aplicación desde cero. Por lo menos tendrás que iniciar tus nuevos proyectos con alguno de estos frameworks estilo Rails. Una vez obtenido tu prototipo funcionando, podrás si deseas seguir con tu desarrollo por tí solo.

¿Qué le pasará a Ruby On Rails en los próximos años? Ni idea. Tampoco encuentro que sea importante saberlo. Al menos no para los que no somos amantes leales de ninguna tecnología en particular (el que me conozca y que desee realizar una extrapolación de la última frase que se guarde el comentario :=P ). Ruby On Rails ya ha hecho el aporte más importante que podría haber hecho a la comunidad de desarrollo de software: nos enseñó lo que supuestamente debemos exigirle como mínimo a cualquier nuevo framework de desarrollo que aparezca. Y eso para mí es más que suficiente.