Frameworks Web 2.0

¿Qué frameworks utilizar en el desarrollo web? El eterno dilema

Es curioso el proceso de selección de un framework, puedes pasar meses de un lado a otro en internet probando, testeando, leyendo y debatiendo hasta llegar a una decisión final, y seguro que al cabo del tiempo acabarás preguntándote si tomaste la decisión correcta.

Desde nitsnets | studios queremos contar nuestra experiencia/historia y la selección de frameworks que nosotros utilizamos para trabajar en la web 2.0. Quizás no sea la selección perfecta y seguro que será nuevamente debatida, pero a nosotros nos está sirviendo para ser más eficientes, ordenados, e intentar alcanzar una de nuestras obsesiones: la industralización del desarrollo web.

El otro día leía en Loogic, archiconocido blog de negocios en internet, lo importante que es tomar una decisión tecnológica, y estamos totalmente de acuerdo. Sus conclusiones eran que en los proyectos web había poco porcentaje de técnicos en la toma de decisiones, y que la solución más sencilla hará que el proyecto funcione mejor. Nuestro caso por tanto es un poco atípico ya que la toma de decisiones la acabamos tomando el equipo técnico, lo que en realidad creo que también tiene algunas desventajas, pero nos ha ido permitiendo estar siempre a la última tecnológicamente.

Y estas decisiones tecnológicas, cuando te dedicas al desarrollo web, se toman desde el primer día. La primera etapa es obvia ¿qué lenguaje de programación vamos a utilizar? Recuerdo la primera etapa de nitsnets en 2006 cuando dábamos soporte a cualquier lenguaje de programación: PHP, ASPX, ASP, JSP, ActionScript, Java, C#, bases de datos MySQL, Oracle, SQlite, servidores Linux, servidores Windows… era enriquecedor sí pero sinceramente poco lógico y efectivo para un equipo de cuatro personas como éramos entonces.

Selección de los lenguajes de programación en la web 2.0

En pocos meses nos dimos cuenta de lo importante que es la especialización y optamos por concretar nuestro mercado que al fin y al cabo es nuestro producto. Los criterios siempre han sido los mismos: opensource siempre que sea posible, buena documentación y una gran comunidad de usuarios detrás. Estos mismos criterios sirven para la selección de frameworks.

Con el tiempo refinamos nuestra elección:

• PHP como lenguaje servidor. Cuando teníamos que decidir el lenguaje servidor decidimos seguir la misma línea que uno de los grandes de internet (lo era más en aquellos momentos):Yahoo.
• MySQL Es la base de datos más utilizada en la web.
• Javascript, decisión obvia como lenguaje cliente en entorno HTML.
• ActionScript 3.0 como lenguaje cliente para sites corporativos y animados (Adobe Flash) o para gestores de contenidos y aplicaciones web (Adobe Flex)
• HTML, CSS Aquí no nos queda otra 😉

Framework PHP

Inicialmente como en muchas empresas desarrollamos un framework propio: nts framework, con una estructura totalmente piramidal. Ahora da hasta un poco de vergüenza reconocerlo pero ni siquiera era MVC (Modelo Vista Controlador). Se componía básicamente de un simple ORM lineal y una serie de componentes muy estables que habíamos desarrollado en paralelo, todas con su nombre corporativo como el nts | image (tratamiento de imágenes), nts | video (compresor de video online), nts | datagrid (para listado de datos), nts | dropdowlist (combobox con ajax), nts | fisher (copias de base de datos), etc…

Este framework lo empezamos a construir como estudiantes en 3º de carrera (2002) algunos de los integrantes de nitsnets | studios y otros compañeros. Ahora lo recordamos con cariño y nostalgia, así que algo tendría. De hecho, alguna gran marca con la que hemos trabajado aún utiliza su web y gestor de contenidos con esos códigos 😉

Con el tiempo y el avance de la web 2.0 nos dimos cuenta que realizar un framework que abarcara los nuevos desarrollos sería una tarea ardua y compleja. Estuvimos varios meses estudiando diferentes frameworks en PHP, probando, testeando y leyendo mucho. La conclusión a la que llegamos fue: ¿Porqué re-inventar la rueda? (clásico error en este mundillo). Fue justo en esa época, por esas casualidades de la vida, que la empresa que habíamos tomado como modelo a la hora de elegir centrarnos en lenguaje PHP, Yahoo, estaba atravesando un proceso similar e hizo hecho pública su elección del framework Symfony para dos de sus más emblemáticos proyectos como Yahoo Answers y Delicious.

