BrowsersLos que tenemos ya unos cuantos años a nuestras espaldas y somos además bilingües digitales, recordamos lo que fue la tremenda guerra de los navegadores de finales de los años ‘90 y principios de los ‘00. Todavía sentimos punzadas de dolor al recordar lo que ello supuso para los desarrolladores web de entonces. Si crees que ahora es complicado programar una aplicación web y que funcione para todos los dispositivos y navegadores, tendrías que haber visto lo que era eso en el año 2.000 :-S

Cuando Internet apareció en nuestras vidas a principios de los años ‘90 muchas empresas subestimaron su importancia. Y quizá la que más se confundió entonces fue Microsoft, por aquella época ya líder del mercado de sistemas operativos para el escritorio. No supo ver el potencial que suponía la Red de redes, y se dejó llevar. para cuando quiso darse cuenta una pequeña empresa llamada Netscape se había hecho con el 80% del mercado de navegadores de Internet, dejando a Microsoft sin posibilidades (aparentemente) de obtener el control de la navegación por el nuevo medio.

Microsoft reaccionó tarde pero tenía su favor dos cosas de las que no disponía la pequeña Netscape: dinero a espuertas, y una cuota de mercado brutal en los sistemas operativos, de más del 95%. Así que puso a los mejores a trabajar en su propio navegador de Internet y en unos pocos años alcanzó a Netscape. Desde agosto de 1995 en que se lanzó Internet Explorer 1.0 poco a poco fue comiendo terreno al competidor, hasta que en 2002, en el máximo apogeo de su poderío, Internet Explorer 6.0 llegó a tener un 96% de cuota de mercado de uso de navegadores. Esos 7 años es en los que se suele acotar la duración de la primigenia guerra de los navegadores.

Para tratar de competir entre ellos, tanto Netscape como Internet Explorer añadían constantemente características a los navegadores, las cuales eran incompatibles entre sí. Una gran parte de la confusión que existe hoy en día con el DOM (Document Object Model) de los navegadores, y la necesidad de estandarizarlo usando “parches” (como por ejemplo que en el procesamiento de eventos tengas que especificar en qué dirección se notifican éstos por el árbol de elementos de una página), provienen de esta época oscura. En aquel entonces, en la práctica, lo que había que hacer era crear dos versiones de tus páginas o aplicaciones web: una para Internet Explorer y la otra para Netscape. Salvo en los casos más simples, era casi imposible hacer algo complejo que fuera fácil de poner a andar en ambas plataformas.

El que más hizo uso de su poder para imponer su punto de vista sobre cómo debían hacerse las páginas Web fue Microsoft, y cuando el World Wide Web Consortium (W3C) se empezó a poner las pilas y promovió estándares para tratar de buscar un común denominador, Internet Explorer no los implementaba. De hecho hasta Internet Explorer 8 (marzo de 2009), cuando ya la nueva competencia de Firefox y Chrome empezaba a hacerles daño de verdad, Microsoft no empezó a tomarse en serio la necesidad de seguir los estándares. De hecho no fue hasta Internet Explorer 9 cuando empezó a conseguir una buena compatibilidad. Ahora con IE10 la implementación de HTML 5 y CSS 3 es muy alta, pero todavía le queda bastante camino que recorrer, si bien el futuro Internet Explorer 11 incorporará algunas características (como WebGL y WebRTC) con las que no estaban de acuerdo y se resistían a incluir en su navegador.

La situación llegó a tal punto que hasta la propia Microsoft hizo campaña contra su propio navegador, muchos años más tarde, y promovió un sitio web para que la gente dejara de utilizar Internet Explorer 6 (aunque aún tiene más de un 5% de cuota a día de hoy). Y no fueron los únicos.

Distintos corazones para la misma Web

