Saltar al contenido
Framework Ecosystems LabsUn contrato, muchos ecosistemas, la misma prueba.

Por qué sí y por qué no — El primer componente#

⬅️ Clase 082 · 📚 Parte 6

Por qué sí Por qué no Qué se paga
React Un componente es una función: nada que registrar, nada que declarar No trae nada más — enrutado, datos y estructura los eliges tú Un ecosistema de decisiones que el equipo mantiene
Vue Las propiedades se declaran, y esa lista sirve al framework y a quien lee El componente vive dentro de una aplicación: hay más ceremonia que en React Un archivo .vue que necesita compilador para ser JavaScript
Angular Todo está declarado: selector, plantilla, entradas — nada se adivina Es el más pesado de arrancar y el que más conceptos pide antes de la primera línea Dos compilaciones, una aplicación entera y errores como NG0401
Svelte El componente se traduce a código: no viaja un motor al navegador Sin compilar no es JavaScript válido; el paso no es opcional Depender de una herramienta de construcción para todo, incluso para probar
SolidJS Sintaxis de React con un modelo que ejecuta el componente una sola vez Ese parecido engaña: las propiedades se leen, no se desestructuran Un ecosistema mucho más pequeño que aquel al que se parece
Lit El componente es una etiqueta HTML estándar: funciona sin el framework alrededor Renderizarlo en el servidor exige fingir un navegador entero El DOM en la sombra, que aísla estilos y complica todo lo demás
Alpine.js Un atributo y ya hay componente: cero construcción, cero instalación No renderiza en el servidor y el escapado es tuyo, con dos contextos distintos Que la seguridad dependa de quién escribe la plantilla
htmx El componente vive donde ya están los datos: el servidor No hay componente en el cliente, así que no hay estado local ni interactividad sin ida y vuelta Una petición por cada cambio, y el escapado a cargo del servidor

🧭 Lo que este contrato no puede probar#

💡 Lo que hay que llevarse#

La palabra «componente» significa siete cosas distintas en estas ocho tecnologías, y confundirlas es el origen de la mitad de las discusiones sobre interfaces.

Lo que sí es común es la idea que Frost llamó diseño atómico [frost-atomic-design]: una pieza con un límite claro, que recibe datos por fuera y produce marcado. Todo lo demás —clase o función, compilado o interpretado, cliente o servidor— es cómo cada ecosistema implementa esa idea.

Y hay una correlación que merece quedarse, porque predice cosas:

Quien controla el momento de interpolar, escapa por ti. Las seis tecnologías que renderizan escapan solas; las dos que solo colocan marcado, no. No es una diferencia de calidad ni de madurez: es una consecuencia de dónde ocurre el trabajo. Si eliges un modelo donde el marcado se construye a mano, el escapado pasa a ser responsabilidad tuya en cada línea, y eso hay que saberlo el primer día y no el de la auditoría.

Fuentes#