Probamos muy en serio otros principalmente CakePHP y Zend Framework (el cual aún utilizamos sus geniales librerías) y estuvimos a punto de elegir Kumbia PHP por ser un framework realizado por desarrolladores de habla hispana, pero ninguno nos llegó a convencer totalmente. CakePHP porque arrastraba cosas del pasado, Kumbia aún no estaba muy maduro en aquella época y Zend simplemente porque echabamos en falta que fuera más compacto y estructurado.

Tras unas primeras experiencias con Symfony era evidente que su elevada curva de aprendizaje nos planteaba serios problemas, ya éramos muchos y no podíamos dedicar tanto tiempo en formación del equipo. Por esta razón se optó por utilizar el más pequeño y manejable CodeIgniter para proyectos de menos envergadura, compaginando durante un tiempo ambos frameworks en nuestros equipos de desarrollo. Sin embargo, debido a su curva de aprendizaje muchísimo más baja y a su gran velocidad de rendimiento, CodeIgniter fue gradualmente sustituyendo a Symfony para proyectos cada vez más complejos, incluyendo algunos enormes como redes sociales enteras.

Conclusión: CodeIgniter con librerías de Pear y Zend Framework, pero estaremos muy atentos a la próxima salida de Symfony 2.0.

ORM (Mapeo Objecto Relacional)

Una de las principales características dentro de un framework es la capa de persistencia con la base de datos. Una vez seleccionado PHP y su framework hay que dar un pasito más y ver qué ORM utilizar. Un ORM es una técnica de programación que permite mapear los datos de la base de datos en objetos. Una capa de abstracción que nos permite incluso tener independencia con el motor de base de datos utilizado, incluso aunque no sea relacional.

Inicialmente también dentro de nuestro nts framework desarrollamos un ORM lineal en el que cada objeto representaba una tabla de la base de datos y mediante herencia unas clases se encargaban de procesos más complejos. De esta forma evitábamos la reiteración de inserciones, modificaciones, eliminares y listados simples. Todo se generaba a partir del esquema de base de datos. Simple y muy eficaz, pero algo limitado. 😛

Una vez nos adaptamos a los frameworks de PHP también lo hicimos a sus ORM. En el proyecto Openart utilizamos un conocido ORM llamado Propel ya que era el ORM por defecto de Symfony por aquel entonces. Si os hemos de ser del todo sinceros no quedamos muy satisfechos con su utilización, tuvimos que tocar mucho el núcleo para poder hacer querys complejas y de alto rendimiento pero que nos permitieran seguir mapeando los resultados.

Fue con nosplay donde optamos por Doctrine integrado con CodeIgniter. Doctrine ya estaba también para Symfony y se hizo el ORM oficial a partir de la versión 1.2. Lo curioso del tema es que el nuevo Propel que saldrá utilizará Doctrine por debajo. 😉

Con Doctrine aunque no lo utilizamos en todo su esplendor el resultado fue mejor y un desarrollo más ágil, quedamos muy contentos con él y además ahora viene Doctrine 2.0 que promete muchísimo.

Conclusión: Doctrine.

Framework Javascript / Ajax

Con Ajax y Javascript nos dejamos llevar por la inercia del mundo web. Al principio esta tecnología tan sólo lo utilizábamos para validar formularios, pero poco a poco y con la expansión del concepto de Ajax, nos dimos cuenta de que el javascript se había vuelto imprescindible para el desarrollo web.

Inicialmente optamos por Scriptaculous , ya que era el más utilizado y de mayor comunidad online en sus inicios. Así, nuestro proyecto estrella de creación de periódicos y revistas digitales Gopress utiliza Scriptaculous para todas las interacciones Ajax.

Con el tiempo Jquery ganó usuarios, una gran cantidad de plugins y todos hablaban de lo bueno que era ese framework. Empezamos a hacer nuestros pinitos, y cuando nos quisimos dar cuenta ya habíamos migrado totalmente a Jquery. Al principio hacíamos híbridos Scriptaculous y Jquery pero su gran cantidad de incompatibilidades nos hizo migrar completamente. Actualmente Jquery es el framework más utilizado en la web, y con un rendimiento excelente.

También en algunos sites utilizamos Mootools pero fue más para efectos gráficos ya que es un framework muy fluido en ese aspecto.

Conclusión: Jquery.

Framework ActionScript 3.0

