¡Chrome cumple 10 años! Gracias por hacer que la comunidad de desarrollo web sea tan abierta, colaborativa y solidaria. DevTools se inspiró en una cantidad innumerable de otros proyectos. A continuación, te mostraremos una retrospectiva de cómo se originó DevTools, y cómo ha cambiado con el paso de los años.



En el principio, estaba Firebug

Imagina por un momento que los navegadores no incorporaban herramientas para desarrolladores. ¿Cómo se depuraba JavaScript? Básicamente, había 3 opciones:
  • Distribuir llamadas window.alert() en todo tu código
  • Comentar secciones de código
  • Observar el código durante un largo tiempo hasta que los dioses de JavaScript te bendijeran con una solución
¿Qué ocurría con los problemas de diseño? ¿Y los errores en la red? Una vez más, la única posibilidad era hacer experimentos cuidadosos en tu código. Esta era la realidad del desarrollo web hasta 2006. Hasta que apareció una pequeña herramienta llamada Firebug que cambió todo.


Captura de pantalla del panel Net de Firebug tomada de Saying Goodbye to Firebug (fuente y licencia).

Firebug fue una extensión de Firefox que permitía depurar, editar y controlar páginas en tiempo real. Como desarrollador web, pasaste de repente de no poder visualizar tus páginas a disponer de las características principales de las herramientas modernas para desarrolladores. La capacidad de comprender exactamente por qué Firefox se comportaba como lo hacía desencadenó un desborde de creatividad en la Web. Sin Firebug, la era de la Web 2.0 no hubiera sido posible.




Web Inspector de WebKit


Alrededor de la misma época en la que se lanzó Firebug, algunos ingenieros de Google comenzaron a trabajar en un proyecto que eventualmente conduciría a Chrome. Desde el principio, Chrome fue una mashup de diferentes bibliotecas de código. Para la representación, los ingenieros de Chrome optaron por Webkit, que es el proyecto de código abierto en el que hasta hoy se basa Safari. Un beneficio adicional de usar WebKit fue que incluía una herramienta práctica llamada Web Inspector.


Captura de pantalla de Web Inspector, tomada de Web Inspector Redesign (fuente y licencia).

Al igual que el panel Net de Firebug, el Web Inspector original quizá te parezca familiar. Gran parte de su funcionalidad persiste en la actualidad, como el panel Elements en Chrome DevTools. Web Inspector se lanzó unos días después de Firebug y Safari fue el primer navegador que incluyó herramientas para desarrolladores directamente en el navegador.




La era de “Inspect Element”


 Chrome aportó muchas ideas innovadoras al ecosistema de los navegadores, como el cuadro multifunción que combinaba búsqueda con la barra de direcciones, y una arquitectura multiprocesos que evitaba que una pestaña bloqueada afectara a todo el navegador. Pero la innovación que más nos gusta fue el aprovisionamiento de herramientas para desarrolladores en todas las compilaciones para todos los usuarios, que quedaban a la vista haciendo clic con el mouse.

"Inspect Element" en 2010



Antes de Chrome, las herramientas para desarrolladores eran una experiencia opcional. Se instalaba una extensión, como Firebug, o se habilitaban algunos indicadores, como aún ocurre en Safari. Chrome fue el primer navegador en facilitar herramientas para desarrolladores desde cualquier instancia del navegador. Nos gustaría alegar que fuimos visionarios para crear un navegador accesible para el desarrollador desde el principio, pero la realidad es que Chrome presentaba muchos problemas de compatibilidad por aquellos días (lo que tiene sentido, ya que nadie realizaba compilaciones asociadas con él) y necesitábamos brindar a los desarrolladores web una alternativa sencilla para solucionar esos problemas. Los desarrolladores web nos informaron que era una característica útil, por lo que la conservamos.


La era móvil


Durante los primeros años del proyecto DevTools, en esencia agregamos capítulos a las historias que iniciaron Firebug y Web Inspector. El siguiente gran paso en nuestro enfoque de DevTools ocurrió cuando quedó claro que los smartphones habían llegado para quedarse.
Nuestra primera misión en este mundo nuevo y audaz fue permitir a los desarrolladores depurar dispositivos móviles reales desde sus máquinas de desarrollo, proceso que denominamos “depuración remota”. DevTools estaba bien posicionado para controlar la depuración remota, gracias a otra consecuencia de la arquitectura multiprocesos de Chrome. En la primera etapa del proyecto DevTools, nos dimos cuenta de que un depurador solo podía acceder de forma confiable a un navegador multiprocesos a través de un protocolo cliente-servidor, en el que el navegador fuera el servidor y el depurador el cliente. Cuando surgió Chrome para dispositivos móviles, el protocolo ya estaba integrado, por lo que solo debimos hacer que el DevTools que se ejecutaba en tu máquina de desarrollo se comunicara con el Chrome que se ejecutaba en tu dispositivo móvil a través del protocolo. Ese protocolo aún forma la columna vertebral de DevTools en la actualidad y se conoce como Protocolo de Chrome DevTools.

