Browsers, una mirada más detallada

Prácticamente todo el mundo con PC sabe lo que es un browser y como utilizarlo, pero como sucede con todo, existe un gran desconocimiento de las formas y comportamiento de los mismos.

Este post tiene como humilde objetivo introducir en los conceptos básicos de dos de los componentes más críticos de los browsers en cuanto a experiencia generada; estos son el motor gráfico y el interprete JavaScript.

A modo de disclaimer: No incluyo a Opera por dos motivos. El primero es la poca participación que tiene en el mercado (1.93% según wikipedia al día de la fecha), y el segundo es que no tengo suficiente conocimiento del mismo e implicaría bastante más investigación que el resto.

Motor gráfico (Layout engine)

Cualquier browser (de primera línea, por así decirlo), posee un motor gráfico encargado de renderizar los archivos html (entre otros, dependiendo del navegador en cuestión). La interpretación que hacen debería respetar la especificación correspondiente*, con agregados particulares como suelen ser la libre interpretación de casos no previstos por la especificación o inclusive errados sintácticamente.

*Los motores gráficos listados pueden no ser estrictamente “motores gráficos”, pudiendo cumplir roles adicionales a los detallados (como ser manejo de historial, soporte DOM, etc).

El renderizado de los browsers (y su velocidad al realizarlo) se puede percibir al:

  • Cargar un sitio, donde se produce un renderizado completo, lo que implica generar la estructura en memoria (render) y su posterior “dibujo” en pantalla (draw).
  • Modificar la estructura del árbol DOM o la geometría de uno o más nodos. En este caso se debe revalidar la estructura generada (parcial o totalmente, dependiendo de la modificación). Esta acción se denomina reflow.
  • Modificar el estilo o geometría de uno o más nodos. Se debe actualizar la visualización de la parte modificada. Esta acción se denomina repaint (o redraw).

Sabiendo esto, vamos a conocer a los sospechosos de siempre.

Microsoft: TridentMicrosoft Trident

Internet Explorer usa Trident como motor gráfico desde la versión 4, con obvios progresos desde ese entonces. De los browsers populares, este es sin duda el menos avanzado (sin contar que corre únicamente sobre Windows).

Los problemas de renderizado* y box model que tuvo y tiene lo ponen muy detrás de los competidores. Gran ejemplo de esto es la dificultad que genera desarrollar un sitio compatible con IE6 e inclusive IE7.

Obviamente, esperamos (y rogamos) que IE9 sea ciertamente un cambio de aire al respecto. Aparentemente IE10 va a reemplazar Trident con Linx.

*Particularmente fui víctima de un  memory leak utilizando background transparente, lo cual descubrí después de culpar y refactorear todo el javascript del site.

Mozilla: Gecko

Netscape GeckoMozilla usa Gecko (originalmente denominado NGLayout) para sus navegadores, ciertamente más poderoso que Trident. Está escrito en C++ y es multiplataforma.

Como adicional cabe destacar que tiene soporte nativo para renderizar archivos XUL (lenguaje de interfaz propio de Mozilla).

A los valientes, los invito a probar SeaMonkey, una “internet-suite” que utiliza Gecko para el render web.

Apple + Google: WebKit

WebkitChrome y Safari (entre otros) utilizan WebKit, que surge como fork de KHTML (motor gráfico para el navegador de KDE, Konkeror). Hablando con propiedad, si bien ambos utilizan este motor, no lo hacen con todos los componentes.

Como se verá más adelante Chrome utiliza WebCore (parte específicamente dedicada al render dentro de WebKit) pero no JavaScriptCore, al cual reemplaza con un intérprete propio.

Este motor gráfico es usado también por Adobe para su plataforma Air.

Dato curioso, el navegador Lunascape utiliza tres motores gráficos distintos (Trident, Gecko y WebKit), permitiendo alternar entre ellos.

Interprete JavaScript (JavaScript engine)