Hasta hace muy poco existían cuatro motores de renderizado, que son el corazón de los principales navegadores del mercado:

  • Trident: es el motor de renderizado de Internet Explorer. Creado y controlado por Microsoft en los años ‘90 y evolucionado hasta llegar a su actual encarnación, muy compatible con los últimos estándares del W3C. Es de código cerrado. Aunque es totalmente multi-platoforma (corre bajo Windows en plataformas Wintel, pero también en la versión para ARM de Windows y en Windows Phone, con arquitecturas diferentes), Microsoft sólo lo utiliza en sus propios productos, por lo que no podemos usarlo en Mac, por ejemplo (algo que hace años sí era posible gracias a los acuerdos entre Microsoft y Apple).
  • Gecko: es el motor de Firefox. Es el heredero de Netscape ya que parte del código que esta empresa liberó como Open Source en 1998 con el nombre de Mozilla. El motor del Netscape original era muy inferior en características y potencia al de Internet Explorer, por lo que liberaron Mozilla y se desarrolló en paralelo en modo abierto para lograr un producto nuevo más competitivo. En 2000 salió Netscape 6 que llevaba Gecko en su corazón, pero en 2003 el entonces dueño de Netsape se deshizo del proyecto. A partir de ese momento los ex-empleados de Mozilla cogieron el proyecto bajo su mano y empezaron con Firefox.
  • Webkit: es el motor de renderizado de Apple Safari y de Google Chrome entre otros muchos navegadores, entre los que se incluyen la mayoría de los navegadores para móviles (iOS, Android, Blackberry...). Hoy en día es el que mayor cuota de mercado conjunta tiene si se suman los de todos los navegadores que lo utilizan. Nació como un “fork” del motor de render KHTML para el entorno de escritorio de Linux KDE. Esta nueva rama la inició Apple en el año 2001, portando el código a Mac OS X con ayuda de adaptadores. En un momento dado se llegó a la conclusión de que la base de código era tan diferente debido a las modificaciones de Apple que era extremadamente complejo mantener el intercambio de código entre KHTML y Webkit, y además la relación entre ambos equipos empezó a ser muy tensa, así que éste último se convirtió en un proyecto independiente. Hoy en día KHTML sigue su propio camino pero apenas es utilizado y de hecho desde 2007 KDE usa también Webkit en el navegador de su escritorio. Aunque Chrome usa Webkit para renderizar las páginas, el motor de JavaScript que utiliza es propio, se denomina V8 y también dota de su potencia a lenguajes de servidor como Node.js.
  • Presto: es el motor de renderizado de Opera. Lanzado en el año 2003 con Opera 7, la gente de Opera Software lo ha abandonado en favor de Webkit, por lo que las próximas versiones de Opera estarán basadas también en el motor que originó Apple.

Dado que Opera ha abandonado Presto, quedan en la práctica 3 motores de render de HTML: Trident, Gecko y Webkit, todos ellos muy parecidos en cuanto a características, confluyendo hacia los estándares del W3C.

Sin embargo Google acaba de anunciar que se separa del proyecto WebKit para crear una nueva variante del motor denominada Blink. Google alega para este movimiento que, dado que su navegador tiene una arquitectura muti-proceso muy diferente a la de los demás navegadores que también usan Webkit, se agrega mucha complejidad al proyecto, así que a partir de ahora irán por libre. Dice que van a deshacerse de 7 sistemas de “build” y a eliminar más de 7.000 archivos (con más de 4,5 millones de líneas de código) para aligerar el programa.

Sin embargo a mi me gusta mucho este FAQ alternativo que ha escrito Rob Isaac traduciendo al cristiano la cháchara del FAQ original de Google sobre el movimiento a Blink. Creo que es bastante esclarecedor sobre las intenciones de Google con Blink.

Una nueva guerra de los navegadores

Ahora mismo nos encontramos en el amanecer de una nueva guerra de los navegadores. Y no me refiero a una guerra comercial por ver quién acapara más usuarios de su navegador, sino a una guerra sucia de estrategias inmovilizadoras en la que el que saldrá perdiendo será sin duda el usuario y sobre todo los programadores.

