Análisis

Un analizador (parser) es el componente que lee texto de entrada y construye una representación estructurada de él con la que un programa puede trabajar realmente. El texto en bruto es solo una secuencia de caracteres sin significado inherente para el software; un analizador es el paso que convierte ese flujo plano en algo con forma y jerarquía. Se sitúa en la frontera entre el texto escrito por humanos o generado por máquinas y los datos estructurados que necesita el resto de un programa.

Dos etapas: tokenizar y luego construir un árbol

La mayoría de los analizadores funcionan en dos etapas distintas. La primera etapa, un tokenizador o analizador léxico, agrupa caracteres en unidades significativas -etiquetas, palabras, números, operadores, símbolos- de modo que la entrada deja de ser caracteres individuales para ser una secuencia de tokens. La segunda etapa, la construcción del árbol, organiza esos tokens en una jerarquía según una gramática, produciendo un árbol estructurado. Separar estos dos trabajos mantiene cada uno más simple y es un patrón que verás una y otra vez.

La tokenización por sí sola resuelve mucha ambigüedad. Considera cómo los caracteres que forman una etiqueta de apertura, un nombre de atributo y un valor entre comillas deben reconocerse como cosas separadas antes de que pueda construirse cualquier estructura; el tokenizador es lo que establece esas distinciones. Solo una vez que la entrada es un flujo limpio de tokens puede la etapa de construcción del árbol razonar sobre cómo se anidan y se relacionan entre sí.

Los parsers están en todas partes

Los analizadores están genuinamente por todas partes en cuanto empiezas a fijarte. Los compiladores analizan el código fuente en un árbol de sintaxis abstracta antes de generar instrucciones de máquina; los navegadores analizan HTML y CSS para construir las estructuras que renderizan; y las aplicaciones ordinarias analizan JSON, XML, YAML y archivos de configuración cada vez que se inician. Casi cualquier programa que acepta entrada de texto tiene un analizador en algún lugar dentro, aunque el autor nunca piense en él con ese nombre.

Por qué el resultado es un árbol

La salida de un analizador suele ser un árbol, y el tipo de árbol depende del dominio. Para un lenguaje de programación es un árbol de sintaxis abstracta que captura la estructura de las expresiones y sentencias; para una página web es el DOM, el árbol de elementos y nodos de texto que el navegador construye a partir del HTML. En ambos casos el árbol, y no el texto original, es sobre lo que operan las etapas posteriores.

La razón por la que un árbol es la salida natural es que la mayoría de los lenguajes y formatos de documento son inherentemente anidados. Una expresión contiene subexpresiones, un elemento contiene elementos hijos, un bloque de configuración contiene bloques anidados. Una lista plana de tokens no puede capturar ese anidamiento, pero un árbol lo expresa directamente, razón por la cual el análisis se describe tan a menudo como convertir un flujo unidimensional en una estructura de varios niveles.

Qué hace que el parsing de HTML sea singular

Lo que hace inusual el análisis de HTML entre todos estos ejemplos es su recuperación de errores estandarizada. El marcado del mundo real está lleno de errores -etiquetas sin cerrar, elementos mal colocados, atributos en posiciones extrañas- y aun así las páginas necesitan mostrarse. La especificación HTML responde a esto definiendo exactamente cómo debe manejar un analizador cada tipo de entrada malformada, en lugar de dejarlo a que cada implementación adivine.

La consecuencia de esa especificación precisa es una interoperabilidad notable. Como las reglas de recuperación de errores están detalladas con minuciosidad, cada navegador moderno construye el mismo árbol DOM a partir de la misma entrada rota, en lugar de que cada uno improvise de forma diferente. Por eso una página malformada se renderiza de forma consistente entre navegadores, y contrasta con formatos más estrictos como XML, que simplemente rechazan la entrada que no está bien formada en lugar de intentar repararla.

Tolerante frente a estricto, por diseño

Ese contraste resalta una compensación de diseño deliberada. Un analizador indulgente como el de HTML prioriza la resiliencia y que el usuario siempre vea algo, a costa de dejar pasar errores en silencio. Un analizador estricto como el de XML prioriza la corrección y la previsibilidad, a costa de rechazar de plano la entrada imperfecta. Ninguno es universalmente mejor; cada uno se adecúa al trabajo para el que fue diseñado, y reconocer qué filosofía sigue un formato te dice mucho sobre cómo se comporta.

Cuando el analizador se detiene: los scripts

El análisis de HTML tiene una segunda particularidad, y todo desarrollador web acaba encontrándola, normalmente por accidente: el analizador puede ser detenido por el propio documento que lee. Cuando llega a un elemento script corriente, no sigue adelante. MDN lo dice sin rodeos: los scripts sin atributos async, defer o type="module", así como los scripts en línea sin el atributo type="module", se descargan y ejecutan inmediatamente antes de que el navegador continúe analizando la página. El análisis se detiene, el script se ejecuta y solo entonces se reanuda.

No es una rareza, se deduce de lo que a un script le está permitido hacer. Un script en ejecución puede escribir en el documento y alterar marcado que el analizador aún no ha alcanzado, de modo que este no puede adelantarse sin riesgo. Esa única restricción explica por qué un script situado arriba en el documento retrasa todo lo que viene debajo, y por qué colocar los scripts al final del body fue durante años el consejo estándar.

Los dos atributos que cambian este comportamiento merecen una lectura precisa, porque no son intercambiables. Con async, el script se descarga en paralelo al análisis y se evalúa en cuanto está disponible, lo que significa que puede interrumpir el análisis en un momento impredecible y, en palabras de MDN, no garantiza ningún orden de ejecución concreto. Con defer, el script se ejecuta después de que el documento haya sido analizado, pero antes de disparar el evento DOMContentLoaded, y los scripts diferidos se ejecutan en el orden en que aparecen en el documento. async cambia el orden por velocidad; defer mantiene el orden y espera.

Es una corrección útil del modelo mental. Un analizador no es solo un traductor de texto a árbol, también es un planificador: cuándo trabaja, qué deja ocurrir por el camino y en qué se bloquea determinan la rapidez con la que una página se vuelve usable.

Un modelo mental para todo el stack

En cuanto empiezas a ver el software como una serie de analizadores que convierten texto en estructura, gran parte de la pila de la web se vuelve más fácil de razonar. El navegador analizando HTML en el DOM, el motor analizando JavaScript en un árbol de sintaxis, el servidor analizando el cuerpo de una petición JSON: son todos la misma idea aplicada en lugares diferentes. Esa única lente, la de texto convirtiéndose en datos estructurados a través de un analizador, es uno de los modelos mentales más útiles de toda la programación.