Los origenes de la tecnolog�a web

Cuando Tim Berners Lee invent� la web buscaba un sistema para poder publicar y visualizar documentaci�n cient�fica de forma remota, que fuera atractiva visualmente, f�cil de codificar y f�cil de usar para un no inform�tico.

En un documento cient�fico es imprescindible la referencia a otros documentos citados con el fin de que el lector opcionalmente pueda profundizar en el tema que se trata.

Por estas razones el Word Wide Web se concibi� como un sistema de p�ginas (documentos) e hiperenlaces.

Inicialmente la web era un mundo de p�ginas est�ticas y enlaces pero pronto la generaci�n de p�ginas din�micas y en general el uso de la web como soporte para el dise�o de aplicaciones basadas en web lo complic� todo.

La llegada de las aplicaciones web

Durante a�os ha existido un esfuerzo de adaptar el paradigma de p�ginas y navegaci�n entre p�ginas al desarrollo de aplicaciones, aplicaciones en las que el concepto de p�gina, como documento est�tico id�ntico para todo el mundo tal y como lo concibi� Berners no existe. Diferentes paradigmas de desarrollo de aplicaciones web se han ido sucediendo:

• Model 1: la traslaci�n directa del modelo original de p�ginas e hiperenlaces en donde las p�ginas son generada din�micamente.
• Model 2 o MVC: la navegaci�n entre p�ginas generadas ya no es directa sino que es intermediada por un controlador que decide cual es la siguiente p�gina dependiendo de las operaciones que se hayan realizado en el proceso de transici�n.
• MVC basado en componentes (�Model 3?): es la sofisticaci�n del Model 2 en donde se simula la forma de trabajar en el escritorio, basado en componentes y eventos, de tal manera que una acci�n del usuario supone la regeneraci�n de la p�gina cambiando parcialmente una parte de la misma de acuerdo con la acci�n. La p�gina y la transici�n entre p�ginas ahora es gestionada por componentes que saben qu� cambios han de realizarse en la regeneraci�n de la p�gina de acuerdo al evento, simulando un comportamiento similar a los sistemas de componentes GUI de la programaci�n de escritorio.

En a�os recientes se ha ido introduciendo la t�cnica AJAX, dicha t�cnica con la ayuda de JavaScript permite el cambio parcial de la p�gina obteniendo nuevos datos del servidor sin llegar recargarse �sta. Aunque la pr�ctica del cambio parcial de una p�gina web es muy anterior a la introducci�n del componente XMLHttpRequest en Internet Explorer (base de la programaci�n AJAX), ha sido el uso de este componente el que ha favorecido un uso masivo de la misma.

Hoy millones de sitios web y aplicaciones web usan AJAX para proporcionar una mejor experiencia al usuario gracias a una mayor inmediatez y transparencia evitando parcialmente las molestas recargas de p�ginas.

Sin embargo a pesar del uso masivo de AJAX podemos decir que hoy d�a la web sigue un modelo que podr�amos calificar de "Model 2 (MVC) enriquecido con AJAX", en donde el llamado aqu� Model 3 tiene cada vez menos sentido, pues la introducci�n de AJAX hace en gran parte innecesaria la gesti�n de p�ginas basada en componentes. Como habitualmente el uso de AJAX tiende a estar ligado a componentes (no necesariamente presentes en el Model 2) podr�amos resumir que el estado del arte actual viene a ser un Model 3.5, en donde la navegaci�n de p�ginas se consigue evitar parcialmente en el caso de transiciones de estado menores, las cuales se realizan utilizando AJAX y JavaScript.

�Qu� inconvenientes tiene la navegaci�n y el desarrollo basado en p�ginas?

Todo programador web sabe lo problem�tica que es la navegaci�n por p�ginas en una aplicaci�n web, aparte del derroche de ancho de banda y de tiempo de proceso en regenerar la p�gina completa est�n los problemas con el cacheado no deseado, el back-forward, los inconvenientes del "form auto fill" habitual en los navegadores etc. No es raro ver aplicaciones web que ocultan los menues y botones del navegador o que usan frames o iframes (por ejemplo en bancos) para evitar la problem�tica de los botones Atr�s/Adelante (Back/Forward).