En el mundo de los navegadores existen dos fuerzas opuestas en cuyo equilibro se basa la felicidad de los habitantes de Internet. Por un lado está la competencia, que es muy importante para asegurar que se avanza y que ninguna empresa impone su propio punto de vista. Por otro tenemos la necesidad de un marco común sobre el que programar y que sea compartido por todos los navegadores.

¿Cómo se aúnan esas dos fuerzas opuestas? Por un lado gracias a la estandarización de las tecnologías web, cometido que le corresponde al W3C. Y por otro tratando de que no haya demasiada desigualdad en las cuotas de mercado de los competidores. Que uno de ellos domine ampliamente a los demás no es bueno para nadie como nos demuestra la historia reciente.

Hasta hace poco nos encontrábamos cerca de esta situación ideal. Disponíamos de 3 motores de renderizado principales en el mercado con unas cuotas de reparto de usuarios bastante equilibradas ya que no había ninguno con un trozo exageradamente mayor que los demás (aunque depende de a quién le preguntes y quién proporcione las estadísticas). Existe un consenso acerca de que HTML 5 y CSS 3 deben ser los caminos a seguir, y todos los navegadores en mayor o menor medida cumplen con el borrador actual de esos estándares, y la confluencia hacia ello es innegable. Si bien todavía existen algunas diferencias entre los navegadores, excepto para aplicaciones avanzadas o especiales que usen algunas características específicas de algún navegador, la programación es muy parecida (lástima de WebRTC y WebGL en IE, pero hacia ello va también). También existen discrepancias acerca de los formatos multimedia a utilizar en cada navegador (con otra pequeña guerra abierta entre Google con su formato WebM y los demás por ver cuál es el que predomina). Ya digo: todavía con diferencias, discrepancias y luchas, pero todo el entorno web confluyendo en la misma dirección.

Sin embargo WebKit especialmente (y en particular por parte de Google) comenzó a añadir extensiones a este motor de renderizado que hacían que ciertas características sólo funcionasen en éste, dejando de lado los estándares y a los demás navegadores. Mozilla también tiene lo suyo en este aspecto, pero su poder cada vez es menor. Internet Explorer incluye algunas extensiones propias pero están pensadas únicamente para ser utilizadas en aplicaciones “Metro” (o Windows Store, como se dice ahora) y no en la Web.

El poder de Webkit se ha extendido enormemente debido no sólo a la popularidad de Google Chrome en el escritorio (con una cuota global estimada que anda de cerca del 40% si no lo ha superado), sino sobre todo a su absoluto dominio dentro del mundo móvil ya que lo incorpora la versión móvil de Safari para iOS (iPhone y iPad) y la versión móvil de Chrome en Android. Este poder rompe el equilibrio y Google sobre todo lo sabe. Así que hace ya tiempo que se dedican a incluir sus propias extensiones al navegador, siendo cada vez más frecuente encontrarse con páginas “optimizadas para Chrome” o que directamente sólo funcionan en este navegador, algo que no pasaba desde los años de IE6 y su 96% de cuota de mercado.

Muchos detractores están haciendo campaña para luchar en contra de este efecto y que vuelva una nueva guerra de navegadores. El más significativo es quizá este artículo que escribió hace un año Daniel Glazman, co-presidente del grupo de trabajo para CSS del W3C:

CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*

En este artículo es una llamada a la acción a todos los desarrolladores web para que no se dejen llevar por la inercia y desarrollen solamente para WebKit, y que no admitan únicamente el uso de los prefijos propios de este motor de renderizado, para que no vuelva a pasar lo de hace una década. También apela a los usuarios para que protesten cuando lleguen a sitios así, y para que no sólo usen Chrome y navegadores con Webkit.

Él, claro está se centra en CSS que es lo suyo, pero esto mismo ocurre en otras partes de HTML, como por ejemplo el sistema de notificaciones, o la implementación específica de algunas APIs.

Con la decisión de Google de moverse de Webkit y empezar su propia versión, Blink, las cosas empezarán a ser mucho peores en los próximos meses. Sobre todo teniendo en cuenta que actualizarán al nuevo motor a sus millones de usuarios de manera silenciosa, sin avisar, y poco a poco tendremos un nuevo motor diferente y con cosas particulares, pero con un poder de mercado enorme con el que competir para quitar a sus competidores del medio.

