Durante muchos años, table no era solo una etiqueta HTML más. Era prácticamente una herramienta de maquetación. Antes de que CSS madurara de verdad, construir layouts complejos sin tablas era bastante más duro, inconsistente y limitado.

Cuando las CSS “no existían” y todo era campo: tablas para columnas, tablas para bloques, tablas anidadas para casi cualquier cosa. No era especialmente elegante, pero durante una época resolvía problemas reales.

Hoy el contexto es otro. table no está muerta, pero ya no cubre la maquetación general como antes. Ahora tiene un papel mucho más concreto. Y eso es bueno.

---

Cuando table era media web

Antes de Flexbox y Grid, alinear elementos y construir estructuras complejas era bastante más incómodo. Había floats, hacks, clears, anchos fijos, cálculos manuales y bastante sufrimiento.

En ese escenario, las tablas daban algo muy valioso:

• filas y columnas alineadas de forma natural
• alturas que se coordinaban solas
• cierta estabilidad entre navegadores
• una forma relativamente predecible de encajar bloques

El problema es que una tabla de maquetación no describe bien el contenido. Si usas <table> para construir una portada, un hero o una galería, el HTML dice una cosa y la interfaz está haciendo otra.

Ahí es donde CSS fue ganando terreno hasta cambiar por completo las reglas del juego.

---

table no ha muerto: simplemente ha vuelto a su sitio

La etiqueta <table> sigue siendo importante cuando el contenido es realmente tabular.

Es decir, cuando tienes:

• columnas con significado
• filas comparables entre sí
• encabezados claros
• relación entre celdas por intersección

Ejemplos claros:

• comparativas de características
• horarios
• listados de precios
• datos financieros
• tablas de métricas
• resultados, rankings o inventarios

<table>
  <thead>
    <tr>
      <th>Framework</th>
      <th>SSR</th>
      <th>SSG</th>
      <th>Islands</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Astro</td>
      <td>Sí</td>
      <td>Sí</td>
      <td>Sí</td>
    </tr>
  </tbody>
</table>

Aquí usar table no solo está bien: es la opción correcta.

---

Cuándo no deberías usar table

No uses table para:

• maquetar una landing
• repartir tarjetas por la pantalla
• hacer un header con logo y navegación
• montar un dashboard moderno
• alinear botones o bloques sueltos

En todos esos casos, hoy tienes herramientas mejores, más semánticas y mucho más flexibles.

El criterio útil es este:

• si comparas datos, piensa en table
• si distribuyes componentes, piensa en flex o grid

---

Flexbox: el gran ganador del día a día

Si me obligaras a quedarme con una sola herramienta de layout para la mayoría de interfaces comunes, sería Flexbox.

Y aquí sí te corrijo un poco, pero en tu intuición hay bastante verdad: Flexbox no gana porque sea más potente que Grid en todo, sino porque resuelve muchísimos problemas reales con menos fricción mental.

Flexbox es especialmente bueno para layout unidimensional:

• una fila
• una columna
• repartir espacio entre elementos
• alinear en un eje principal y otro secundario
• crear grupos de botones, barras, cards simples, headers, stacks y menús

.nav {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 1rem;
}

Por qué Flexbox es tan importante

• se aprende antes
• se usa más a diario
• encaja muy bien en componentes pequeños y medianos
• resuelve alineaciones que antes eran un dolor
• sirve tanto para horizontal como para vertical

Por eso en frontend moderno Flexbox suele ser el caballo de batalla.

---

Grid: más complejo, pero mejor en layouts bidimensionales

Grid no sustituye a Flexbox. Juega otra partida.

Grid destaca cuando necesitas pensar el layout en filas y columnas a la vez:

• una portada editorial
• un panel con áreas bien definidas
• galerías
• dashboards
• bento layouts
• estructuras donde la posición importa de verdad

.dashboard {
  display: grid;
  grid-template-columns: 240px 1fr 320px;
  gap: 1.5rem;
}

Lo que hace muy bien Grid

• controlar columnas y filas explícitamente
• construir áreas complejas
• reorganizar el layout con precisión
• pensar la página como sistema, no solo como una fila de piezas

Lo menos amable de Grid

• tiene más conceptos
• exige visualizar mejor la estructura
• en componentes pequeños puede ser más de lo necesario

Por eso Grid no es “mejor que Flexbox” en general. Es mejor cuando el problema es realmente bidimensional.

---

Entonces, ¿Flexbox o Grid?

Una regla simple:

• usa Flexbox para componentes y distribución en un eje
• usa Grid para layouts generales o estructuras en dos ejes

Y lo normal no es elegir uno para toda la web. Lo normal es combinarlos:

• Grid para la estructura global
• Flexbox para lo que pasa dentro de cada bloque

.page {
  display: grid;
  grid-template-columns: 280px 1fr;
}

.sidebar-nav {
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
}

Esa mezcla es probablemente la más habitual en interfaces modernas.

---

¿Y display: table?

Aquí suele haber confusión, porque no es lo mismo:

• usar la etiqueta HTML <table>
• usar una capa CSS como display: table

display: table hace que un elemento se comporte visualmente como una tabla, aunque no lo sea semánticamente.

.fake-table {
  display: table;
  width: 100%;
}

.fake-row {
  display: table-row;
}

.fake-cell {
  display: table-cell;
}

¿Para qué sirve?

Puede servir para reproducir comportamientos concretos de una tabla sin usar la etiqueta real.

¿Cuándo merece la pena?

Pocas veces.

Hoy normalmente:

• si el contenido es tabular, usa <table>
• si el layout no es tabular, usa Flexbox o Grid

display: table queda en una zona rara: ni te da la semántica real de una tabla ni suele ser mejor opción que los sistemas modernos de layout.

No está prohibido. Simplemente ya casi nunca es la mejor primera opción.

---

¿Se sigue usando table en emails?

Sí. Y bastante.

El mundo del email HTML vive bajo reglas mucho más antiguas que la web moderna. Los clientes de correo tienen compatibilidades muy irregulares, motores de render distintos y soporte desigual para muchas propiedades CSS.

Por eso en email siguen siendo comunes:

• layouts con tablas
• estilos inline
• estructuras más rígidas
• menos confianza en Flexbox o Grid

En una web moderna, maquetar toda la interfaz con tablas sería volver atrás. En un email, en cambio, las tablas siguen siendo una herramienta práctica y realista.

Ese detalle importa porque evita dos errores:

• pensar que table está obsoleta para todo
• pensar que como aún sirve en emails, también debe servir para toda la maquetación web

No. Cada entorno tiene sus reglas.

---

Comparativa rápida

Por cierto… esto es una tabla ↓

Herramienta	Mejor para	Fortalezas	Limitaciones
table	Datos tabulares reales	Semántica correcta, relación clara entre filas y columnas	Mala opción para maquetación general
Flexbox	Layouts en un eje	Simple, versátil, ideal para componentes	Se queda corto si necesitas controlar filas y columnas a la vez
Grid	Layouts en dos ejes	Precisión, áreas complejas, estructura potente	Más complejo y a veces excesivo para piezas pequeñas
display: table	Casos muy concretos o legacy	Imita comportamientos de tabla	Rara vez mejora a table, flex o grid

---

Regla práctica para no complicarte

Si dudas, piensa así:

1. ¿Estoy mostrando datos comparables? Usa table.
2. ¿Estoy alineando o repartiendo componentes en una fila o columna? Usa Flexbox.
3. ¿Estoy definiendo una estructura completa con filas y columnas? Usa Grid.
4. ¿Estoy maquetando un email HTML? Las tablas siguen teniendo bastante sentido.

Con eso aciertas la mayoría de veces.

---

Conclusión

table no ha muerto. Lo que ha pasado es que ha dejado de usarse como solución universal de maquetación y ha vuelto a un terreno donde sigue siendo muy buena: los datos tabulares y algunos entornos especiales como el email HTML.

Flexbox es probablemente la herramienta más útil del día a día porque resuelve muchísimos problemas con poco coste mental. Grid entra cuando la estructura es más ambiciosa y necesitas controlar dos dimensiones de verdad. Y display: table existe, sí, pero hoy casi siempre hay una opción mejor.

---