La programaci�n basada en p�ginas tiende a forzar una forma de programar extra�a, repetitiva (plagada de includes) e ineficiente (tanto en ancho de banda como en potencia de c�lculo) que no existe en el �mbito del escritorio en donde no existe esa imposici�n.

�Qu� es lo que impide un uso intensivo de AJAX?

En el �mbito del desarrollo web se suelen distinguir dos tipos de soluciones: aplicaciones web y sitios web.

En el primer caso AJAX tiende a utilizarse cada vez m�s de forma intensiva debido a que este tipo de aplicaciones no tiene algunos de los requisitos de los sitios web, es en los sitios web en donde un uso intensivo de AJAX puede suponer un problema.

En los sitios web el usuario est� acostumbrado al concepto de p�gina, ligados a las p�ginas existen algunos requisitos b�sicos de cualquier sitio web tal y como:

1. Memorizaci�n de p�ginas favoritas (bookmarking): cada p�gina web tiene un �nico URL, dicho URL es por tanto "memorizable" como favorito. Como AJAX tiende a cambiar parcialmente las p�ginas se pierde la posibilidad de guardar favoritos.
2. Search Engine Optimization (SEO): la compatibilidad SEO es un deber de cualquier sitio web, cualquiera puede entender esto. Los actuales robots indexadores de p�ginas ven la web como Web 1.0, es decir, el c�digo JavaScript es totalmente ignorado tal que cualquier cambio parcial de p�gina hecho via AJAX cargando datos del servidor no es conocido por los robots indexadores que atraviesan el sitio web porque dicha acci�n no se realiza.
3. Servicios basados en visitas de p�ginas: por ejemplo anuncios y monitorizaci�n de visitas tal y como Google Analytics est�n basados en el n�mero de veces que una p�gina ha sido cargada. Por tanto los cambios parciales de p�ginas hechos por AJAX no cuentan.
4. Necesidad ocasional de ventanas emergentes (pop-ups)

Estos requisitos hacen que el uso intensivo de AJAX est� desaconsejado en sitios web de gran p�blico. Sin embargo la diferencia entre aplicaci�n web y sitio web es cada vez m�s sutil, de hecho cualquier sitio web es hoy d�a una aplicaci�n web.

�Debemos renunciar a sitios web intensivos en AJAX?

NO.

Hay soluciones t�cnicas a los requisitos anteriormente mencionados.

�Es posible el desarrollo de sitios web basados en una �nica P�gina Web (SPI)?

�SI!

Es el momento de realizar esta transici�n en las que todos, programadores y usuarios saldremos ganando. Tenemos la tecnolog�a y los navegadores ya est�n a la altura para conseguir este objetivo.

Para ello es preciso compatibilizar el funcionamiento de la t�cnica Single Page Interface (SPI) con los requisitos mencionados anteriormente de cualquier sitio web.

Adi�s a las p�ginas bienvenidos los estados

Si en una aplicaci�n web sin JavaScript la sucesi�n de estados equivale al de p�ginas, en una aplicaci�n SPI cualquier cambio parcial de la p�gina supone un estado (o estado de "la p�gina"). Entre los estados hay que distinguir dos categor�as de estados:

• Fundamentales
• Secundarios

La diferenciaci�n entre ambos tipos de estados es importante, porque los estados fundamentales ser�n p�ginas web cuando sea necesario, ser�n aquellos estados que merezca la pena que sean vistos tambi�n como p�ginas web. La distinci�n entre estados fundamentales y secundarios depender� de cada sitio web.

Para entender ambos tipos de estados es conveniente considerar un ejemplo real: la validaci�n de un usuario a trav�s de login y password.

En una aplicaci�n cl�sica existir�an dos p�ginas, la propia del login la cual se recargar� cuando el login es incorrecto mostrando adem�s alg�n mensaje de error, y la p�gina de entrada correcta mostrando al usuario las posibles opciones.