Además hemos de tener en cuenta que Apple ahora se queda sin la mitad aproximadamente del código que se contribuía a Webkit (era Google quién lo hacía), y Apple está centrado en iOS 7 y sus iDispositivos. Tener un navegador de vanguardia no creo que sea una de sus prioridades, más allá de como mucho mantenerse a un nivel parecido al de los demás navegadores, o sea, como Microsoft no hace tanto. Por otro lado Microsoft no puede liberar alegremente nuevas versiones de su navegador tan a menudo como quisiera ya que, al contrario que Google, tiene cientos de millones de clientes corporativos en los que no puede simplemente actualizar su motor de renderizado y ya está. Si rompe la compatibilidad sin querer con alguna aplicación interna tendría un problema muy grave que ha partido, encima, de un producto gratuito, por no mencionar que los administradores de sistemas son muy conservadores (por la cuenta que les trae) y no actualizan así como así nada en sus redes. Google no tiene ese problema.

Google está libre para avanzar a la velocidad que crea conveniente con las características de su navegador, sin luchar con Apple, con una cuota de mercado muy elevada y con actualizaciones silenciosas y automáticas en segundo plano. No va a tardar en añadir decenas de características que sólo funcionarán en su navegador. Y la Web y todo lo que funciona desde ella son su prioridad absoluta. De ello depende su supervivencia, así que no dudará ni un ápice en hacer lo que sea para barrer a los demás del mercado. ¿Te suena la historia? A mi también.

Muchos pueden alegar que el hecho de que se añada innovación es positivo. Claro que lo es. Lo que NO es positivo es que lo hagan sin contar con los demás de modo que usen su poder para alcanzar mayores cuotas de mercado (qué pasa si GMail o Google Maps sólo funcionan con Chrome, por ejemplo, o si hay ciertas cosas que sólo funcionan en Android y no en los demás móviles), y sin consensuarlo con los demás actores del mercado.

Y la cosa sólo puede ir a peor. De hecho ya se están viendo movimientos en otros ámbitos que poco tienen que ver con decisiones que favorezcan a los usuarios y mucho con decisiones comerciales (eliminar Active Sync de Google Apps, cargarse Google Reader...).

Es cierto que el W3C es un organismo lento hasta la exasperación, que lleva muchísimos años para aprobar HTML 5 y todavía le falta bastante para hacerlo. Pero eso no es motivo para saltárselo a la torera y que cada uno tire por su lado. Lo que habría que hacer es consensuar y debatir sobre las nuevas características necesarias para los navegadores, innovando en las mismas sin importar de quién vengan, y llegar a acuerdos aunque algunos pierdan pequeñas parcelas de poder o no estén totalmente de acuerdo (esto pasaba en Webkit hasta ahora sin mayores tragedias que se sepa). Unas veces ganarán unos y otras otros, pero así ganaremos siempre los que importamos: los usuarios, y también los desarrolladores. También se puede agilizar el trabajo de la W3C. Es una cuestión de voluntad y de poner recursos y personas específicamente dedicadas a ello por parte de las empresas involucradas.

¿Te acuerdas de cuándo Microsoft introdujo VBScript en sus navegadores y sólo lo soportaban ellos? Pues tenlo en mente cuando dentro de unos meses tengas a Dart, el lenguaje de Script de Google, metido en Chrome y empiecen a aparecer sitios de la empresa (Gmail?), que sólo funcionen con ese navegador porque están escritos con Dart. Por no mencionar el poder que pueden tener para dotar de ventaja competitiva a su sistema operativo móvil, Android.

Lo dicho en el título: estoy teniendo un Déjà vu. En él Blink es el nuevo Internet Explorer 6 y Google hace exactamente lo mismo que hizo en su día Microsoft.

Me están entrando sudores fríos...

 

ACTUALIZACIÓN 10/4/2013

