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 decisión hará más sencillo y coherente el desarrollo de WebKit y permitirá optimizar el motor Nitro integrándolo a un nivel más profundo dentro de su arquitectura. Buenas noticias para los usuarios de Safari y aquellos desarrolladores que confían en que una especialización es justo lo que necesita el proyecto, pero malas para quienes necesitaban precisamente lo contrario.
Este es el caso de Samsung y Oracle, dos compañías que aunque no contribuyen de forma significativa al proyecto, sí que utilizan WebKit junto a otros motores de JavaScript como V8 o Nashorn respectivamente. La respuesta de Oliver Hunt, uno de los ingenieros de Apple implicados en el proyecto es tajante:
Apoyar a V8 supuso una carga considerable para webkit, y fue necesario realizar un gran número de costosas y pesadas abstracciones para que fuese posible soportar múltiples motores de JS. Por si esto fuera poco, en WebKit2 tan solo apoyaremos el uso de JSC [JavaScriptCore, el nombre no comercial de Nitro], así que no creo que haya nada que pudiese convencerme de que mantener el soporte de múltiples motores de JS sea bueno para el proyecto.
Tras enumerar algunas de las cosas que hacen de JavaScriptCore una gran opción frente a V8 incluyendo la abstracción de CPU (que permite añadir soporte de más arquitectural con relativa sencillez), Oliver concluye:
Teniendo en cuenta todas estas grandes y maravillosas características, el soporte (a cierto nivel) de “todas” las arquitecturas, la carga sustancial que implica el mantenimiento de las bibliotecas portadas de V8 no parece que valga la pena, al menos para mí.Si hay alguna característica de V8 que quieras y JSC no tenga, te invito a que señales los errores o incluso contribuyas con su implementación :D
En pocas palabras: hagamos de Nitro el mejor motor de JavaScript en lugar de tratar de abarcarlo todo. Lo mismo se aplica por supuesto a WebKit, lo que como mínimo promete una competición de lo más interesante.
Espacio para el humor
Un último detalle sin la menor relación con lo anterior. Mientras navegaba por los archivos de la lista de desarrollo de WebKit me he encontrado con una divertida broma que envió el 1 de Abril un ingeniero de Intel con el anuncio de una nueva característica esperada durante largo tiempo: el soporte del VHS para la reproducción de vídeo en la web. Las respuestas acerca de Microsoft apostando por el formato Beta en su lugar y similares no tienen desperdicio.
Más información | WebKit-dev – Cleaning House
En Applesfera | Apple debería considerar seriamente la opción de abandonar WebKit y pasarse a Blink
 |  |