En una web SPI tanto el estado donde se muestra el login inicial como el estado de entrada correcta mostrando las opciones podr�an considerarse los estados fundamentales, los estados en donde se muestran los mensajes de error de login mostrando de nuevo el formulario del login podr�an considerarse estados secundarios.

En el caso de un sitio web basado en p�ginas que se quiere convertir en una web SPI, los estados fundamentales normalmente ser�n los equivalentes a las p�ginas y los secundarios cuando a partir de un estado fundamental (la antigua "p�gina") se producen cambios menores que no merecen la pena (por ejemplo) ser memorizados como favoritos o ser procesados por un crawler.

Single Page Interface y Bookmarking

Diferentes p�ginas tienen diferentes URLs, si se sigue la ruta SPI �c�mo cambiar el estado y la vez la URL para poder ser guardada como favorita sin recargar la p�gina?.

Hay un truco, y es a trav�s de la referencia del URL ("hash fragment", shebang o hashbang), la parte final del URL tras el car�cter #, que sirve para situarse en un punto concreto de la p�gina (a trav�s de un <a name="ref"></a>). Un cambio en esa parte del URL (si existe) no provoca la recarga de la p�gina, por lo que al mismo tiempo que cambiamos de estado fundamental de la p�gina podemos cambiar la referencia del URL a trav�s del objeto JavaScript window.location sin provocar una recarga. Como el URL cambia al mismo tiempo que el estado fundamental, el usuario puede memorizar en cualquier momento dicho URL como "favorito" en su navegador.

Cuando dicho usuario quiere volver en otro momento al estado memorizado como favorito directamente, el estado objetivo est� presente en la referencia del URL, se producir� una solicitud al servidor, sin embargo dicha referencia por desgracia no es enviada al servidor porque se considera que no forma parte del URL desde el punto de vista de las comunicaciones HTTP, por ello es preciso un proceso post-carga.

El servidor devolver� una p�gina inicial en el que no ha considerado el estado requerido sin embargo el objeto window.location contiene la URL completa de la p�gina cargada incluyendo la referencia. Si nada m�s cargar la p�gina se detecta la presencia de una referencia de estado, v�a JavaScript y window.location es posible reescribir la URL y parametrizarla de forma normal para que vuelva a hacerse una nueva request al servidor para que sirva la p�gina directamente en el estado requerido.

Otra opci�n, mejor que el uso de hashbangs, surge con la llegada de HTML 5, la HTML 5 History API.

Single Page Interface y Search Engine Optimizaci�n (SEO)

La forma m�s sencilla de conseguir que nuestro sitio web sea procesable por los motores de b�squeda es ofrecer dos modos de navegaci�n diferentes, a los usuarios de la web como SPI, y a los robots indexadores como p�ginas.

El siguiente ejemplo de enlace muestra esta idea:

<a href="URL p�gina" onclick="return false">�</a>

Este enlace no har� nada en un navegador con JavaScript activado porque la navegaci�n est� desactivada a trav�s del "return false" del atributo onclick y sin embargo un robot indexador ignorar� el atributo onclick pues el c�digo JavaScript es ignorado, y considerar� el URL especificado como una p�gina a procesar.

En el �mbito de una aplicaci�n SPI, los URLs usados para navegaci�n de estados/p�ginas deber�n contener el estado destino, el mismo tipo de URL que usamos en bookmarks (utilizando una referencia para indicar el estado) o directamente indicando el estado como un par�metro, esta �ltima opci�n es la preferida pues evita una solicitud al servidor, por supuesto siempre es posible utilizar "pretty URLs" para este fin.

Actualmente Google ya procesa "AJAX URLs", es decir, URLs conteniendo el estado objetivo en la referencia de la URL siguiendo #! como se especifica en Making AJAX Applications Crawlable, en este caso el sitio web/aplicaci�n debe devolver la p�gina solicitada en este caso a trav�s de un par�metro _escaped_fragment_.