En esta sociedad de Internet, con sobrecarga de información y llena de artículos ligeros y superficiales, la gente se ha acostumbrado a no leer (aunque le marques en negrita lo importante). Incluso los que sí leen, en muchos casos no se paran ni medio segundo a meditar sobre lo que han leído. Así que quizá en este artículo debería haber sido menos didáctico y más directo al grano, al menos a tenor de algunas críticas que se han vertido sobre él en las redes sociales. En otros casos además confluye la circunstancia de que como contra-argumentos lo único que se hace es repetir clichés (disfrazados de aforismos) que mucha gente tiene grabados a fuego y nunca analizan de manera objetiva y con cierta perspectiva.

Uno de estos clichés es el de “Es Open Source, ergo es siempre bueno”.

A ver, mis conclusiones de este artículo de opinión no se ven influidas en modo alguno por el hecho de que Blink sea o no Open Source. Da exactamente igual que sea ese el caso. Lo importante aquí es que una determinada empresa tiene una posición predominante en el mercado y que va a utilizar esa posición para llevar a los usuarios hacia sus productos para tratar de acabar con su competencia, como ya hizo Microsoft en los ‘90. Para ello van a dotar a su navegador de características incompatibles con los demás navegadores para que debas utilizarlo para hacer uso de sus productos (correo, mapas, quizá buscador), de modo que pueda favorecer sobre todo a su sistema operativo para móviles, pero también para que uses Chrome y puedan saber más de ti y venderte mejor publicidad. No será en medio año ni en un año, pero seguro que sí en menos de dos.

¿Qué más da que el producto sea Open Source? ¿Los demás navegadores van a coger ese código Open Source y lo van adoptar? ¿Por qué no adoptan entonces directamente todos los navegadores Blink como futuro motor de render y así todos contentos? Quizá deberían hacerlo y así todos tendrían que ponerse de acuerdo.

Webkit ya es Open Source. No es necesario que hagan Blink para que el producto sea Open Source. La diferencia estriba en que ahora en WebKit las contribuciones al código son aproximadamente del 50% por parte de Google y Apple. Lo que contribuye el resto de la gente es casi testimonial. Esa situación obliga a Google a negociar con Apple sobre qué cosas se incorporan o no al navegador, y se mantiene un cierto equilibrio puesto que ambas empresas están en lucha con sus sistemas operativos móviles y, como en el chiste del dentista, la situación es “vamos a llevarnos bien”.

Ahora que Google va por libre y su navegador tiene una cuota de mercado tan amplia, nada les impide tomar medidas en el navegador para atarlo a sus tecnologías, productos y sistemas, como haría cualquier empresa privada en su situación y mientras las autoridades anti-monopolio no les metan mano como pasó con Microsoft.

Y es que, queridos niños y niñas, Google es una empresa privada, no una ONG, y (¡cuidado, spoiler!) los reyes magos no existen. Lo único que buscan es su beneficio y el de sus accionistas, al igual que Apple, Microsoft, Facebook, o cualquier otra empresa privada. Lo del “Don’t be evil” hace mucho que quedó en otro cliché. Por eso es necesario un W3C ágil y participativo.

El hecho de que el código de Blink vaya a ser Open Source no tiene absolutamente nada que ver con lo que yo estaba diciendo. en el artículo Es indiferente para lo que me preocupa y debería preocuparnos a todos los que estamos involucrados en Internet.

Sé que alguna gente que ha criticado mi punto de vista estaba en el instituto cuando se generó la primera guerra de los navegadores (¡qué viejo me hace sentir!) y no saben de lo que estoy hablando. Pero a nada que uno se pare a analizarlo es evidente. Lo negativo de la situación se cae por su propio peso.

En cualquier caso, el tiempo me dará o me quitará la razón. Todo esto es solo una opinión basada en la experiencia. Pero como no estamos hablando de religión ni de política, no hay motivos para la acritud ni las discusiones.

Simplemente espero haber aclarado un poco más mi punto de vista con este comentario adicional :-)

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA