Filosofía
Componentes propios, en React y Vue, con CSS nativo.
Cada uno está construido desde cero, con la accesibilidad y el comportamiento que normalmente te da una librería ya hecha.
Todo esto parte de la idea de que entender la plataforma por debajo es lo que te deja construir con criterio, elijas el framework que elijas.
Por qué React y Vue
Casi todo el mundo enseña componentes en un solo framework. Aquí cada pieza vive en los dos: React y Vue 3, ambos con TypeScript. No es por duplicar trabajo porque sí, es para separar lo que importa de lo que cambia con la herramienta.
Un componente es, en el fondo, una API con unas props que entran, unos eventos que salen y un comportamiento accesible que cumplir. Eso no pertenece a ningún framework. React y Vue son dos formas de expresar la misma idea, y verlas lado a lado deja claro qué es esencia y qué es sintaxis. Por eso cada pieza acepta solo lo que dice su tabla de props, en React y en Vue.
De paso deja ver que puedo moverme entre stacks y migrar de uno a otro sin perder el norte, porque el diseño del componente manda y la herramienta es secundaria.
Por qué Astro
Enseñar componentes en dos frameworks a la vez necesita un sitio donde React y Vue puedan convivir en la misma página. Eso es justo lo que hace Astro con su arquitectura de islas.
Cada componente interactivo es una isla que se hidrata por su cuenta. El resto de la página es HTML estático, así que el JavaScript solo se carga donde hace falta y el contenido sigue siendo rápido y bueno para SEO.
Astro aquí es el pegamento mínimo: routing, el esqueleto HTML y los CSS globales. No impone su forma de hacer las cosas, deja que cada isla sea del framework que toque.
Por qué CSS nativo
Vengo de la maquetación, y el CSS es donde más cómodo me muevo. Por eso aquí no hay Tailwind ni SCSS, solo CSS nativo, que hoy ya cubre todo lo que antes pedía una herramienta extra.
Nesting, has(), container queries, color-mix(), light-dark(), animaciones ligadas al scroll. La plataforma se ha puesto al día, y dominarla a fondo vale más que esconderla detrás de una capa de utilidades.
El theming entero del portfolio sale de custom properties y light-dark(), sin una línea de JavaScript para los colores. Es la prueba de que entiendo la plataforma, no solo un framework montado encima.
Build vs buy
Construirlo todo desde cero no es una regla fija. En un producto real, muchas veces lo correcto es tirar de una librería headless y centrarse en el negocio.
La decisión depende del contexto, del tiempo que haya, de si el equipo apuesta por lo custom y de cuánto control necesites sobre el detalle. Más que una respuesta única, hay un criterio.
Lo que no cambia es que saber usar una librería es commodity. Entender qué resuelve por dentro (foco, teclado, accesibilidad) es lo que te permite decidir con cabeza. Aquí construyo esa parte yo mismo para que se vea.
Custom en la era de la IA
Construir un componente complejo costaba mucho tiempo. Con desarrollo asistido por IA ese coste cae en picado, y lo que antes llevaba horas hoy sale en un rato.
El matiz importa. La IA genera código, no criterio. Si no conoces el DOM, la accesibilidad o cómo funciona un focus-trap, no sabes si lo que te devuelve está bien o si rompe la navegación por teclado sin que nadie lo note. Las bases son lo que te deja dirigir y verificar.
Por eso los fundamentos valen más ahora, no menos. El valor se ha movido de escribir el código a saber qué es correcto. Este playground es eso mismo, la base puesta a trabajar.
