Uno de los motores de renderizado más populares, hasta el punto de que se empezó a temer por una completa conquista de uso, es WebKit. El proyecto fue inicialmente desarrollado por Apple, pero gracias a su liberalización en 2005 varios fabricantes se unieron a él, entre ellos Google. Hoy día está muy extendido, tanto es así que Android lo utiliza para el navegador predeterminado, Safari para iOS, incluso Steam o Netflix se basan en él. El desarrollo por tanto se basa en la comunidad open source, aunque básicamente son las dos grandes compañías las que se encargan de aprobar, debatir y desarrollar la mayoría de avances del proyecto.

Gracias a que una página puede mostrar webs ligeramente diferentes según el motor, es una práctica relativamente común el ofrecer webs personalizadas para cada navegador o dispositivo. Las empresas lo saben, y la experiencia que se proporciona desde el smartphone no tiene porque ser la misma que la que se tiene cuando te conectas desde un sobremesa. Los motores de renderización son capaces de aprovechar las especificaciones de hardware para optimizar tanto la velocidad como la calidad de las imágenes a mostrar, y precisamente en eso es donde se trabaja.

Cada navegador quiere hacer algo especial, pero para eso se necesita tener tus propias herramientas. De momento los motores de renderizado open source han sido de gran utilidad, pero en un sector en el que Google, Apple o Microsoft quieren ofrecer algo tan propio la idea de crear su propia rama de desarrollo no podía tardar mucho en llegar.

Google crea Blink, un fork de WebKit

Durante el último año, de todos los grupos que participan, ha sido Google quién mostraba mas revisiones en el código del motor WebKit. Por cada cambio sin embargo surgía debate, y a más grande el cambio más tiempo para ponerse de acuerdo con los otros integrantes de el camino que se debe tomar.

Google ha decidido crear Blink, un proyecto derivado o fork de WebKit, que ya en su día derivó de KHTML. Con este movimiento deja a Apple fuera de las nuevas novedades que el equipo de trabajo de Mountain View realice. Los de Cupertino pueden seguir utilizando el núcleo de WebKit, pero exceptuando el (¿probable?) caso que Apple también cree un fork aparte será Chrome y no Safari quién nos muestre novedades relacionadas con su motor de renderizado.

Adam Barth, ingeniero de software de Google, escribe como la decisión de Google de hacer un fork de WebKit no fue fácil. Tener múltiples motores de renderizado será similar a tener múltiples navegadores, estimulará la innovación y mejorará con el tiempo la salud de todo la web como un ecosistema abierto y diverso.

Esto pensamos que en realidad nos deja un par de consecuencias a medio plazo:

• Veremos una versión más rápida de Chrome.
• Nuevo diseño pensado en aprovechar la potencia de más de un núcleo.
• Tiempo de arranque menor.
• Actualizaciones menores de Chrome en periodos más cortos gracias a la menor cantidad de revisores necesarias para sacar adelante las novedades. 
• Limpieza de código no compatible con los productos de Google. 
• Menos mano de obra para Safari. Apple pierde cerca de 2/3 de los desarrolladores de WebKit. 
• ¿A alguien le suena Chrome OS?

En concreto empezaremos a ver Blink en las futuras actualizaciones de Chrome dentro de aproximadamente unas diez semanas, en la versión número 28 y en las de, como explicaremos luego, Opera número 14.

Microsoft y sus propios problemas

El motor de renderizado de Microsoft se llama Trident. Pero a diferencia de los demás aquí podemos ver el eterno problema, el considerado por la mayoría de los desarrolladores como el cáncer de Internet. El motor culpable de tener que hacer centenares de líneas de código que en un mundo donde se respetaran los estándares no harían falta. Han pasado más de 5 años desde que Firefox pasara los tests Acid, pero solo las últimas versiones de IE empiezan a pasarlos, algo inaceptable para un navegador que venia preinstalado en tantos ordenadores.

Lo peor encima es que no se trata de un motor de código abierto. No tendría sentido que Microsoft no se apoyara en la comunidad de desarrolladores, pero todo es por culpa de su Microsoft Lifecycle support policy. Microsoft ofrece un mínimo de diez años de soporte en todas sus tecnologías, que en caso de integrar novedades en WebKit incompatibles no podría garantizar, precisamente por eso son tan reaccios a licenciar Trident a terceros.

Esta estrategia le funcionó muy bien a Netscape, incluso a la misma Microsoft o a Apple en los primeros años, pero la guerra de los navegadores cambió cuando Mozilla creó Gecko y abrió un mundo de posibilidades, dejando ver claramente lo tristemente que había funcionando la industria de los motores de renderizado hasta ese momento.

Mozilla se une a Samsung

¿Qué hay de Firefox? No nos preocupemos todavía. Mozilla seguirá utilizando su propio motor Gecko, totalmente maduro y completo, en las futuras versiones del navegador de escritorio. Sin embargo y con vistas al futuro; Mozilla se ha aliado con Samsung para crear Servo, un motor de renderizado open source creado desde cero y basado en el nuevo lenguaje Rust, parecido a C++ y que ya va por la versión 0.6.

