Me mudo

Este blog no recibirá ya más actualizaciones. Ve al nuevo blog enricflorit.com o averigua por qué me mudo.

miércoles, 17 de octubre de 2012

Detección del navegador vs. detección del soporte

Un problema que se han planteando los desarrolladores web desde que la web existe es la compatibilidad con navegadores. Hablo del código para JavaScript, donde en ocasiones podemos llegar a multiplicar el código necesario para cualquier aplicación por dos o tres. Por suerte, la mayoría de problemas más básicos se están solucionando al introducir nuevas versiones en los navegadores. O tal vez no?
Algo de historia
Antaño, los desarrolladores web (en aquellos tiempos, “webmasters”) tenían que preocuparse por dos plataformas: Internet Explorer y Netscape Navigator. Pero era algo casi normal, y tenías tres opciones:
  • Soportar ambos navegadores
  • Soportar uno de los dos. El que te hiciera menos rabia, el que te gustara más o el preferido por tus visitantes.
  • No soportar ninguno de los dos. Las webs no tenían tantas necesidades multimedia como hoy, y la mayoría de efectos JS solían ser puras chorradas.
Pero claro, con el tiempo fueron llegando más necesidades, más soluciones... y los navegadores modernos. Es decir, la popularización de los navegadores modernos. Navegadores que respetaban los estándares (todavía a medias, pero empezaba a existir esa idea). Y algunos de los webmasters empezaron a ver que era mucho mejor adaptar sus aplicaciones para estos navegadores e Internet Explorer.
La gran pérdida de tiempo
Como IE lo hacía todo al revés, era sencillo diferenciar entre el código moderno y el antiguo. Bastaba detectar el navegador, y se popularizaron el uso de scripts cortos como /*@cc_on!@*/false o '\v'=='v', basándose en errores del motor de JavaScript de IE.
Pero poco a poco, sucedió que las versiones nuevas de IE (que no modernas) empezaron lentamente a soportar formas estándar y de acuerdo con los navegadores modernos. Problemas? Sí, muchos. Se fueron cambiando los métodos de trabajo, y era asunto del desarrollador meterse en problemas de cómo se soluciona cada caso en cada navegador.
Una solución parcial: las bibliotecas JavaScript
Con la llegada de bibliotecas como jQuery, Mootools, etc., el problema de la compatibilidad parecía que se arreglaba por completo. Está demostrado que no es así, pero se acortó sustancialmente el tiempo de mejoras de compatibilidad en una web.
Así que, ¿porqué nos seguimos complicando la vida? ¿No tenemos suficientes herramientas con estas bibliotecas, como para que aún queramos más? La respuesta es no, y tiene explicación en algo de lo que se habla mucho en estos tiempos: HTML5.
La llegada de HTML5, un quebradero de cabeza (otro más)
HTML5 mola, ya lo he dicho alguna que otra vez. Pero como todo lo nuevo, tardará un tiempo en ser aceptado por todos los navegadores. Algunos puede que no lo lleguen a soportar nunca, pero qué le haremos. Hay un montón de cosas nuevas: etiquetas semánticas, vídeo y audio nativos, canvas, svg, nuevas API de JavaScript, nuevo código CSS...
Parece ser que vuelven los problemas... Que si este navegador soporta esto, que si no lo soporta... Ha llegado el momento de ser más selectivos, escribir nuestro código en función del soporte de una característica y no del navegador y/o su versión (como hacíamos con Internet Explorer). Pero cómo lo hacemos?
Sencillamente, con bibliotecas de test. Modernizr es una muy famosa y que se ha sabido desenvolver bien, es pequeña y sencilla. Además es modular, así que podemos compilar nuestra propia versión desde la web para que solo haga lo que necesitamos. Os recomiendo que la descarguéis para probarla: http://www.modernizr.com/
Para acabar, parece que tenemos solucionado el tema de la compatibilidad, con algunos baches (de escribir varias versiones del código no nos libramos), pero lo que sí que nos es útil es el uso de bibliotecas.
Aún así, creéis que hay algún asunto pendiente en el tema de la compatibilidad? Cuál?
Un saludo! ;-)

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...