El legado de Internet Explorer 6 sigue siendo una pesadilla para los desarrolladores web. El navegador de Microsoft de antaño les hizo la vida imposible y sólo es ligeramente hiperbólico decir que casi destruyó todo Internet. Era realmente tan malo, señores.
Hoy en día, los desarrolladores que quieren utilizar las API web «de vanguardia» se encuentran recurriendo al mismo tipo de soluciones específicas para el navegador, pero esta vez el navegador que arrastra las cosas viene de Apple.
Safari, se queda considerablemente atrás con respecto a sus pares en el soporte de las funciones web. Si está lo suficientemente atrasado como para ser considerado «el nuevo IE» es discutible y puede decir más sobre la sombra que IE todavía proyecta en la web. Pero Safari -o más concretamente el motor WebKit que lo impulsa- está muy por detrás de la competencia. Según el panel de pruebas de la plataforma web, los navegadores basados en Chrome soportan el 94% del conjunto de pruebas, Firefox consigue el 91%, pero Safari solo consigue el 71%.
En los ordenadores de sobremesa esto no importa demasiado porque los usuarios siempre pueden cambiar de navegador. En los dispositivos iOS, sin embargo, eso no es posible. Según las normas de la App Store de Apple «las aplicaciones que navegan por la web deben utilizar el marco WebKit y el Javascript WebKit adecuados». Todos los usuarios de iPhone son usuarios de Safari/WebKit, tanto si utilizan Safari como Chrome.
Apple tiene el monopolio de los navegadores en iOS, algo que Microsoft nunca pudo conseguir con IE. En Windows al menos podrías instalar Firefox. Si lo haces en iOS puede que diga Firefox, pero sigues usando WebKit. La realidad es que si tienes un dispositivo iOS, usas Safari y estás atado a sus limitaciones.
Otra cosa que los desarrolladores web encuentran agobiante, es el lento ciclo de desarrollo de Apple. Apple actualiza Safari aproximadamente cada seis meses en el mejor de los casos. Los navegadores basados en Blink se actualizan cada seis semanas (pronto cada cuatro), Firefox lo hace cada cuatro semanas y Brave cada tres. Esto significa que Apple no sólo tarda en añadir nuevas funciones, sino que su ciclo de desarrollo implica que incluso las correcciones de errores simples tienen que esperar mucho tiempo antes de llegar a los dispositivos de los usuarios. Las soluciones de Safari no son soluciones rápidas. Si tu sitio web se ve afectado por un error de Safari, puedes esperar hasta un año antes de que se resuelva el problema.
Un tema que surge cuando se indaga en los datos de las Web Platform Tests sobre las deficiencias de Safari es que incluso cuando WebKit ha implementado una función, a menudo no está completa. Tomemos el caso de las aplicaciones web progresivas (PWA). Las aplicaciones web progresivas son un término que engloba a los sitios web que quieren comportarse como aplicaciones móviles nativas. Algunas de las APIs utilizadas para construir PWAs incluyen la capacidad de ejecutarse a pantalla completa (sin interfaz de usuario del navegador), enviar notificaciones y alertas, capacidades offline y lanzarse desde un icono en la pantalla de inicio. Probablemente los dos ejemplos más conocidos de PWA son Twitter y Uber.
Apple ha implementado gran parte de lo que los desarrolladores necesitan para construir PWAs, pero hay limitaciones. Apple no ha añadido soporte para el envío de notificaciones e iconos en la pantalla de inicio. En esencia, Apple no ha implementado algunas de las características principales que hacen que los sitios web puedan comportarse de manera similar a las aplicaciones.
Este ha sido durante mucho tiempo el núcleo del argumento de que Apple está paralizando deliberadamente WebKit para proteger su negocio de la App Store. En otras palabras, si Apple implementa estas cosas, los desarrolladores empezarán a crear mejores aplicaciones web, nadie comprará aplicaciones nativas y Apple perderá su 30% de la App Store de iOS.
Esto puede tener sentido para los desarrolladores web, que están profundamente apasionados por la construcción de aplicaciones web, pero no tiene mucho sentido fuera de ese contexto. Apple es una de las empresas más ricas del mundo, y probablemente no le preocupe demasiado lo que los desarrolladores web vayan a hacer con todas esas fantásticas nuevas API que no soporta. Sin duda, Apple está protegiendo sus intereses, pero al menos ahora mismo eso parece estar más relacionado con el movimiento de Apple para posicionarse como protector de la privacidad de los usuarios que con la preocupación por las aplicaciones web.
Los defensores de Safari, y la propia Apple, argumentan que la compañía no está implementando todas estas nuevas APIs porque dejar que los desarrolladores tengan acceso a tus puertos USB, Bluetooth, estado de la batería y sensor de proximidad permitiría a los anunciantes crear «huellas dactilares» del dispositivo que erosionan aún más la privacidad, por no hablar del impacto en la vida de la batería.
No tengo ningún dispositivo iOS pero, sinceramente, la postura de Apple en este caso casi me hace desear uno.
Probablemente debería admitir ahora que odio la web moderna. No me preocupa tanto porque tener un dispositivo móvil y tener privacidad son mutuamente excluyentes. No me gusta la privacidad, pero encuentro la experiencia de los sitios web modernos tan poco fiable, lenta y, en general, hostil al usuario, que prefiero hacer literalmente cualquier otra cosa.
Me desagradan tanto las experiencias que permiten las APIs web basadas en JavaScript que he optado por navegar con JavaScript desactivado. Esto devuelve a la web una hermosa y limpia simplicidad que probablemente haría feliz a Apple. Los sitios que se cargan sin JavaScript los leo – los sitios que no lo hacen no me molestan. Sí, hablo en serio. Si Invidious puede cargar el contenido de YouTube sin JavaScript, ¿por qué no puede hacerlo YouTube? No lo sé y no me importa. Escribí un script para asegurarme de que siempre me redireccionen a Invidious (PeerTube es una mejor alternativa) pero divago.
Lo que quiero decir es que quiero apoyar a Apple en esto, pero desgraciadamente creo que el argumento de que Apple está frenando a Safari para proteger la privacidad de los usuarios es débil. Aunque no creo que a Apple le preocupe tanto que los desarrolladores web perjudiquen los beneficios de su App Store, tampoco creo que la empresa sea lo suficientemente grande como para ignorar la web por completo y no sufrir las consecuencias. Es decir, Apple puede creer que está actuando para proteger la privacidad de los usuarios, pero no funcionará.
El hecho de no haber implementado estas API no ha impedido que se adopten en todos los demás navegadores. Llevará un tiempo, pero ya sabemos cómo acaba esta historia. Termina como terminó para Internet Explorer: Microsoft perdió. Todos los demás siguieron adelante y finalmente Microsoft fue la empresa con el producto que nadie quería. Si Apple sigue ese camino, no sólo perderá Apple, sino también la web. Porque los defensores de Apple tienen razón en una cosa: si Apple no se enfrenta al gigante Blink de Google, no parece que nadie más lo haga.
¿Qué aspecto tiene ese monstruo? El desarrollador web Tim Perry señaló hace poco que hace tiempo todos los navegadores ofrecían sus propias API de complementos. Pero, como escribe Perry, «Chrome dominó de forma efectiva el mindshare de los desarrolladores, proporcionó unas API de extensiones más potentes y fáciles de usar que se hicieron mucho más populares, y tanto Firefox como Safari… eliminaron sus propias API y aceptaron las de Chrome, permitiendo involuntariamente que Google estableciera unilateralmente el estándar de las extensiones web». Esto es lo que ocurre cuando no hay nadie que se oponga al líder del mercado.
Ahora está ocurriendo lo mismo con las herramientas de desarrollo y las API. «Chrome sigue el mismo camino hoy en día», escribe Perry, «ofreciendo a los desarrolladores web herramientas más potentes y una mejor experiencia de desarrollo (mejores herramientas de desarrollo, menos errores) que Safari. Si nada cambia, es probable que el resultado sea similar. Esto es malo».
Lo que la web necesita es que alguien ponga freno a Google y a Blink y se asegure de que las API que se crean son buenas para los usuarios de la web. No sólo para los usuarios de Google. No sólo para los usuarios de Apple. No sólo para los desarrolladores web. Son buenas para todos.
Gran parte del desarrollo de características web modernas se produce en silencio y con muy poco debate. Los desarrolladores de Blink proponen características enviándolas en Chrome detrás de una bandera de desarrollador. En ese momento ya hay una implementación que funciona y el debate es difícil, si no imposible.
No estoy sugiriendo que Apple tenga motivos impuros, pero parece que tal vez su visión de Safari podría, al menos temporalmente, ser útil para el proceso de los estándares web … si Apple pudiera cambiar su forma de enfocar Safari.
Probablemente sea una quimera. Pero como escribió recientemente Bruce Lawson, defensor de la web desde hace mucho tiempo (y antiguo evangelista de Opera): «Si Apple permitiera que Safari compitiera realmente, sería mejor para los desarrolladores web, las empresas, los consumidores y para la salud de la web».
Si Apple fuera menos opaca y más rápida en su proceso de desarrollo, podría participar más en el debate sobre las nuevas API. Si la empresa está realmente preocupada por las implicaciones de las API en materia de privacidad, debería expresarlo. Hacer frente a Google y ofrecer una alternativa real a Chrome. No sería fácil, pero podría ser la única esperanza que tenemos.
fuente: The register
