JuanCri.com

miércoles 17 de febrero, 2010 a las 05:36

Hace algunas semanas, comenzamos un experimento para definir la arquitectura básica de las aplicaciones web que desarrollaremos en CxNet de aquí en adelante.

Aunque uno de los lenguajes que más utilizado es PHP (principalmente entre 2001 y 2004), no me siento cómo desarrollando "web". Comparado a la satisfacción de programar software sin interfaz de usuario, que sólo debe cumplir con los protocolos de los sistemas a los cuales se conecta, la web tiene un sin fin de complejidades.

Ésta es mi historia:

HTML: Aprendí gracias a Mosaic y algunas páginas de muestra que venían en el CD de mi primer módem. Luego, cuando por fin pude usarlo para conectarme a internet, seguí experimentando y creé algunas páginas, pero nada de lo que me sienta muy orgulloso.
Perl: Hace unos 11 años, alguien me pidió investigar una forma de listar información sobre empresas en un sitio web. Hice pruebas con Perl, el lenguaje más utilizado para desarrollar CGI en la época, y logré buenos resultados. Perl se convertiría en mi segundo lenguaje de programación (después de BASIC... aunque pasando por alto algunas pruebas con JavaScript).
PHP: Ya el 2001, cuando comencé a trabajar (semi) formalmente, PHP resonaba como la maravilla del desarrollo web. Me tomé algunos días y, utilizando unas mil hojas tamaño carta y varios cartuchos recargables de tinta, imprimí la documentación de la, entonces nueva, versión 4 de PHP. Éste sería uno de los lenguajes que utilizaría por más tiempo. Si bien no habían frameworks en la época, y todas las variables se importaban mágicamente (nada de $_POST o similares), hace algunos años comencé a buscar alternativas como PRADO Framework.
ASP.NET:
Java Struts: Este conocido motor MVC para Java me fue impuesto por el cruel mercado. Nunca me sentí cómodo con él y, después de menos de seis meses de práctica, renuncié a mi trabajo y decidí enfocarme en .NET/Mono, lo que incluía ASP.NET.

Si bien el modelo de ASP.NET, también ocupado en JSF, PRADO Framework y otros, es cómodo y ordenado, uno de los problemas que tiene es el uso de servicios Ajax o JSON y la interacción con JavaScript, nada de natural. Hay varios intentos de amalgamar estas tecnologías que parecen haber sido diseñadas para lo mismo pero que, sin embargo, tienen arquitecturas totalmente opuestas. Un intento es ASP.NET Ajax, el cual incluye un "update panel", en el cual se pueden insertar otros controles que utilizar AJAX por debajo. Otro intento, muy bueno, es Gaia Ajax Widgets. En este caso, sus desarrolladores crearon toda una gama de controles "ajaxosos", extendiendo la funcionalidad de los controles originales. Incluso llegué a comprar una licencia durante una oferta. El viewstate se seguía ocupando, pero no todo era color de rosas. Hay que saber muchos detalles de cómo funcionan estos sistemas, a bajo nivel, para poder resolver problemas que seguramente ocurrirán tarde o temprano, síntomas de una relación ilícita entre dos mundos que se niegan a convivir.

Como todo cambia, especialmente en este mundillo de la computación, siempre hay que replantearse las cosas. En el caso de las plataformas web, esto me ha ocurrido varias veces.

Hay dos criterios muy importantes que deben ser tomados en cuenta cuando se elige una plataforma: el usuario y el desarrollador. GMail es tal vez el gran ejemplo de AJAX. La primera aplicación masiva donde no había que esperar por un refresh o postback y donde el usuario es complacido con una interfaz intuitiva y simple. En el caso del desarrollador, hay un gran problema en el típico framework web mezclado con AJAX (o JSON, etc). Cierto contenido es rendereado en el servidor mientras otro contenido es generado dinámicamente al cargarse datos a través de un request AJAX.

Luego de la popularidad alcanzada por JQuery y la facilidad de uso de JSON en ASP.NET MVC, decidí probar esta combinación. En los próximos posts, les contaré cómo.