HTML Básico vs Aplicación AJAX ¿Son buenos los extremos?

diciembre 7, 2010
By

La evolución de la Web puede ser a veces comparada con la Moda en donde existen momentos “Retros” en que se vuelve a los inicios y se retoman los principios básicos. Inicialmente un sitio web era un conjunto de páginas html estáticas enlazadas mediante vínculos (hipervínculos). Luego se comenzaron a procesar estas páginas desde el servidor utilizando algún lenguaje como por ejemplo PHP, ASP.NET, etc, devolviendo así un contenido más dinámico y extendido, producido por solo un conjunto pequeño de estas páginas “inteligentes”. Pero todo no quedó ahí. Comenzó a surgir el concepto de Aplicación Web llevando lo que era una página que representaba a un documento hacia una mímica de interfaz de usuario para dar la sensación de “aplicación de escritorio” llegando al clímax con la tecnología AJAX, sus Widgets JavaScript y finalmente reventando con las RIAs donde se encuentran Flash/Flex, Silverlight y actualmente luchando por el trono, el embrión HTML5 que, según los pronósticos, llegará para quedarse.

Recientemente tuve que desarrollar una aplicación web que por simplificar digamos que consistía en mostrar una tabla de datos (un listado de frutas por ejemplo) en la cual al hacer clic sobre un elemento de la tabla se visualizaran los detalles del elementos (un maestro/detalle simple).

Desarrollo Web orientado a Aplicación

Dejándome llevar por la furia de la tecnología, el “Bleeding Edge”, pues se me ocurrió publicar los datos de que se mostrarían en tabla utilizando un servicio que produjese JSON para luego ser consumido por un Widget JavaScript creado con la biblioteca ExtJS (Excelente biblioteca por cierto!) y por supuesto, al hacer clic sobre un elemento, sacar una ventaja JavaScript con el detalle que a su vez fuese consumido vía AJAX/JSON desde otro servicio. Además como orquestador de todo pensaba utilizar ASP.NET MVC de forma tal que estos “servicios” que producen JSON estuviesen más acorde con la arquitectura ROA (Resource Oriented Arquitecture). Este acercamiento podemos decir que está “Orientado a Aplicación” debido a que el servidor no produce una página/documento sino una aplicación JavaScript que ejecuta en el navegador del cliente y carga por demanda los datos directamente (a través de una producción JSON). Y por supuesto, no hablemos de aplicaciones Silverlight o HTML5 que tienen un mayor número de posibilidades por estar ejecutando en el navegador del cliente, acercándose mucho más al concepto de aplicación.

extjs_grid_screenshot

(Para más información ver el artículo en inglés “A Grid with Ajax/Pagination/Sorting/Filtering on ASP.net MVC with ExtJS and Enitiy Framework”)

Sin embargo, este acercamiento tiene un problema: como no es un documento/página, no es indizado por los buscadores y no aparece en las búsquedas de Google, Yahoo, Bing, etc (Note que los crawlers no ejecutan JavaScript, por lo cual el contenido de la aplicación no podrá ser representado).

Desarrollo Web orientado a Documentos

El opuesto sería crear una aplicación ASP.NET MVC que produzca una tabla HTML y a su vez utilizar una URL REST para generar las páginas de detalles. Este sería el acercamiento “Orientado a Documentos” y sería localizable con cualquier buscador porque en principio “son solo páginas html clásicas”. Y ese es el éxito de MVC: generar dinámicamente páginas html “estáticas”. Y con estáticas por supuesto me refiero a que cada recurso es identificado por una única URI aunque sea un solo controlador desde el servidor el que genera los recursos (principio MVC).

medalwinners2_thumb

No obstante, esta es una regresión bastante cruda a los principios ya que se pierden los comportamientos “ricos” de filtrar, ordenar y paginar que todos esperaríamos tener (sin realizar recargas/postback por supuesto) y que sin duda son la razón de ser de JavaScript.

Un punto medio

Retomando la pregunta, ¿Son buenos los extremos? Después de leer el artículo Walkthrough: full example of using MvcContrib grid with jQuery datatable llegué a la conclusión de que lograr un balance medio es mejor.

¿Que tal si tuviésemos una solución que fuese REST (ASP.NET MVC) y que devuelva inicialmente HTML clásico y en caso de que el navegador soporte JavaScript pues “mejore” este HTML?

Pues el componente jQuery datatables 1.4 es un plugin para jQuery que tiene esta funcionalidad: lee el tag <table> de una página y extiende la misma con la funcionalidad de filtrar, ordenar y paginar. El funcionamiento de este y otros plugins de manera general consiste en explotar la estructura declarativa del documento HTML y modificarla en tiempo real; no siendo así en otros casos como el Grid de ExtJS que es una aplicación JavaScript a la cual se le insertan datos mediante código JavaScript.

Claro, también hay que tener en cuenta el escenario en el que se va a utilizar la aplicación web. Si estamos desarrollando un marco de trabajo para crear Blogs, está claro que sería inteligente seguir el principio ROA y utilizar AJAX/JavaScript con cuidado, para que se preserve el concepto de “documento”. Sin embargo, si estamos haciendo un Juego en HTML5 pues perdería sentido el concepto de documento.

Conclusiones

Generalmente los extremos son excluyentes y lo que bien se gana a un lado puede ser a costa del sacrificio de otras características, por lo que sería importante analizar qué escenario se quiere resolver y si es importante conservar el concepto de “documento” en nuestra aplicación. Personalmente soy un fan de ExtJS producto de la calidad de la interfaz de usuario que se puede elaborar, pero reconozco que no es la respuesta a todo; me gusta más la filosofía de jQuery con sus DataTables cuando de “documentos” se habla.

Tags: , , , , ,

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Acerca del autor...

Alejandro Tamayo

Web: http://www.linkedin.com/in/atamayocastillo
Alejandro Tamayo
Professor, Researcher, Developer, Consultant and technology enthusiast. Master of Science (MSc) in Computer Science and member of Weboo Research Group.Leer completo