Sobre Flash y ActionScript 3.0 hay que matizar mucho para qué necesitamos el framework. En nuestro caso plantearemos el escenario de la creación de páginas web animadas para potenciar una marca o producto, páginas para agencias de publicidad, etc, que en conjunto podríamos denominar micro-sites comerciales.

Inicialmente trabajábamos con un conjunto de clases desarrolladas de forma independientes e inconexas y hacíamos constantes peticiones desde la línea de tiempo. Trabajar en la línea de tiempo es una de las experiencias más caóticas de la programación web pero juntar a diseñadores, animadores y desarrolladores todos a la par lleva este tipo de complejidad implícita.

Con el tiempo y la aparición de nuevas funcionalidades requeridas como el famoso swfaddress, empezamos un framework en AS3 para el desarrollo de sites webs animados corporativos. Este framework propio (con el pseudo nombre de dframework, nunca llegó a materializarse una versión 1.0) tenía como premisa el sacar todo el código fuera de la línea de tiempo y controlar cada pantalla del flash como si fueran páginas independientes de HTML. Después de varios proyectos nos topamos con Gaia Framework y descubrimos que era igual que nuestro prototipo pero totalmente acabado, más estable y con más funcionalidades. Fue curioso ver cómo la filosofía o idea inicial era la misma: un framework pensado para el desarrollo de micro-sites animados. ¿Otra vez reinventando la rueda? Ya habíamos aprendido la lección, y optamos por migrar a Gaia y no mirar atrás. Actualmente los sites los desarrollamos totalmente en este framework junto con una gran cantidad de librerías externas (queuloader, as3lib, etc) y otras desarrolladas por nosotros mismos que quizás en el futuro podamos publicar y ofrecer a la comunidad. 😉

En caso de realizar aplicaciones del tipo RIA (Rich Internet Aplication) existen frameworks muy pontentes de ActionScript 3.0, para trabajar en ActionScript o Flex como son Cairngorm 2.0 o PureMVC, o el que tanto está dando de hablar últimamente Robotlegs.

Base de datos

Siempre optamos por la utilización de MySQL y la verdad que era lo más evidente, al ser la base de datos recomendada por PHP y su base de datos por defecto. A pesar de sus numerosos detractores, de hecho el tiempo ha dado la razón a este motor ya que es el utilizado por muchos de los grandes servicios actuales de internet: Facebook, Youtube, Flickr y un largo etcétera.

Sin embargo, podemos estar a las puertas de un cambio de paradigma ya que hay mucho debate sobre la caída del modelo relacional en las base de datos en internet. El NoSQL coje mucha fuerza y las bases de datos documentales dejan de ser conceptos para convertirse en realidades como Google BigTable o MongoDB. Estamos estudiando estas alternativas porque a nivel de rendimiento pueden aportar mucho, y pensamos redactar nuestros avances en el blog 😉

Conclusión final

Los frameworks son necesarios por no decir imprescindibles ya que nos aportan ventajas inestimables como escabilidad, un mejor mantenimiento, independencia de la lógica de negocio y la interfaz gráfica, desarrollo ágil pero sobretodo orden y una forma de trabajar siempre igual. Aunque como todo en la vida no todo el mundo piensa igual como se puede apreciar en este genial post to framework or not to framework.

La conclusión en cuanto a frameworks web 2.0: CodeIgniter (php), Doctrine (php ORM), Jquery (javascript), Gaia (flash actionscript 3.0). Actualmente lo que hacemos es hacer crecer los frameworks que hemos elegido con librerías extrenas y creando nuestras propias librerías dentro de cada framework. En futuros posts iremos poco a poco desglosando nuestra selección de librerías utilizadas en estos distintos frameworks y lenguajes de programación. Validar formularios, crear listados, tratamiento de imágenes, envío de emails…

Esperemos que os parezca interesante y os ayude en la toma de soluciones tecnológicas.

Reflexiones

¿Qué frameworks utilizáis? ¿Que librerías son imprescindibles en el desarrollo web? ¿base de datos relacionales o documentales? ¿CodeIgniter o Symfony?

Por último y como una última reflexión final ¿Podríamos optar por Joomla, Drupal, Magento, WordPress… como base de nuestro desarrollo software? ¿Estaríamos subiendo un peldaño de los frameworks o nos estaríamos obligando a programar como lo hacen ellos? ¿Podríamos prescindir de los frameworks adoptando un CMS Opensource como los mencionados?.

Etiquetas: as3, css, flash, framework, html, jquery, nitsnets, php, web 2.0