astro.build

Empieza por la experiencia predominante del usuario

Utiliza las alternativas enlazadas en esta página como candidatas y, después, compáralas con el tipo de experiencia que realmente necesitas ofrecer. Astro está especialmente alineado con proyectos donde leer, navegar, comparar o descubrir contenido importa más que mantener un estado continuo en el navegador.

Elige la afirmación que mejor se ajuste a tu proyecto:

• La mayor parte de la página debe funcionar como HTML. Da más peso a Astro porque el contenido estático no requiere JavaScript del lado del cliente de forma predeterminada.
• La interacción pertenece a varios controles diferenciados. Comprueba si esos controles forman islas claras que puedan hidratarse de forma independiente.
• Casi todas las regiones comparten estado activo en el cliente. Evalúa detenidamente las opciones centradas en aplicaciones porque los límites de las islas podrían aportar menos valor.
• La publicación en Markdown necesita una estructura coherente. Compara las colecciones de contenido validadas y compatibles con TypeScript de Astro con el modelo de contenido de cada opción enlazada.
• El equipo debe reutilizar componentes de interfaz existentes. Comprueba la integración pertinente, el coste del runtime y las expectativas de mantenimiento en lugar de asumir que todos los sistemas de componentes se combinan libremente.

Compara una página representativa

Utiliza la misma página real y los mismos requisitos para cada alternativa enlazada. Una plantilla inicial demuestra que una herramienta funciona, pero no revela si su arquitectura se ajusta a tus necesidades más difíciles de contenido, interacción y autoría.

Pregunta para la decisión	Pruebas que recopilar
¿El contenido esencial llega sin ejecución en el navegador?	Inspecciona el HTML entregado
¿Puede separarse la interacción de forma clara?	Traza los componentes y el estado compartido en el cliente
¿Cuándo debe activarse cada control?	Prueba las necesidades de carga inmediata, durante el tiempo de inactividad y basada en el viewport
¿Es mantenible el flujo de trabajo del contenido?	Modela una colección real con requisitos de validación
¿Qué llega al navegador?	Revisa el código de los componentes, los runtimes, los archivos multimedia y los scripts de terceros
¿Puede el equipo gestionarlo con confianza?	Compara las convenciones, la depuración y el mantenimiento continuo

Aplica una tabla de evaluación interactiva

Para cada opción enlazada, marca cada criterio como muy adecuada, viable o con mucha fricción. Pondera los criterios según el proyecto en lugar de limitarte a contar las puntuaciones.

1. Contenido disponible como HTML útil.
2. Claridad de los límites de interacción.
3. Compatibilidad con el enfoque de interfaz preferido por el equipo.
4. Contenido estructurado y validación.
5. Coste del estado compartido del lado del cliente.
6. Requisitos de integración y despliegue.
7. Duplicación del runtime y mantenimiento de dependencias.
8. Accesibilidad con patrones de interacción reales.

Si Astro sigue siendo una opción, prueba una isla grande o exigente en lugar de limitarte a un artículo estático. Si una alternativa enlazada sigue siendo una opción, sométela a los mismos archivos multimedia, navegación, scripts de terceros y flujo de trabajo editorial para que la comparación refleje las condiciones de producción.