Las páginas publicadas necesitan un runtime consciente del contenido
El trabajo de ayer parecía una suma de ajustes pequeños en Notipad Publish, el renderer y la web de Nikki.
Una timeline con color distinto.
Un título menos en la home.
Un flowchart que deja de cortarse.
Un bloque de código que recupera su lenguaje.
Visto por separado, todo eso parece pulido.
Visto junto, aparece otra decisión:
una página publicada ya no puede tratar todos sus bloques como si necesitaran el mismo runtime.
El problema no era solo visual
La web pública ya mezcla varias superficies en una misma lectura:
| Tipo de contenido | Qué le falla si se trata como HTML genérico |
|---|---|
| Prosa | La jerarquía visual se vuelve redundante o ruidosa |
| Diagramas Mermaid | El layout se corta o nace con la escala equivocada |
| Flowcharts | Necesitan otra anchura y otra altura mínimas que una timeline |
| Bloques de código | Pierden el lenguaje y con él la posibilidad de resaltado correcto |
Eso cambia la pregunta.
Ya no era “cómo metemos más runtime en la página publicada”.
Era:
¿cómo hacemos que cada página cargue solo la capacidad que realmente necesita para seguir siendo legible?
El bundle fijo dejó de ser una respuesta seria
Mientras el publish era más homogéneo, cargar el mismo paquete para todo era una salida cómoda.
Pero esa comodidad empezó a romper dos cosas a la vez.
La primera era el peso mental del sistema: si cada página hereda Mermaid, resaltado y reglas de layout aunque no los use, la publicación deja de ser una composición precisa y se convierte en una manta genérica.
La segunda era la calidad de lectura: un flowchart no necesita el mismo contrato que un Gantt, y un bloque json sin clase de lenguaje deja al renderer público sin contexto suficiente para decidir cómo pintarlo.
La decisión real fue pasar de un runtime fijo a un runtime condicionado por el contenido:
- si la página no tiene diagramas, no carga Mermaid;
- si el markdown no contiene código resaltable, no carga el resaltador;
- si el diagrama es un flowchart, recibe reglas de tamaño distintas a las de una timeline;
- y si un bloque no se resalta, al menos conserva la información de qué lenguaje era.
Eso no es optimización prematura.
Es escribir mejor el contrato entre contenido y lectura pública.
El contrato tenía que sobrevivir toda la cadena
La parte interesante no estaba en un solo repo.
El cambio cruzó el core de render, el servicio que transforma markdown y el servicio que publica páginas.
Eso importa porque una página publicada falla cuando una capa asume que otra “ya sabrá” qué hacer.
La cadena quedó más explícita:
- El renderer base conserva la clase de lenguaje incluso cuando no aplica resaltado.
- El servicio de render solo trae el resaltador cuando detecta que el markdown realmente lo necesita.
- El servicio de publicación solo inyecta el runtime de Mermaid cuando la página contiene diagramas.
La lección es sencilla:
si el significado del contenido se pierde en una etapa intermedia, el runtime público acaba compensándolo con heurísticas más frágiles.
El contenido también empezó a dictar las reglas
La home de Nikki dejó de repetir el nombre como título grande y empezó a diferenciar visualmente la formación dentro de la timeline.
Eso puede parecer editorial, pero en realidad confirma el mismo movimiento.
Cuando la publicación madura, el contenido deja de diseñarse para sobrevivir a un renderer torpe y empieza a apoyarse en un renderer más específico.
La página ya no necesita un encabezado redundante “por si acaso”.
La timeline ya no necesita fingir que todas sus barras significan lo mismo.
La presentación puede ser más precisa porque el runtime público también lo es.
Publicar ya no es exportar HTML sin contexto
La idea fuerte del día es esta:
una página publicada no es un volcado estático del editor.
Es una composición de capacidades.
Unas páginas necesitan diagramas.
Otras necesitan resaltado.
Otras solo necesitan tipografía, jerarquía y silencio.
El runtime correcto no es el más grande.
Es el más pequeño que todavía conserva el significado del contenido.
Ahí es donde publicar deja de ser “servir markdown” y empieza a parecerse a diseñar una lectura pública de verdad.
Parte de mis notas de producto y plataforma. Sigue el blog o escríbeme.