¿Sabías que las tablas HTML también tienen una API?

• La API de HTMLTableElement existe desde hace mucho tiempo, pero es una interfaz integrada para manipular tablas HTML que casi no se usa
• Con esta API se pueden crear y acceder directamente a tbody, thead, tfoot, caption, row y cell, sin necesidad de volver a renderizar toda la tabla cuando hay cambios
• El código de ejemplo muestra cómo convertir datos en arreglos anidados en una tabla y cómo agregar filas y celdas con insertRow() e insertCell()
• También permite varias operaciones, como acceder a celdas por índice con t.rows[1].cells[1] o agregar la última fila con insertRow(-1)
• El autor menciona que esta API tiene potencial para ampliar las capacidades de la tabla como estructura de datos, con espacio para añadir eventos o funciones extra, como en los formularios

---

Resumen de la API de tablas HTML

• La mayoría de los desarrolladores crean tablas con métodos del DOM (createElement, etc.) o insertando cadenas con innerHTML, pero esto último implica riesgos de seguridad
• HTML incluye una antigua API de HTMLTableElement con la que se puede manejar el cuerpo, filas, celdas, encabezado, pie, caption y summary de una tabla
• Esta API permite manipular elementos individuales sin volver a renderizar toda la tabla

Ejemplo de código: crear una tabla desde un arreglo

• En el ejemplo se convierte el siguiente arreglo anidado en una tabla
  • [['one','two','three'], ['four','five','six']]
• La tabla se crea con document.createElement('table'), y luego se agregan en bucle cada fila (insertRow) y cada celda (insertCell)
• El contenido de cada celda se asigna con innerText

Acceso y modificación de celdas

• Se puede acceder a las celdas de la tabla creada por índice
  • Ejemplo: t.rows[1].cells[1] → <td>five</td>
• También es posible eliminar o agregar filas y celdas
  • Ejemplo: t.insertRow(-1) agrega una fila al final
  • t.rows[2].insertCell(0) crea una nueva celda y luego se le asigna innerText = 'foo'

Limitaciones de la API

• Existen reglas de índices poco intuitivas, como insertRow(-1)
• No hay forma de crear directamente elementos TH, por lo que todas las celdas se manejan como TD

Posibles ampliaciones futuras

• El autor señala que crear tablas sigue siendo engorroso y propone revisar esta API para ampliar sus funciones
• Igual que a los formularios HTML se les añadieron formData o eventos change, menciona que también podrían incorporarse eventos o funciones avanzadas a las tablas
• Con ello, la tabla podría consolidarse no solo como una herramienta de layout, sino como una estructura de datos

[sonnet]

Como desarrollador con relativamente poca experiencia, me sorprenden los artículos que hablan como si hubieran "descubierto" una API que han estado usando desde el principio.

[GN⁺]

Opiniones de Hacker News

• Parece que mucha gente no leyó bien el artículo El punto central de este texto no es la etiqueta `` en sí, sino la interfaz DOM específica para tablas Por ejemplo, métodos como HTMLTableElement.prototype.insertRow() o HTMLTableRowElement.prototype.insertCell() son más intuitivos que createElement() o appendChild() Pero en las UI basadas en librerías como React, Svelte o Vue, casi ya no se usan este tipo de métodos También es interesante que, como en la sintaxis de HTML, aunque omitas thead, tbody o tfoot, se manejan automáticamente En los últimos 5 años sí he usado directamente .insertRow, .insertCell, .createTHead, .rows y .cells en scripts de demostración En cuanto al estilo de código, me parece más limpio usar for en vez de forEach y omitir el argumento del índice

  • Hoy en día los frameworks han reemplazado tanto la manipulación básica del DOM que da la impresión de que ya casi nadie conoce estos fundamentos Me acordé de cuando leía el artículo de C|net sobre la primera vez que se agregó la etiqueta ``. Ya se nota que estoy bastante viejo