La razón que esgrime Mozilla es que quieren hacer un nuevo motor optimizado para dispositivos ARM con varios núcleos, una razón que coincide con las de Google para crear Blink, cosa no debería extrañarnos. Servo también incluirá numerosas características de seguridad que esperemos estén al nivel de lo ya visto en Firefox.

La presencia y apoyo de Samsung en este nuevo motor podría ser el enésimo intento por parte de los coreanos de diferenciar sus móviles aún más del resto de la tropa Android, aunque dudamos realmente que empecemos a verlo en Firefox OS. Parece mucho más como que Mozilla utilizará Servo para probar cosas nuevas en dispositivos multinúcleo con un hardware radicalmente distinto del que acostumbra a utilizar Firefox.

¿Veremos detalles del Unreal Engine de Epic ya disponibles en las primeras pruebas de Servo? Es muy aventurado pensar ya en estas cosas, pero cuando se juntan dos empresas del calibre de Samsung y Mozilla todo puede pasar.

samsung_mozilla_rust

Opera y Apple tienen algo que decir

Opera no quiere saltar del carro y debe atarse al clavo más ardiente. Y esto pasa porque Opera ha decidido aliarse con Google y abrazar Blink, todo ello después de que dejaron de usar Presto, el cual estuvieron utilizando durante años, y de haberse pasado a WebKit hace meses. No olvidemos que Opera es un contendiente muy importante en el sector de la telefonía con la versión móvil de su navegador. Veremos si logran diferenciarse lo suficiente con Chromium como para remontar cuota de mercado.

Y mientras; Apple se queda como el único gran contribuyente de WebKit. No es posible tener varios equipos independientes que trabajan en grandes proyectos de software y aquí ha pasado esto mismo. Los ingenieros de Apple ya han informado que siguen involucrados en el desarrollo del motor de Safari y del navegador base de iOS, y están haciendo limpieza del código de WebKit relacionado con Chromium, algo que podría perjudicar a muchos desarrollos que se basan en el mismo.  El motor JavaScript V8, el DOMFileSystem, la WebLayer y la librería gráfica Skia serán las primeras en caer.

¿Veremos Chrome para iOS con el motor Blink? Técnicamente no debería haber ningún problema, pero todos conocemos la estricta y vigilada política de Apple, y tienen tajantemente prohibido cualquier motor que no coincida con el de su navegador predefinido, por lo que Chrome deberá desarrollar una rama aparte especial de iOS si quiere seguir teniendo un navegador en el Iphone o similares.

¿Cómo afectarán estos cambios en el futuro a desarrolladores y usuarios?

Nos gusta pensar que las “buenas” empresas abogan por estándares abiertos y las malos no. La verdad es la siguiente: las empresas inteligentes hacen las partes adecuadas para que su negocio prospere y da igual si eso significa que deben abrir o mantener de manera propietaria el código de sus programas. Simplemente en este tema Google quería alejarse de Apple para agilizar el proceso de trabajo y desarrollo y centrarse en aquellas características de WebKit que más utilidad tendrán para los planes del buscador. Lo mismo puede aplicarse para Mozilla, que ha visto como en el sector móvil está su futuro y se ha dado cuenta que el diseño e idea original que ellos tenían no tendrá cabida de aquí a unos años.

Y todos estos movimientos que ha habido estos días vienen genial para remover esos temores que había que WebKit se convirtiera casi en el único y todopoderoso motor de renderización con el que había que trabajar. Para ello ya están los estándares, y todo sería más fácil y compatible si los cumplieran. Tener un buen número de motores refuerza la importancia de estos. Queda realmente feo, y es común encontrar, ver sentencias de CSS como -webkit-*extensions; esperemos que tampoco veamos su contrapartida de -blink-*extensions.

Dejemos que nos contesten una serie de preguntas Darin Fisher, Eric Seidel y Paul Irish sobre el futuro de Blink.

En el vídeo, como desarrolladores que son defienden las bondades de todo esto, pero hay quién se muestra mas crítico con esto. Lo primero que nos lleva la mosca a la oreja es que si bien el código es open source, al final resultará en una comunidad como la de Android, donde los usuarios colaboran pero al final es Google la que lo decide todo a su manera. Es increíble que en este tema haya sido Apple la que más se haya aprovechado de la liberalización de un trabajo suyo y que sea Microsoft, quién tiene como modelo de negocio la universalidad de sus productos, la que tiene el navegador más atrasado y cerrado de todos.

¿Estamos ante las puertas de una fragmentación en cuanto a compatibilidad de los navegadores se refiere? Nos tememos que por mucho que el core de WebKit no se vea tan afectado por los distintos forks gracias a que al fin y al cabo siguen siendo proyectos abiertos, el hecho que se creen motores según tipos de procesador, según dispositivo y según intereses no puede ser nada bueno. Un ejemplo de bifurcación positiva fue MariaDB, ya que salvó a MySQL del oscuro destino que tiene bajo Oracle, veremos si pasa lo mismo con WebKit. Cuando se llega a cierto punto en un proyecto utilizado por todos o una de las partes implicadas se esciende en la búsqueda de su propio camino o acaba por convertirse en un estándard de facto.

¿Se convertirá el motor de renderizado, y por ende el navegador predeterminado en un factor diferencial a la hora de elegir una marca u otra? ¿Cuál de ellos os llama más la atención?