Depuración remota

La depuración remota fue un paso en la dirección correcta, y hasta hoy es la herramienta principal para asegurarte de que tus sitios se comporten de forma razonable en dispositivos móviles reales. Sin embargo, con el tiempo, nos dimos cuenta de que la depuración remota podía ser algo tediosa. Cuando te encuentras en las primeras fases de la creación de un sitio o una característica, generalmente solo necesitas una aproximación de primer orden a la experiencia móvil. Esto nos llevó a crear un conjunto de características de simulación móvil, como las siguientes:

  • Emulación precisa de la vista del puerto móvil, simulación de entradas táctiles y orientación del dispositivo
  • Restricción de la conexión de red para simular 3G y CPU para simular hardware móvil menos potente
  • Falsificación de identidad de usuario-agente, ubicación geográfica, datos de acelerómetro y más.

Nos referimos a estas características de forma conjunta como Device Mode.






Un prototipo inicial de Device Mode



Device Mode en 2018

La era del rendimiento


Mientras se desplegaba la era móvil, las grandes apps como Gmail trascendían los límites conocidos de las capacidades de la Web. Los errores del nivel de Gmail requerían herramientas para el nivel de Gmail. Una de nuestras principales contribuciones al ecosistema de herramientas fue mostrar un desglose paso a paso de exactamente todo lo que Chrome debía hacer para mostrar una página.


Panel Timeline original, como se anunció en Do More with Chrome Developer Tools,,


Panel Performance en 2018.


Estas herramientas fueron un paso en la dirección correcta, pero para poder detectar oportunidades de optimización era necesario aprender los pequeños detalles relacionados con el funcionamiento de los navegadores y buscar entre una gran cantidad de datos. Últimamente, hemos realizado compilaciones sobre esta base para proporcionar más estadísticas de rendimiento guiadas. El nuevo motor Lighthouse alimenta el panel Audits y también está disponible como módulo Node para integración con sistemas de IC.


Sugerencias de rendimiento en el panel Audits


La era Node.js


 Hasta aproximadamente 2014, concebíamos a DevTools ante todo como una herramienta para compilar experiencias excelentes en Chrome. El surgimiento de Node nos llevó a repensar nuestro rol en el ecosistema web.
Durante los primeros años de Node, los desarrolladores de este entorno se encontraron en una situación similar a la de los desarrolladores web antes de Firebug, o a la de los desarrolladores de Gmail antes del panel Timeline; la escala de las apps para Node superó la escala de las herramientas para Node. Debido a que Node se ejecuta en el motor JavaScript de Chrome, V8, DevTools era un candidato natural para cubrir la brecha. En 2016 llegó la asistencia para depurar Node con DevTools, lo que incluye las características habituales de DevTools; entre otras, puntos de interrupción, procesamiento de código paso a paso, cajanegrismo y mapas de origen para código transpilado.
Administrador de conexiones de Node



El ecosistema del protocolo DevTools


 El nombre Protocolo de Chrome DevTools (CDP) sugiere una API que solo DevTools puede usar. La realidad es más general que eso: es la API que permite acceder a Chrome mediante programación. Durante los últimos años, hemos visto que algunas bibliotecas y aplicaciones de terceros se unieron al ecosistema del protocolo:
  • chrome-remote-interface proporciona acceso de JavaScript de bajo nivel al protocolo.
  • Puppeteer lo lleva al siguiente nivel de abstracción y permite la automatización del siempre vigente e independiente navegador Chrome con la JavaScript API moderna.
  • Lighthouse automatiza el proceso de búsqueda alternativas para mejorar el rendimiento y la calidad de las páginas.

Nos entusiasma ver que miles de proyectos dependen de estos paquetes para permitir una interacción completa con Chrome. Si estás en el negocio de las herramientas o la automatización, te recomendamos revisar el protocolo para ver si ofrece alguna oportunidad para tu dominio. Por ejemplo, los equipos de VS Code y WebStorm lo usan para permitir la depuración de JavaScript en sus IDE respectivos.

Lo que viene
Nuestra misión principal es compilar herramientas que te ayuden a crear experiencias geniales en la Web. Dependemos en gran medida de tus comentarios para determinar los productos o las características que debemos desarrollar.


Gracias por crear una comunidad tan dinámica. Esperamos recorrer otros 10 años dando forma a la Web contigo.

Publicado por el equipo de Chrome DevTools