La compatibilidad puesta en duda
Los desarrolladores deben tener claro desde el principio que a pesar de la supuesta compatibilidad entre navegadores, JavaScript es interpretado de modo diferente según sea el navegador utilizado. Es cierto que con el paso del tiempo el nivel de compatibilidad es cada vez mayor, especialmente si se compara con la situación existente hace ocho o diez años. En esos primeros años de JavaScript era necesario crear código específico casi para cada uno de los navegadores principales para poder obtener resultados equivalentes. Esto generaba una carga de trabajo multiplicada por dos o por tres y aún así la interfaz de usuario no se comportaba de la misma manera en los diferentes navegadores.
Para estar seguros que nuestro código JavaScript es correcto en todos los entornos debemos realizar pruebas completas en todos los navegadores principales. Hay muchas funciones JavaScript que son exclusivas de un navegador determinado.
¿Qué navegador hay que tener en cuenta? La respuesta a esta pregunta nos la dan las encuestas que se realizan continuamente sobre el tema, así como también podemos conocer qué sistemas operativos se están utilizando más, qué tamaños de pantalla, qué resolución y qué velocidad de conexión utilizan los navegantes de Internet.
Como desarrolladores debemos saber qué parte del mercado queda fuera de nuestro alcance cuando decidimos una configuración determinada de nuestro código.
Al haber muchas estadísticas de uso de navegadores tenemos casi tantos resultados como encuestas pero, aproximadamente y sin ánimo de crear polémicas, se puede estimar que el mercado actual (a marzo/2014) se reparte de la siguiente manera:
- Internet Explorer 22%
- Firefox 20%
- Safari 10%
- Chrome 45%
- Resto 3% (Opera, Maxthon, etc.)
Pero nuestro drama como desarrolladores no acaba sabiendo en qué tipo de navegador se ejecuta nuestro código: no sólo debemos tener en cuenta eso sino a qué versiones de navegador, dado que, por ejemplo, JavaScript se comporta diferente en IE 8 e IE 10 y también es importante saber que un navegador no actúa igual en un equipo Windows (85 % del mercado) que en un equipo Macintosh (9% del mercado) o Linux (3% del mercado). En definitiva, la tarea de pruebas de un desarrollo web debe ser valorada en su justa manera y asignarle el tiempo necesario ya que las combinaciones de navegadores, versiones y sistemas operativos dan como resultado docenas de entornos diferentes.
Una decisión estratégica
Si nuestro sitio web se va a utilizar en una intranet de una empresa o una institución en la que conocemos perfectamente la configuración de los equipos que la componen, que además suelen ser similares, este problema se reduce de manera sustancial; quizá todos los equipos de los usuarios sean Windows 7 con IE 9 o superior, por lo tanto un sólo tipo de prueba nos alcanzará para dar por correcta una página determinada. En cambio, si nuestro sitio web es de uso abierto a Internet nuestra ecuación cambia radicalmente y tendremos que tomar decisiones estratégicas para que las pruebas no sean interminables.
Una decisión estratégica
Somos conscientes que es imposible probar nuestro código en docenas de configuraciones. Sólo una aplicación del tipo de Amazon se puede dar ese lujo. Por lo tanto debemos averiguar cuáles son actualmente los entornos más utilizados y centrar nuestras pruebas en esas configuraciones. Por ejemplo, actualmente Chrome 36, IE 11 y Firefox 30 abarcan gran parte del mercado seguidos de lejos por Safari y Opera, si nos centramos en estos navegadores estaremos reduciendo significativamente la cantidad de pruebas (y las correspondientes adaptaciones de código), sabiendo que habrá cosas que quizá no funcionarán, por ejemplo, en IE 8.
|
|
|
