RSS WebKit

Hoy mismo os hemos comentado cómo el código fuente de WebKit nos ha sugerido que iOS 12 puede seguir siendo compatible con el iPhone 5s, pero por lo visto no es lo único que nos va a soplar. Desde 9to5Mac leemos que ese mismo código también tiene escondidas referencias a un modo oscuro para macOS.

Sí, no hablamos de iOS si no de macOS. Se ha visto que, desde marzo, el código de WebKit puede llegar a cambiar la apariencia de ciertos elementos de una web dependiendo de unos parámetros que le dé el sistema. Y esos parámetros pueden ser un cambio de color hacia el modo oscuro, para que así las webs con fondo claro cambien.

Ademas de los tests de velocidad, una de las pruebas mas importantes para los desarrolladores web es el test de rendimiento de los navegadores. Estos tests tienen como referencia Speedometer, un test de rendimiento que pone a prueba diferentes tareas típicas de un navegador web para finalmente darle una puntuación. Speedometer fue creado por Apple en 2014, ahora llega Speedometer 2.0, adaptado a las tecnologías actuales.

De acuerdo con el blog oficial de WebKit, en iOS 10 se han realizado una serie de cambios importantes en el navegador de Apple. Por ejemplo ya no tendremos que pulsar sobre un GIF para que comience a reproducirse como en iOS 9, y tampoco tendremos más videos molestos que se reproducirán automáticamente al cargar una web.

Aunque Joe Belfiore midió al máximo sus palabras durante la presentación oficial de Project Spartan, el nuevo navegador web que tomará el relevo a Explorer en Windows 10, lo cierto es que el vicepresidente ejecutivo de sistemas operativos de Microsoft no puede negar la evidencia: WebKit se ha convertido en el estándar de facto en los motores de renderizado web y seguir atados por la compatibilidad con versiones anteriores de Explorer es un lastre.

"Un nuevo motor de renderizado que ha sido creado para ser compatible con el modo en que se escribe la web hoy día", aseguró Belfiore rápidamente antes de pasar a la siguiente característica, sabiendo perfectamente que bien podríamos sustituir la última parte de esta sentencia por una sola palabra, WebKit. Y atentos porque aquí no estamos hablando de seguir los estándares del World Wide Web Consortium -W3C-.

Muy buenas noticias para los desarrolladores: Apple acaba de deshacerse de un defecto que llevaba tiempo arrastrando desde modernizando WebKit en iOS 8 y permitiendo que cualquier aplicación que cargue una página web pueda hacerlo con el mismo rendimiento que Safari. Para mí, era una de esas cosas que consideraba incomprensibles.

De este modo, cuando todo el mundo use iOS 8, cualquier aplicación que cargue una página web desde un panel (y sin cambiar a Safari Mobile) no tendrá ninguna barrera para hacerlo con la misma rapidez que con el navegador nativo. Y eso también son buenas noticias para los navegadores de la competencia como Google Chrome, que también podrán gozar del máximo rendimiento posible en iOS.

La optimización y el aumento de velocidad de los motores JavaScript se ha convertido en uno de los principales campos de batalla de los navegadores web. El motor Nitro de Apple vivió su momento de gloria tiempo atrás poniendo a Safari al frente pero Google logró adelantarlo por la derecha con su V8 y ahora la manzana parece estar decidida a devolvérsela.

Y es que los últimos cambios registrados en WebKit, el proyecto de software libre mantenido por Apple y sobre el que se construye Safari, otorgan a su motor de JavaScript una inyección de rendimiento que lo hacen significativamente más rápido que Chrome en algunos benchmarks, brillando especialmente a la hora de ejecutar código no optimizado para asm.js, el subset especial de JavaScript desarrollado por Mozilla para interpretar código C y C++.

Todavía vemos a los MacBook Pro con pantalla retina como algo nuevo y caro, pero es cuestión de tiempo para que este tipo de pantallas lleguen al resto de ordenadores de Apple (tanto el resto de portátiles como en las pantallas de sobremesa). Y aunque ya hay algún apaño en marcha, la web tiene que prepararse para este salto de resolución que ya están empezando a adoptar incluso en la competencia.

Por eso, el motor Webkit ha añadido soporte para gráficos que cambian de forma dinámica dependiendo del dispositivo que estemos usando, cubriendo desde un smartphone hasta la pantalla más grande de un ordenador de sobremesa. Todo depende de la cantidad de pixeles reales que se usen para mostrar un punto en la pantalla: Apple lo multiplica por dos (cosa que ya nos deja margen de sobra para que la retina humana no distinga los pixeles), pero se podría multiplicar incluso por cuatro en pantallas con una densidad de pixeles muy alta. Es, básicamente, un "multiplicador de resolución".

Que opine que Apple deba considerar la opción de abandonar WebKit y subirse a lomos de Google con Blink para centrarse en la capa de la interfaz de usuario no implica que crea que lo vaya a hacer, y mucho menos de forma inmediata. Lo que está ocurriendo en cambio es justo lo que cabría esperar: Apple ha tomado de nuevo las riendas del proyecto WebKit empezando por hacer limpieza eliminando el soporte de Google Chrome y su motor de JavaScript V8.

El movimiento ha sido criticado por algunos que ven como WebKit vuelve a cerrarse más estrechamente alrededor de Safari y las tecnologías que utiliza, pero los ingenieros de Apple lo tienen claro: hacer que WebKit fuese capaz de operar con varios motores de JavaScript ha sido una gran carga para el proyecto y el único motivo por el que hicieron esa concesión a Google fue porque esperaban que se convirtiese en un gran contribuidor al mismo, tal y como así ha sido.

La semana pasada Google anunció sus planes para abandonar WebKit y fundar un nuevo proyecto de código abierto basado en este con el nombre de Blink. Google era el mayor contribuidor de WebKit, pero por algún motivo nunca compartieron con el proyecto los cambios que realizaron para permitir el uso de la arquitectura multiproceso de Chrome, la cual hace que cada pestaña funcione de forma independiente mejorando notablemente la estabilidad y seguridad del navegador.

Ante la negativa de Google, la comunidad del proyecto WebKit anunció hace tres años WebKit2, una nueva API diseñada desde cero para utilizar este modelo de división de procesos que Apple integró en Safari 5.1, pero que aún es descrita por la propia web del proyecto como una tecnología temprana que no está lista para el gran público. Sabiendo que Apple está decidida a adoptar esta arquitectura y tampoco necesita seguir manteniendo la antigua, ¿por qué no cortar por lo sano como Google y apostar por Blink aprovechando que también es de código abierto y cuenta con todo lo que necesitan?

A Google se le está empezando a dar bien eso de sorprendernos con sus anuncios y hoy lo hacen con Blink, un nuevo motor de renderizado de código abierto basado en WebKit. La compañía de Mountain View utilizaba hasta ahora WebKit, el motor creado en 2001 por Apple a partir de KHTML, para renderizar las páginas en su navegador, Chrome, pero las próximas versiones pasarán a utilizar el nuevo motor en su lugar.

Google se había convertido en el principal contribuidor de WebKit, pero al parecer la popularidad del proyecto y la incorporación de decenas de compañías y plataformas también están lastrando su desarrollo. Blink nace así con la intención de cortar por lo sano (Google habla de que lo primero que harán será eliminar 4.5 millones de líneas de código que ya no necesitarán) agilizando su trabajo con las tecnologías que sí utilizan y despidiéndose de las que no.