Últimamente leo bastante la página del w3c (Qué acierto fue cambiar su diseño), y casi siempre me veo a mí mismo leyendo sobre el Grupo de Trabajo de Aplicaciones Web (WebApps Working Group). ¿Qué es?
“El W3C Web Applications (WebApps) Working Group, una fusión de los grupos de trabajoWebAPI y WAF, se constituye para desarollar APIs estándar para el desarrollo de Aplicaciones Web del lado del cliente. Este trabajo incluirá tanto la documentación de APIs existentes como el XMLHttpRequest, como el desarrollo de nuevas APIs que enriquezcan las aplicaciones web.”
Veamos en qué consisten algunas de esas APIs que están desarrollando:
Cada widget podrá tener un documento de configuración que almacenará metadatos relativos al Widget. Además, cada instancia de un widget podrá almacenar datos de manera persistente. ¿Cómo se hará esto? Gracias a otra API de almacenamiento de datos locales.
Está bastante maduro (En estado de Recomendación Candidata), y existe una suite de tests para probar su correcta implementación.
Supongamos el siguiente bloque de código HTML 4.01:
<table id="score">
<thead>
<tr>
<th>Test
<th>Result
<tfoot>
<tr>
<th>Average
<td>82%
<tbody>
<tr>
<td>A
<td>87%
<tr>
<td>B
<td>78%
<tr>
<td>C
<td>81%
</table>
Si quisiéramos obtener los valores de todas las celdas tendríamos que ejecutar algo similar a esto con la API de DOM Level 2:
var table = document.getElementById("score");
var groups = table.tBodies;
var rows = null;
var cells = [];
for (var i = 0; i < groups.length; i++) {
rows = groups[i].rows;
for (var j = 0; j < rows.length; j++) {
cells.push(rows[j].cells[1]);
}
}
¡Qué feo! La nueva API permite hacerlo de este modo mucho más conciso:
var cells = document.querySelectorAll("#score>tbody>tr>td:nth-of-type(2)");
Como véis, es exactamente igual que lo que ya hacemos con los selectores de jQuery, salvo que en un tiempo podremos realizarlo directamente desde el motor de JavaScript del navegador, sin necesidad de frameworks.
Esta API también está muy madura, y al igual que la anterior es una Recomendación Candidata. Está disponible en Firefox desde su versión 3.1+, en Internet Explorer 8 y en Safari 3.1+. Pero hasta que no borremos del mapa a IE6 e IE7 tendremos que seguir utilizando herramientas como jQuery.
Es un nuevo mecanismo de almacenamiento local que, a diferencia de las Cookies, permite almacenar un gran volumen de datos (Por ejemplo, los emails de una cuenta, haciendo innecesario plugins como Google Gears), y también permite almacenarlo accesible a todas las ventanas del dominio al que pertenecen.
Todo se realizaría de un modo muy sencillo: Simplemente accediendo al atributo que proceda dentro del objeto localStorage.
De nuevo, está disponible ya en Firefox 3.5, IE8, Safari 4.0, Chromium…
Permite lanzar distintos hilos de ejecución que se ejecutan en paralelo a la página principal. De este modo, se puede trabjar en un entorno thread-like trabajando con un mecanismo de coordinación de pase de mensajes.
Como ejemplos, podríamos:
- Generar una hebra que busque números primos en background.
- Un worker que actualice una base de datos local. Estaría permanentemente escuchando al servidor mediante un WebSocket, y cuando hubiera algún cambio, modificaría la base de datos local.
- Operaciones de Lectura/Escritura de fondo.
- Workers compartido. Distintas ventanas podría compartir un único Worker que, en un momento dado, podría actualizar a todas a la vez.
- Delegación. Aprovechando las distintas CPUs de los microprocesadores multi-core.
Lógicamente, esto abre un gran número de posibilidades en cuanto al rendimiento de las páginas web.
Por el momento disponible en Firefox 3.5+, Safari 4, Chromium.
La API que define esta especificación puede no parecer muy revolucionaria: Permite recivir notificaciones PUSH desde el servidor en forma de evento DOM. Perfectamente podemos lograr el mismo objetivo mediante XHR o un iframe. Sin embargo, dada su naturaleza, permitiria que, cuando el navegador se pueda coordinar con el operador de red, se ahorraran notablemente recursos de red. Uno de los efectos colaterales sería aumentar la duración de las baterías de los dispositivos portátiles.
Esta API permite una auténtica conexión bidireccional entre el navegador y el servidor. Ya fue cubierta en este blog cuando Google Chrome anunció su implementación.
Es exactamente lo que su nombre sugiere. Consiste en una especificación de un API que permitirá almacenar información en una base de datos locale accesible mediante SQL.
Veamos un ejemplo de su funcionamiento:
function prepareDatabase(ready, error) {
return openDatabase('documents', '1.0', 'Offline document storage', 5*1024*1024, function (db) {
db.changeVersion('', '1.0', function (t) {
t.executeSql('CREATE TABLE docids (id, name)');
}, error);
});
}
function showDocCount(db, span) {
db.readTransaction(function (t) {
t.executeSql('SELECT COUNT(*) AS c FROM docids', [], function (t, r) {
span.textContent = r.rows[0].c;
}, function (t, e) {
// couldn't read database
span.textContent = '(unknown: ' + e.message + ')';
});
});
}
prepareDatabase(function(db) {
// got database
var span = document.getElementById('doc-count');
showDocCount(db, span);
}, function (e) {
// error getting database
alert(e.message);
});
En primer lugar se define la función prepareDatabase() que, en caso de que fuera necesario, crea la base de datos con una tabla llamada “docids” con dos columnas (“id” y “name”). Si hay éxito, o no es necesario crearla, se llama a la función getDatabase(), que obtiene un manejador de la base de datos, y entonces llama a la función que hace realmente el trabajo, en este caso showDocCount().
Como último ejemplo de apartados en los que trabaja el WebApps Working Group, voy a mosotrar la File API. Permitirá un manejo avanzado de ficheros desde JavaScript, pudiendo:
- Una vez que el usuario conceda permisos, el navegador permitirá leer y parsear un fichero.
- Se podrá almacenar información de forma local.
- Se permitirá guardar los archivos, del mismo modo que ahora se pueden descargar ficheros de servidores remotos.
- Se podrán enviar ficheros grandes a servidores de un modo más eficiente que el actual. Por ejemplo, se podrá dividir en porciones.
- Los navegadores implementarán mecanismos para poder cancelar o impedir los casos de uso enumerados anteriormente.
Sin duda, APIs como éstas permitirán realizar aplicaciones reales que funcionen en el navegador sin necesidad de un servidor. Como ejemplo, un reproductor multimedia avanzado, que guarde una caché local con metadatos de nuestra música y películas.
Creo que muy pronto comenzaremos a ver todas estas nuevas aplicaciones ir aparenciendo, poco a poco, hasta que un día el navegador realmente sea un framework de aplicaciones más.