• Recuerdo haber usado esta API hace como medio año, ya sea por la documentación de MDN o porque me la recomendó una IA Las propiedades rows y cells fueron muy útiles para implementar navegación con teclado Se puede ver un ejemplo relacionado en el código de ClickHouse

  • De lo que más me entristece en la web actual es de la gente que hace tablas con div No ordenan bien y, sobre todo, hay casos como M365 Admin donde la implementación de tablas es un desastre

• Va en una línea similar a la discusión sobre botones (hilo anterior) Desde hace unos 10 o 15 años, todo se fue convirtiendo en ``, y HTML empezó a usarse como una caja de herramientas de UI en lugar de marcado semántico

  • Eso pasa porque el DOM originalmente no se usa como documento semántico, sino como objetivo de renderizado El HTML semántico es una buena idea, pero en la práctica no es fácil esperar mucho de eso Además, los elementos semánticos traen estilos predeterminados, así que los desarrolladores terminan prefiriendo el neutro De hecho, creo que haber separado y `` también fue un error de diseño
  • Llevo más de 20 años usando HTML, pero por mi experiencia la mayoría todavía usa bastante bien las etiquetas con significado Claro, algunos hacen todo con div, pero en cosas como botones normalmente sí lo escriben correctamente
  • Creo que este cambio era inevitable La mayor parte del contenido web está centrado en marketing, así que las empresas quieren que se vea exactamente como ellas quieren Si existiera una web DocBook separada para documentación técnica, sería interesante porque el usuario podría aplicar sus propios estilos

• Usé esta API al hacer una herramienta para comparar imágenes de Stable Diffusion Como había muchas filas y columnas y había que recrear la tabla con frecuencia, actualizar el DOM era más lento que generar todo de una vez como cadena Supongo que es porque cada llamada a la API actualiza el DOM de inmediato

• Había una explicación de que “no hace falta volver a renderizar toda la tabla”, pero en realidad los métodos estándar del DOM ya funcionan así Aun así, está bastante bien que ayude a reducir la navegación tediosa por el DOM

  • Revisé el código de WebKit y, por dentro, corre la misma lógica, así que casi no hay diferencia de rendimiento

• También hace falta redescubrir la API de formularios HTML

• El problema de las tablas no es llenarlas de datos, sino que no traen funciones de búsqueda, ordenamiento ni filtrado

  • Me pregunto con qué se está comparando para decir eso No veo ninguna razón por la que esas funciones no se puedan implementar también en tablas

• No entiendo eso de que “esta API fue abandonada” Yo todavía la uso con frecuencia cuando hago tablas HTML

  • La expresión “abandonware” originalmente se usa en un contexto de licencias, así que aquí el título suena un poco exagerado Parece que el autor quería decir que esta API es un área antigua con espacio para expandirse Igual que con la API de formularios, creo que a las tablas se les podrían agregar funciones como ordenamiento y filtrado
  • Como hoy casi todos usan frameworks de UI declarativos como React o Svelte, estas API imperativas del DOM se están volviendo cada vez más de nicho
  • En una palabra, ahora estamos en la era de React

• El código de ejemplo es interesante, pero abrevia demasiado los nombres de variables y eso dificulta la lectura En vez de b, t, r, c, sería mejor usar nombres con significado

  • Al final este tipo de discusión se siente como una discusión de bicicletero, enfocada en detalles menores
  • En ámbitos pequeños, es natural usar nombres de variable cortos
  • Aun así, creo que los nombres de variable de una sola letra son una optimización equivocada Lo digo especialmente como alguien que usa Haskell
  • Más que los nombres cortos en sí, lo que confunde es mezclar índices como (ri, i) Si las variables cumplen roles parecidos, conviene unificar también la longitud de sus nombres
  • Una línea como let b = document.body; es especialmente difícil de leer Por ahorrarte unos bytes, solo aumentas la carga cognitiva