Al mismo tiempo el framework SPI puede a�adir c�digo espec�fico al onclick antes del return false o asociar un "event listener" al enlace registr�ndolo a trav�s de addEventListener o attachEvent dependiendo del navegador, dicho event listener podr� estar vinculada a una acci�n que se comunique con el servidor via AJAX para efectuar el cambio de estado. Cuando se pulse el enlace dicho cambio de estado no ser� una carga de una nueva p�gina pues el atributo onclick="... return false" impide el comportamiento por defecto del enlace.

La t�cnica descrita es la m�s sencilla e inmediata a trav�s de enlaces visibles compatibles con robots y con SPI, siempre es posible separar ambas funcionalidades utilizando enlaces ocultos para el usuario pero visibles para los robots junto con otro tipo de elementos "pulsables" para efectuar las transiciones de estado SPI a trav�s de JavaScript, los cuales ser�n invisibles para los robots.

Es fundamental que el framework web servidor tenga la capacidad de generar la p�gina web en el estado requerido como HTML en tiempo de carga, pues lo normal es que la transici�n de estados tras la carga se realice a trav�s de JavaScript con cambios parciales de p�gina. Esta dualidad entre renderizaci�n parcial de estados via JavaScript y como HTML en carga directa de estado son requisitos imprescindibles para conseguir un sitio web SPI y a la vez capaz de simular p�ginas.

SPI y los botones Atr�s/Adelante

Los botones Atr�s/Adelante son una fuente de problemas en sitios web basados en p�ginas y deber�an ser evitados lo m�s posible. A pesar de que los usuarios finales est�n acostumbrados a evitar los botones Atr�s/Adelante cuando est�n enviando un formulario de datos (porque conlleva el riesgo de comprar dos veces el mismo producto), el uso de los botones Atr�s/Adelante es enormemente popular.

Aparentemente el paradigma SPI rompe la tradicional forma de navegar en un sitio web, porque en teor�a los botones Atr�s/Adelante no tienen sentido en SPI (no hay p�ginas) y los navegadores web no proporcionan un buen control de estos botones.

Esto no es totalmente cierto, el comportamiento de los botones Atr�s/Adelante puede ser simulado, en vez de navegaci�n por p�ginas, Atr�s/Adelante (y la navegaci�n en general por la historial del navegador) puede ser usado para cambiar el estado actual al previo/siguiente estado. En este caso un c�digo JavaScript puede detectar cuando la parte "referencia" de la URL cambia y solicita a la aplicaci�n que cambie el estado al especificado en la URL. Debido a que el navegador no cambia la p�gina, tu aplicaci�n es ahora totalmente responsable del comportamiento del Atr�s/Adelante evitando los t�picos problemas del uso de Atr�s/Adelante cuando se env�a un formulario de datos, ahora en SPI no hay tal formulario y no hay navegaci�n por p�ginas no controlada por la aplicaci�n/sitio web.

SPI y los servicios basados en visitas a p�ginas

Los servicios de anuncios o los contadores de visitas a p�ginas est�n basados en cargas de p�ginas. En ambos casos es posible usar elementos ocultos <iframe> conteniendo una p�gina web con los scripts requeridos por dichos servicios.

En el caso de los servicios de anuncios tal y como Google AdSense la inserci�n din�mica del <iframe> supondr� la carga de los anuncios por lo que cada cambio de estado puede suponer una nueva carga o inserci�n din�mica del <iframe>. Google AdSense parece detectar cuando el script de AdSense es ejecutado dentro de un <iframe> y tiene en cuenta el contenido del la p�gina contenedora. Puede ser conveniente a�adir alg�n tipo de par�metro que identifique el estado fundamental que est� cargando el <iframe>.

En el caso de los scripts de visitas, podemos utilizarlos como monitorizaci�n de visitas a estados fundamentales de nuestra sitio web SPI. En este caso el <iframe> oculto contendr� una p�gina web normal que simplemente contiene los scripts de control de visitas, a trav�s de un par�metro podremos indicar al script qu� estado fundamental estamos visitando. Dicho <iframe> es conveniente que sea un elemento global que es introducido en la p�gina una sola vez. Cuando un estado fundamental es cargado a trav�s de una URL, el <iframe> de control de visitas convendr� que tenga como par�metro la informaci�n del estado siendo cargado. Tras la carga inicial cualquier cambio de estado podremos notificarlo cambiando la URL via JavaScript de acuerdo con el nuevo estado, dicho cambio provocar� una recarga del <iframe> de visitas memorizando dicha visita al estado.

SPI y las ventanas pop-up

La creaci�n de una nueva ventana supone claramente una ruptura con el modelo SPI, pero no hay que ser fundamentalista, si el estado de dicha ventana no interfiere en el estado de la p�gina que la cre�, nada hay de malo en el uso de ventanas pop-up como p�ginas normales.

El problema surge cuando las acciones realizadas en una p�gina "pop-up" influyen en la p�gina padre, ya sea dicha p�gina/ventana modal o no modal, la coordinaci�n entre p�ginas es complicada. Por ejemplo no hay un est�ndar web para gestionar p�ginas web modales respecto a otra p�gina, pues el concepto de p�gina tradicionalmente ha sido siempre el de un elemento aut�nomo y por tanto su ciclo de vida es dif�cilmente coordinable desde otra p�gina.

Este problema desde hace tiempo tiene soluci�n en SPI y consiste en la simulaci�n de ventanas modales o no modales dentro de la misma p�gina web sin necesidad de crear nuevas p�ginas. En el caso de las ventanas no modales cualquier elemento HTML con posicionamiento absoluto pasa a ser una "ventana no modal" y la modalidad se consigue a trav�s del adecuado uso del posicionamiento absoluto, el control del z-index y la opacidad respecto a las capas ("layers") inferiores. Estas soluciones son las deseadas en un ambiente SPI.

Con un poco de esfuerzo, incluso el estado en el que se muestra una ventana modal puede ser un estado fundamental y por tanto procesable por los buscadores de p�ginas.

Un cambio cultural del programador web

La mayor�a de los programadores (y frameworks web) piensan en una web basada en p�ginas, la eliminaci�n de las p�ginas supone un cambio radical en el modo de hacer sitios y aplicaciones web. Este cambio ya no es tan radical gracias a que la popularidad de AJAX hemos reducido el n�mero de p�ginas de nuestros sitios web y en resumen nos ha acercado poco a poco a este "nuevo" modelo de programaci�n SPI.

En la nueva web SPI desparece el tag <form> y en general la necesidad de la sesi�n usada como coordinadora de datos entre secuencias de p�ginas, debido a que el protagonista pasa a ser �nicamente la p�gina cliente con alg�n tipo de simetr�a en el servidor (la p�gina en el servidor). De hecho, la eliminaci�n de la necesidad de coordinar p�ginas a trav�s de la sesi�n elimina otra fuente de problemas tal y como es la pr�ctica de algunos usuarios de abrir varias ventanas con la misma p�gina en aplicaciones web que suelen corromper la sesi�n y la aplicaci�n en general.

La forma de programar SPI es basada en eventos de forma totalmente similar a como se hace en el escritorio en donde la gran mayor�a de las aplicaciones suelen ejecutarse dentro de la misma ventana principal y cuando existen ventanas hija, �stas son plenamente controladas por la ventana principal y verdaderamente modales.

Siguiendo la evoluci�n de paradigmas de desarrollo web, podr�amos denominar Model 4 a esta "nueva" forma de construir sitios web.

Un cambio cultural del usuario?

No mucho, a trav�s del soporte de favoritos y la simulaci�n del funcionamiento de los botones Atr�s/Adelante, los usuarios finales apenas van a apreciar la diferencia entre un sitio web SPI y el mismo basado en p�ginas, es m�s lo que percibir�n es que el sitio SPI responde con mucha m�s prontitud y se eliminan los t�picos parpadeos y el "scroll" de cambio de p�gina.

Viabilidad t�cnica hoy

Este manifiesto no es una declaraci�n de intenciones sino la expresi�n de la voluntad de promover una "nueva" forma de construir sitios web que es ya real. Las consideraciones t�cnicas anteriores han tenido siempre el framework web Java ItsNat como base tecnol�gica en el desarrollo de sitios web SPI. A pesar de que ItsNat fue concebido desde el primer d�a pensando en este tipo de aplicaciones, las t�cnicas anteriormente mencionadas pueden ser desarrolladas en otros framework web, o bien dichos frameworks podr�an evolucionar hacia la posibilidad de realizaci�n de este tipo de sitios web SPI con requerimientos de simulaci�n de p�ginas.

Algunas caracter�sticas deseables de los sitios web SPI para que puedan ser substitutivos de los sitios webs tradicionales basados en p�ginas, tal y como la simulaci�n de p�ginas a trav�s de estados fundamentales en carga, s�lo son posibles en frameworks web c�ntricos en el servidor, en donde la renderizaci�n HTML se realiza en el servidor en tiempo de carga. Es la posibilidad de renderizaci�n de estados fundamentales como HTML en tiempo de carga y a la vez por inserci�n parcial a trav�s de JavaScript, las caracter�sticas clave de un framework apto para la realizaci�n de sitios web SPI. Los frameworks c�ntricos en el cliente pueden tener un papel muy relevante para la realizaci�n de los llamados estados secundarios en este documento.

Dos ejemplos reales real

La web innowhere.com/jnieasy

Est� construida con ItsNat en el servidor y es un buen ejemplo de sitio web SPI porque resume las caracter�sticas exigidas a una web SPI, de acuerdo con este documento, para poder ser substituta de forma satisfactoria de una web tradicional. De hecho la nueva versi�n SPI reemplaz� sin cambiar significativamente est�tica y funcionalidad, la versi�n anterior basada en p�ginas. Est� basada en hashbangs.

Caracter�sticas:

• Single Page Interface: los botones Atr�s y adelante son simulados cambiando al estado visitado previo o siguiente.
• Los estados fundamentales pueden ser memorizados como Favoritos (bookmarks)
• SEO compatible: los estados fundamentales son accesibles por navegaci�n por p�ginas si desactiv�ramos JavaScript en el navegador, incluso una ventana modal
• Compatible con el sistema de "AJAX URLs" de Google usando el formato #!, la p�gina puede ser tambi�n solicitada usando el par�metro _escaped_fragment_ de acuerdo con la convenci�n de Google. Por ejemplo este estado es procesado por Google solicitando este URL.
• Funciona con JavaScript desactivado.
• Muestra un banner con publicidad de Google AdSense
• A pesar de ser SPI, la navegaci�n por los estados fundamentales es monitorizado por Google Analytics a trav�s de un <iframe> oculto cuyo URL cambia indicando el estado visitado.
• Una simulada ventana modal evita crear una nueva p�gina, esta ventana tambi�n es accesible directamente a trav�s de un enlace directo o con la versi�n hashbang con texto ya serializado como HTML y por tanto el contenido es SEO compatible.

La web www.itsnat.org

Tambi�n construida con ItsNat en el servidor. En este caso se usa la JavaScript History API. Este es el m�s perfecto enfoque para convertir un sitio web conventional en un SPI SEO compatible. Si la History API no fuera soportada por un navegador concreto, se usa una navegaci�n paginada convencional autom�ticamente. Todos los navegadores modernos soportan la JavaScript History API. Las caracter�sticas SPI de este sitio web son b�sicamente las mismas que el ejemplo previo.

El Manifiesto en otras lenguas

Ingl�s

Nota: estas traducciones pueden estar ligeramente desactualizados porque este manifiesto est� vivo y puede cambiar.

Ucraniano gracias a Mario Pozner

Ruso gracias a Andrey Geonya, puede estar ligeramente desactualizado porque este manifiesto est� "vivo".

Serbo-Croata gracias a Jovana Milutinovich

Eslovaco gracias a Knowledge Team

Alem�n gracias a Valeria Aleksandrova.

Rumano gracias a Science Team.

Macedonio gracias a Katerina Nestiv

H�ngaro gracias a Elana Pavlet

Estonio gracias a Valerie Bastiaan

Enlaces al manifiesto

Noticia en JavaHispano.org

Noticia en DZone

Noticia en TheServerSide.com

Discusi�n en YCombinator.com

Autor del manifiesto: Jose Mar�a Arranz Santamar�a