Cuando Opera anunció que pasaría sus distintos navegadores a WebKit, la prensa tecnológica mundial pareció alegrarse sin saber realmente lo que significaba. Nos gustaría, de manera objetiva, desglosar las posibles consecuencias de que la mayoría de los navegadores web se basen en WebKit, tanto para los proveedores de navegadores web como para los desarrolladores.
Opera utilizará la implementación Chromium de WebKit, así como el motor V8. Esto significa que, aunque Opera utiliza el nombre “WebKit”, no está utilizando los mismos fragmentos que componen otros navegadores WebKit como Safari. Este es un concepto importante que hay que entender si se quiere ser objetivo sobre la situación actual.
A menudo se asume que, dado que todos estos navegadores comparten el mismo nombre “WebKit”, todos soportarán las mismas características y las soportarán de la misma manera. Aunque esto es cierto para muchas características básicas, a menudo no es cierto para las características más nuevas y de nicho.
Por ejemplo, mientras que la API del Gamepad ha llegado a Chrome, todavía no ha llegado a Safari y es poco probable que lo haga. Otro ejemplo es WebGL, una tecnología que lleva mucho tiempo en Chrome, pero que apenas ha empezado a ver la luz en Safari (todavía detrás de una preferencia de los desarrolladores). Por supuesto, estos son ejemplos más grandes y experimentales, pero el punto subyacente permanece.
Apple se ha enfrentado a múltiples acusaciones de prácticas anticompetitivas en los últimos años, y parece que hay más por venir. Esta vez, un grupo de desarrolladores ha lanzado un proyecto llamado “Open Web Advocacy” que desafía a Apple a permitir otros motores de navegación en iOS.
“El motivo del grupo es intentar persuadir a Apple de que tiene que permitir otros motores de navegación en iOS, para que éste sea una plataforma mejor para desarrollar cosas para la web moderna”, explica Lawson. “Porque en este momento, todos los navegadores en iOS, ya sea con la marca Chrome, Firefox o Edge, son en realidad una piel de marca de Safari, que se queda atrás [de otros navegadores] porque no tiene competencia en iOS”.
Por ejemplo, las capacidades de pantalla completa están limitadas en los navegadores de terceros, y Apple restringe la integración de Apple Pay a Safari. Al mismo tiempo, las aplicaciones basadas en la web no pueden ejecutarse a pantalla completa, y los navegadores de terceros no ofrecen la opción de añadir una aplicación web a la pantalla de inicio. Los desarrolladores también se quejan de la falta de NFC web y otras API en el WebKit de iOS.
Cuando eliges un navegador web, también estás eligiendo un motor de navegación y un motor de renderizado – a veces estos dos términos se utilizan por separado y a veces para significar lo mismo. Técnicamente, el motor de renderizado renderiza las páginas y el motor de navegación se encarga de las comunicaciones entre el motor de renderizado y la interfaz de usuario del navegador.
Ya conoces los nombres de los tres principales motores de navegación, pero ¿qué son exactamente? Su trabajo consiste en tomar el código HTML, CSS y otros códigos de una página web -el texto que puedes ver en el código fuente de la página o abrir en un editor de texto, estableciendo los diseños, el contenido de la página y el estilo- y convertirlo en lo que realmente ves en la pantalla. El motor del navegador toma decisiones sobre cómo interpretar lo que un desarrollador web ha escrito: cómo afectan determinadas líneas de código a lo que aparece en pantalla.
Teniendo en cuenta todo esto, ¿debería seguir con su motor de navegación actual o debería cambiar a otro? Como ya hemos dicho, a primera vista no hay una gran diferencia entre los navegadores: Chrome (Blink), Firefox (Quantum) y Safari (WebKit) muestran la mayoría de los sitios web de forma muy similar y a velocidades muy parecidas, porque todos aceptan los mismos estándares web básicos (algo que no siempre ha sido así: descanse en paz Internet Explorer). No hay ninguna característica principal que podamos señalar que te haga dejar de repente WebKit y cambiar a Quantum, o viceversa.En un nivel, Blink es el mejor motor de navegador que existe (después de todo, Microsoft cambió a él). Es rápido en la representación de las páginas y aplicaciones, las actualizaciones se envían rápidamente, es relativamente robusto, y los errores tienden a ser parcheados rápidamente.
Según Apple, algunos de los cambios que requirieron diferentes tácticas de desarrollo implicaron características específicas de OS X que están ausentes en el KHTML de KDE, como Objective-C, KWQ (pronunciado “quack”) una implementación del subconjunto de Qt requerido para hacer que KHTML funcione en OS X escrito en Objective C++, y las llamadas de OS X[18].
El intercambio de código entre WebCore y KHTML se hizo cada vez más difícil a medida que la base de código divergía, ya que ambos proyectos tenían enfoques diferentes en cuanto a la codificación y el intercambio de código[19]. En un momento dado, los desarrolladores de KHTML dijeron que era improbable que aceptaran los cambios de Apple y afirmaron que la relación entre ambos grupos era un “amargo fracaso”[20] Apple presentó sus cambios en grandes parches que contenían múltiples cambios con una documentación inadecuada, a menudo en relación con futuras adiciones a la base de código. Así, los desarrolladores de KDE tenían dificultades para volver a integrar estos parches en KHTML[21]. Además, Apple había exigido a los desarrolladores que firmaran acuerdos de confidencialidad antes de examinar el código fuente de Apple y, aun así, no podían acceder a la base de datos de errores de Apple[22].