Steve Jobs, ante su negativa de usar Flash de Adobe en el iPad, indicó que se iban por el camino de HTML5. La cuestión es si los argumentos de Jobs sobre Flash y HTML5 son técnicos o son simplemente pretextos por un pleito personal que tiene con los creadores de Photoshop, Illustrator, Flash y otros programas. Pero juzgue usted mismo:
Verdad #1: La seguridad es una pesadilla.
El problema fundamental con el cómputo del lado del cliente es que el usuario tiene finalmente el control sobre el código que corre en su máquina. En el caso de las aplicaciones Web, con un depurador avanzado, es posible abusar del código. Con depuradores como Firebug, cualquiera que quiera curiosear con facebook, Google, o cualquier sitio web, puede hacerlo insertando “breakpoints” y entonces analizar el código. Es una muy buena manera de aprender, pero es una pesadilla en términos de seguridad.
Supongamos que hay una variable a la cual usted le quiere cambiar el valor. Firebug permite eso y entonces podríamos hacerle “pensar” al sitio web que estamos en alguna parte diferente del planeta. Es fácil editar las variables que muestran la latitud y longitud, por ejemplo. Pero cualquier variable puede ser modificada.
Por supuesto hay límites a los problemas de seguridad que pueden ocurrir. Algunas herramientas para Javascript, como Google Web Toolkit generan código que es tan complicado como el de cualquier compilador estándar. Sin embargo, hay herramientas, como el Javascript Deminifier nos pueden ayudar a desentrañar el código. Los peligros dependen de la naturaleza de la aplicación. Cambiar las coordenadas geográficas puede ser hasta divertido, pero si en algún sitio web le da al que cambia una variable todos los permisos sobre un usuario, entonces la cuestión se complica.
Lo que todo esto significa es que las aplicaciones HTML5 no pueden ser muy confiables cuando se trabaja con recolección de datos. Hay que estar al tanto de esto.
Verdad #2: El almacenamiento local está limitado
Las bases de datos locales pueden ser una manera simple para que las aplicaciones web tomen los datos de la computadora del cliente, pero cualquiera que pida mayor funcionalidad en este aspecto, tendrá dificultades. Las capacidades de almacenamiento de HTML5 son un importante agregado al sistema, pero no se puede mover los datos guardados a otras máquinas, hacer respaldos o abrirlos con otras aplicaciones.
Así, se tiene lo peor de los dos mundos: toda la responsabilidad de hospedar los datos pero sin el control de ellos. Algunos navegadores, como Safari, permiten ver qué bases de datos fueron creadas en la computadora del usuario, pero la información es limitada. Incluso en Safari se pueden borrar las bases de datos creadas, pero no se puede mover la información.
Y desde luego, no faltará el programador que analice cómo se crearon los datos de una aplicación particular. El punto aquí es que no hay información creada en HTML5 que sea fácil de abrir en un editor de textos genérico u hoja de cálculo.
Verdad #3: Los datos locales pueden ser manipulados
El usuario puede no tener control de los datos, pero el sitio que los creó sí y entonces hay un peligro de que estos sean manipulados. Los desarrolladores de sitios web necesitan preocuparse por la seguridad de los datos en las bases locales. Aún no hay herramientas para editar fácilmente dichos datos y actualizar los privilegios y no hay manera de que el sistema que los creó lo prevenga. Todos los agujeros de seguridad en javascript afectan a las bases de datos. Basta con un vivales que busque escribir un script o código nativo para cambiar los datos y habrá problemas.
Verdad #4: las aplicaciones fuera de línea son una pesadilla para sincronizar.
El almacenamiento de los datos locales se mejora con la habilidad de usar aplicaciones web fuera de línea. La sincronización de datos es el problema.
Si la app web está conectada a internet, puede salvar los datos contínuamente en la nube. Cuando se está fuera de línea, los datos no son salvados en la nube. Cuando alguien cambia de navegador o usa una máquina diferente, empiezan a generarse copias de los datos y entonces vienen los problemas de la sincronización.
Cabe decir que siempre han habido problemas con las aplicaciones nativas, pero la diferencia es que el modelo nativo hace obvio quién es el responsable de la sincronización: los humanos, quienes manejan los problemas de sincronización viendo los nombres de archivos y cambiando las fechas. Pero como HTML5 no le da control al usuario sobre las bases de datos creadas, los desarrolladores deben dar una interfaz al usuario para manejar la sincronización. La especificación no ofrece ninguna ayuda en este sentido.
Esto no es totalmente intratable. Los programadores manejan estos dolores de cabeza usando sistemas de control de versiones, los cuales se han vuelto cada vez más sofisticados para manejar tales problemas. Los desarrolladores de HTML5 tendrán que aprender de estas problemáticas para poder manejar la sincronización de las apps web HTML5.
Verdad #5: La nube no te debe nada.
No hay que satanizar tampoco a HTML5 por todos los problemas estructurales cuando se guardan datos en la nube, pero ésta es una parte esencial de la nueva visión en donde en la nube se eliminarán las dificultades de instalar software y respaldar datos.
Dadas las limitaciones actuales de HTML5 en lo que se refiere a las bases de datos locales, el núcleo del almacenamiento de datos de una aplicación web estará en manos de los servidores, y hay momentos en donde este enfoque puede ser devastador. Sólo como ejemplo, Facebook decidió que no usaría un plug-in de Linux para permitir subir fotos. Gracias a esta decisión, el plug-in desapareció, con todas las fotos que se subieron con el mismo.
Estas historias no son comunes, pero están apareciendo con más frecuencia cada vez por muchas razones. Los términos de servicios de muchas apps web hacen explícito que los datos no son tuyos y en la mayoría de los casos no tienes argumentos legales para recobrarlos. Muchos servicios en Internet aclaran que los datos pueden borrarse “sin dar razón alguna“.
No solamente HTML5 no piensa en arreglar esta dificultad, pues su estructura asegura que cualquier dato local del navegador del usuario será guardado en la nube, fuera de su alcance y control. Según HTML5 esto es una característica, no un bug, pero puede tornarse fácilmente en su contra.
Verdad #6: Las actualizaciones forzadas no son para todos.
Cuando una compañía de aplicaciones web necesita actualizar sus sistemas, tiene que actualizar a todos al mismo tiempo. Y aunque esto se supone, le quita la responsabilidad a los usuarios de manejar las instalaciones de software, puede ser una pesadilla para aquel que por alguna razón no quiere las nuevas características en la versión nueva. Y esto no sólo es un problema de privacidad, sino de la problemática común en donde las nuevas versiones fallan o tienen bugs y conflictos con las versiones anteriores, cosa que pasa.
Verdad #7: Los trabajadores de la web no ofrecen prioritización
Los trabajadores web (web workers), son uno de los añadidos más intrigantes a HTML5. En lugar de usar a los scripts de javascript wait, delay y pause, los desarrolladores web pueden ahora dividir el código y segregarlo para que lo usen los trabajadores web. Esto es una forma rudimentaria de paralelización, asunto que en general lo usan los sistemas operativos y no las aplicaciones (aunque no veo lo malo en esto).
Y aunque no duplica todas las características de todo el sistema operativo, da la opción de dividir el trabajo, separarlo, aunque no hay forma que el usuario decida las prioridades. El API solamente permite mensajes para ser pasados de y hacia los objetos del trabajador. Eso es todo. El navegador maneja el resto.
En otras palabras, no hay manera de ver la creación del trabajador web o de trazar lo que está haciendo. Esto puede ser usado por el malware cuando se entienda cómo hacerlo, cosa que no se ve remota.
Verdad #8: Hay incompatibilidades de formato
HTML5 crea las etiquetas <audio> y <video>. Supuestamente basta con ponerlo en el código y listo, se hace streaming del video o del audio. El problema es que si es tan fácil, ¿por qué no se puede hacer que funcione en todos los navegadores en existencia?
Por supuesto que esto no es responsabilidad de HTML5 sino de los creadores de cada navegador, los cuales deciden qué implementan y qué no, dada la referencia de HTML5. Los desarrolladores del API incluyeron la función canPlayType, pero esta función no la soportan todos los navegadores.
Verdad #9: las implementaciones dependen del navegador.
La versión idílica de HTML5 es una cosa y otra la triste realidad de las diferentes implementaciones. Así, un navegador puede o no aceptar algún tag. En algunos casos podrá ser un simple problema menor. En otros puede hacer inservible una aplicación con HTML5.
Verdad #10. La idiosincracia del hardware lleva a nuevos retos.
Parece injusto quejarse sobre cómo los creadores de los navegadores web van más allá del deber para dar un mejor desempeño, pero la falta de éste queda sin ser castigada. Como el dueño de un nuevo Ferrari, que encuentra de pronto su coche contra un poste de luz, en donde a veces poder extra no siempre es una bendición.
Los programadores deben prestar atención a qué características adicionales son las que ya están funcionando, y además, no es claro cómo van a darse cuenta de qué tan rápido corre su código.
Verdad #11: Política, como siempre.
Algunos llaman a Ian Hickson, el principal borrador del estándar de HTML5, el Dictador Supremo de la Vida. Están bromeando, supongo. El escritor hace al final de cuentas sugerencias, pero los genios que escriben el código para las companías que hacen navegadores son las que toman al final la decisión de implementar o no alguna característica. Después de un par de años, el estándar es frecuentemente cambiado para que sea igual a la implementación.
El problema es que por un lado queremos libertad, innovación, etc, pero por otra, queremos la estabilidad que da una referencia planteada por “el dictador“. Sin embargo, como pudo haber dicho Winston Churchill: “Se ha dicho que la democracia es la peor forma de gobierno, excepto por todas las otras formas de gobierno que han sido intentadas de tiempo en tiempo“.
Fuente: InfoWorld