Por otra parte, otro componente (obviamente crítico) es el interprete Javascript, del cual depende obviamente la ejecución de los scripts. En este aspecto varían las implementaciones de browser a browser, así como también las optimizaciones realizadas.

Estos intérpretes están recibiendo mucha atención hoy en día, siendo el rendimiento de los mismos un factor crítico a la hora de promocionar los productos.

Microsoft: JScript, Chakra y la turba iracunda

Cualquier persona que se maneje mínimamente en el tema del desarrollo web sabe sobradamente lo odioso que se tornan las cosas al incluir los productos de Microsoft en la ecuación.

Obviamente esto no cambia a la hora de hablar de Internet Explorer y su (¿libre?) interpretación de JavaScript. En principio, ellos no interpretan JavaScript como está propuesto por el estándar (!), sino JScript, que representa un subset de funcionalidad JavaScript en conjunto de algunas extensiones propietarias*.

*Hay que reconocer sin embargo, que algunas de esas extensiones originalmente propietarias son muy exitosas hoy en día, siendo la más reconocible de las mismas las XMLHttpRequest(vulgarmente hablando, Ajax).

Mozilla: SpiderMonkey

Mozilla utiliza SpiderMonkey (que viene de la época de Netscape), escrito en C. A este motor se agregaron como componentes de optimización TraceMonkey (FF3.5) y JägerMonkey (FF4.0). Las optimizaciones realizadas van desde pre compilación (se optimiza el código al evaluarlo) hasta compilar en tiempo de ejecución porciones de código críticas (como ser el código interno de un loop).

Proyecto hermano de SpiderMonkey es Rhino, motor escrito en Java,  en el cual se basan los proyectos SSJ Narwhal y RingoJS.

Google: V8

V8Google presentó su navegador (Chrome) con un poderoso motor Javascript denominado V8. A diferencia de SpiderMonkey, V8 está escrito en C++.  Obviamente también presenta un conjunto de optimizaciones, siendo la más importante compilar el código Javascript a código nativo además de usar la técnica de inline caching.

Este motor es artífice del hype actual que existe con respecto a la velocidad de ejecución, desde su salida, todos los browsers del mercado tratan de seguirle el paso a Google con obvio beneficio para los usuarios.

Al igual que ocurre con Rhino, este intérprete es utilizado por (al menos) un proyecto SSJ, en este caso se trata de Node, sin duda alguna el de más renombre actualmente.

Apple: JavaScriptCore y SquirrelFish

SquirrelFishSafari utiliza por obvios motivos el intérprete JavaScript propio de WebKit, con las también obvias mejoras recibidas.

En este caso, el esfuerzo de los muchachos de WebKit se canaliza en SquirrelFish, que posteriormente evoluciona a SquirrelFish Extreme (SFX, mejor conocido Nitro) que aplica la ya mencionada receta de traducir JavaScript a código nativo con su consecuente mejora de performance.

Leer más:

Imagen de Trident tomada de: http://blogs.sitepoint.com/2010/04/01/microsoft-drop-trident-from-internet-explorer/



2 views shared on this article. Join in...

  1. gil dice:

    Tenmgo un problema, uso Explorer 7 en mi PC, pero algunas paginas como la del periodico Excelsior NO las puede leer, y si las grabo en un cybercafe a una USB cuando trato de leerlo en mi PC no lee esa paginas, las otras si, ademas en la URL le pone signos de % entre cada palabra. Como puedo corregir eso? si le cargo Explorer 8, se podra leer bien? me da miedo que con un Explorador mas nuevo me desconfirgure la PC y luego ya no lea nada. ¿alguien sabe si Explorer 8 es seguro,sin fallas? Gracias



Pings to this post

  1. […] Browsers, una mirada más detallada BrowserHigh Performance JavaScript (YUIConf 2010) Tuesday, December 28th, 2010 by […]


Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Comment

You may use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>