Hoy en día escu­chas a menudo que HTML5 es la solu­ción para todo. Que con­vierte las webs en apps para tableta, per­mite a tu sobrino mon­tar el nuevo **Tube, rellena la decla­ra­ción de la renta y cocina deli­cio­sas tor­ti­llas de pata­tas. Lo que poca gente sabe es que, en reali­dad, el Hyper­Text Mar­kup Lan­guage está acabado.

La web empezó como una serie de con­te­ni­dos en pági­nas está­ti­cas conec­ta­das por enla­ces. Cada página era un docu­mento com­pleto y la inter­ac­ción se limi­taba a seguir los enla­ces para obte­ner otros docu­men­tos. En ese con­texto se desa­rro­lló el HTML como forma de estruc­tu­rar el contenido.

Con el tiempo las webs cre­cie­ron en tamaño y crear pági­nas está­ti­cas se vol­vió imprác­tico, de modo que se gene­ra­lizó el uso de scripts de ser­vi­dor para gene­rar­las bajo demanda. Las ter­mi­na­les de los usua­rios eran mucho menos poten­tes que el ser­vi­dor, por lo que todo el pro­ceso se hacía antes de ser­vir la página está­tica. Nor­mal­mente, ese pro­ceso con­sis­tía en unir varios frag­men­tos de HTML y relle­nar la plan­ti­lla con los con­te­ni­dos ade­cua­dos. De cara a la web, y a los bus­ca­do­res, la página gene­rada seguía siendo un docu­mento individual.

Poco a poco algu­nas par­tes de la web se hicie­ron más diná­mi­cas gra­cias al código JavaS­cript, que se eje­cuta en el lado del nave­ga­dor y no en el del ser­vi­dor. Al prin­ci­pio el len­guaje no era están­dar (Inter­net Explo­rer y Nets­cape usa­ban varian­tes dife­ren­tes), era lento (hasta que Goo­gle empezó a demos­trar la impor­tan­cia de eje­cu­tar JavaS­cript con efi­cien­cia), y los orde­na­do­res en los que se tenía que eje­cu­tar tenían menos poten­cia que un móvil actual.

En JavaS­cript, los con­te­ni­dos de una página se codi­fi­can según el Docu­ment Object Model. El DOM es un esquema en el que cada rama da acceso a su con­te­nido o las pro­pie­da­des de ese con­te­nido, inclui­dos los esti­los CSS. Los datos en el esquema DOM se pue­den con­ver­tir en un docu­mento HTML, XHTML o XML envol­viendo los datos en las eti­que­tas correspondientes.

En los últi­mos años, muchas pági­nas y apli­ca­cio­nes han empe­zado a salirse del para­digma del docu­mento indi­vi­dual usando un método par­ti­cu­lar de JavaS­cript (cono­cido como AJAX en su forma ini­cial, Web­So­ckets en una imple­men­ta­ción más reciente) que, sin nece­si­dad de car­gar un docu­mento nuevo, per­mite soli­ci­tar al ser­vi­dor paque­tes de datos para modi­fi­car la página que esta viendo el usuario.

Por moti­vos prác­ti­cos, muchas de esas trans­fe­ren­cias de datos no se hacen en forma de HTML. En el for­mato JSON, los datos se trans­fie­ren en un esquema anidado de líneas “clave” = “valor”. En XML se trans­fie­ren como <clave atributo1=“valor” atributo2=“valor”>contenido</clave>. En CSV se usan sim­ples líneas de valo­res sepa­ra­dos por comas.

Cuando el código JavaS­cript recibe esos datos, modi­fica el DOM del docu­mento actual. El DOM es leído direc­ta­mente por el nave­ga­dor, que pro­cede a actua­li­zar la página. En nin­gún punto del pro­ceso se uti­liza HTML. Sólo si el usua­rio le pide al nave­ga­dor que mues­tre el “código fuente” el nave­ga­dor pone los datos del DOM entre eti­que­tas HTML, XHTML o XML y los pre­senta de esa forma.

Por tra­di­ción, toda­vía es común que el ser­vi­dor copie o genere el docu­mento HTML a par­tir de una base de datos y lo envíe entero al nave­ga­dor (lo que aumenta el tamaño). El nave­ga­dor des­com­pone ese HTML para tra­du­cirlo al DOM, que es cómo el nave­ga­dor y JavaS­cript ven el docu­mento. El resul­tado es que dos máqui­nas ter­mi­nan comu­ni­cán­dose con datos for­ma­tea­dos para que los lean huma­nos, pese a que nin­gún humano nece­sita leerlos.

Las mejo­ras en los nave­ga­do­res han hecho que las cone­xio­nes y la velo­ci­dad y coste de trans­mi­sión sean el nuevo cue­llo de bote­lla. Si pides un docu­mento entero con cada acción, el ser­vi­dor tiene que trans­mi­tir par­tes redun­dan­tes, con las eti­que­tas HTML ya gene­ra­das, o infor­mar al nave­ga­dor de que algu­nos ele­men­tos no han cam­biado. Por otro lado, las gran­jas de ser­vi­do­res nece­si­tan ser efi­cien­tes y hoy es nor­mal que el ser­vi­dor sea mucho menos potente que el PC del usuario.

Lo que algu­nos desa­rro­lla­do­res se están plan­teando ahora es qué nece­si­dad hay de trans­mi­tir los datos envuel­tos en eti­que­tas y embu­ti­dos en docu­men­tos, cuando bas­ta­ría enviarle una sola vez al cliente un script que se encar­gue de comu­ni­carse con el ser­vi­dor, reci­bir los nue­vos datos “pela­dos” y actua­li­zar el DOM. La única situa­ción en la que un Len­guaje de Mar­cado de Hiper­Texto sería nece­sa­rio es cuando se guarde una cap­tura está­tica del con­te­nido en un for­mato legi­ble por huma­nos. Aun­que los usua­rios no se den cuenta, la mayor parte de esas copias se hacen ahora en XML (el mismo for­mato de mar­cado que se usa en los feeds o en el inte­rior de los docu­men­tos de Office ―en ver­sio­nes recien­tes― y OpenOffice).

En el sen­tido de qué habi­li­da­des se pedi­rán de la gente que tenga que crear pági­nas web, “saber HTML” pronto no sig­ni­fi­cará nada. O bien nos limi­ta­re­mos a intro­du­cir datos para que una plan­ti­lla JavaS­cript los pre­sente en forma de apli­ca­ción web, o ten­dre­mos que saber crear esas plan­ti­llas JavaS­cript y los scripts de ser­vi­dor nece­sa­rios para comu­ni­carse con ellas usando for­ma­tos de datos JSON, XML, CSV, etc. Las pági­nas estruc­tu­ra­das con HTML esta­rán obso­le­tas y los docu­men­tos está­ti­cos se guar­da­rán como XML, para ser pre­sen­ta­dos con la apli­ca­ción que le con­venga al usuario.