Construí una aplicación en todos los frameworks frontend
Otra lectura excelente de Alicia. ¡Por favor, consulta los enlaces a continuación para encontrar más de su gran trabajo! 
TL;DR
¿Qué framework deberías usar? Bueno, eso depende de lo que estés desarrollando y cuáles sean tus prioridades. Pero hice una herramienta de comparación rápida para ayudarte a encontrar el stack perfecto para tu proyecto. Ver: Stack Match.
¿Solo quieres los números? También construí la misma aplicación usando 10 frameworks diferentes y los comparé. Consulta el repositorio framework-benchmarks para ver el código fuente y los resultados.
Metodología
¿Por qué estoy escribiendo esto? Bueno, veo muchos artículos que promocionan frameworks específicos o critican otros. Pero raramente el autor corta a través del hype y proporciona una comparación imparcial entre todas* las opciones.
Mi objetivo aquí es esbozar brevemente la propuesta única de valor de cada framework, cuándo deberías usarlos, cubriendo sus pros, contras y también mencionar mis opiniones.
Hablando de imparcialidad, necesito construir la misma aplicación en cada framework para que esto sea una prueba justa (¡que he hecho!). Pero ese es el primer problema, ya que las aplicaciones simples no demuestran completamente las capacidades de un framework en escenarios del mundo real. Como tal, también he incluido proyectos reales/en vivo que he construido con cada uno. Todos estos están listos para producción, con un número decente de usuarios activos y/o descargas (en realidad, un total de 1 millón de usuarios anuales y 50k estrellas en GitHub).
Dado que literalmente hay cientos de frameworks frontend, para mantener este post razonablemente, solo voy a cubrir los “top” 10 más recientes y mejores, y nos estamos enfocando principalmente en la experiencia del desarrollador (pero también se incluirán benchmarks de rendimiento).
¡Suficiente charla, vamos a ello!
React
React está en todas partes, alimentando más de 1.3 millones de sitios web, y utilizado por muchas (probablemente la mayoría) de las grandes empresas. Ha existido durante más de 12 años, respaldado por Meta, con herramientas muy maduras y un ecosistema grande. Así que no es de extrañar que se haya convertido en la opción predeterminada para muchos equipos. Es muy estable con una excelente compatibilidad hacia atrás (que en realidad también es uno de sus inconvenientes, ya que hay múltiples formas de hacer todo).
Pero no es perfecto. Añade mucho código repetitivo, haciéndolo mucho más verboso de escribir que frameworks como Svelte o Vue. El DOM virtual también añade una sobrecarga de rendimiento bastante significativa (en realidad, solo la reconciliación, pero es fácil de usar incorrectamente), la memoización es a menudo manual, las características concurrentes aún no son muy maduras, y los bundles tienden a ser grandes, incluso con mucho tree shaking.
Pros
- Muchos empleos disponibles
- Ubicuo, ecosistema enorme, buen soporte comunitario, respaldo corporativo
- Flexibilidad, construir cualquier cosa desde SPAs, correos electrónicos hasta aplicaciones móviles (más o menos)
Contras
- Aunque es rápido para comenzar, React puede ser lento de dominar correctamente, y hay muchas cosas que pueden confundir a los principiantes
- Menos eficiente de forma predeterminada, y el DOM virtual añade una sobrecarga
- Bastante pesado en código repetitivo, especialmente cuando se compara con Svelte o Solid
Mis opiniones
Si estás haciendo vibe coding, React tiene una gran ventaja, ya que hay una enorme cantidad de código para que los AIs consuman. Del mismo modo, si estás buscando un trabajo, no puedes equivocarte aprendiendo React ya que ha sido el framework dominante para la mayoría de empresas durante bastante tiempo.
Dicho esto, personalmente no me gusta React: es lento, pesado, aburrido y a veces un poco más complejo que otros frameworks.
Me resulta frustrante tener que hacer tanto trabajo manual para mejorar el rendimiento de una aplicación. Hace que el código sea verboso y propenso a errores. Aunque las herramientas para desarrolladores son muy buenas, inspeccionar la salida compilada aún puede ser bastante doloroso. Paso mucho más tiempo con la documentación abierta, ya que la especificación de React es bastante grande y amplia.
Lo que construí
Vue
Vue es un framework progresivo, lo que significa que puede usarse para todos los tipos de aplicaciones, desde solo un script de inserción para mejorar HTML hasta una SPA completa con SSR. Como Svelte, utiliza SFCs (componentes de archivo único) donde cada archivo .vue agrupa plantilla, lógica y CSS con alcance. Para la reactividad, Vue utiliza Proxies de ES2015 para rastrear dependencias y actualizar solo lo que es necesario, sin necesidad de memoizar manualmente.
Pros
- Realmente fácil, intuitivo y rápido de aprender y usar
- Componentes de archivo único agradables con estilos con alcance
- Reactividad de grano fino fácil y seguimiento de dependencias eficiente
- Herramientas oficiales para enrutamiento, estado y SSR (incluidas por separado)
Contras
- Aunque Vue puede escalar muy bien, se necesita mucha reflexión al usarlo para un proyecto muy grande
- Hay algunas inconsistencias (como las dos APIs competidoras Options vs Composition)
- Algunas advertencias de reactividad (por ejemplo, .value en refs, la desestructuración pierde reactividad)
Mis opiniones
Vue podría verse como el framework Goldilocks, sentándose cómodamente entre la flexibilidad de React y la estructura de Angular. Vue es lo suficientemente rápido, lo suficientemente divertido y lo suficientemente probado en batalla, pero no destaca realmente de manera asombrosa en ninguna de estas áreas.
El sistema de reactividad usando Proxies es genuinamente impresionante. Cambia una propiedad de datos y todo lo que depende de ella se actualiza automáticamente. Y, el ecosistema es mucho más fuerte de lo que la gente se da cuenta.
Elegí Vue para Dashy, porque tenía todo lo que necesitaba, pero también es increíblemente fácil, para que los colaboradores pudieran agregar sus propios widgets y características, sin una curva de aprendizaje pronunciada.
Lo que construí
Svelte
Svelte ha sido clasificado consistentemente como uno de los frameworks más amados, y por una buena razón. Es simple, rápido, ligero y realmente divertido. La reactividad está integrada directamente en el lenguaje, sin hooks, proxies o la rareza de useEffect; solo asigna a una variable y reacciona.
A diferencia de muchos otros frameworks, no envía un runtime ni utiliza un DOM virtual. En su lugar, los componentes se compilan en JavaScript vanilla altamente optimizado en tiempo de compilación. Entonces, no hay sobrecarga de runtime, no hay código de framework en tu bundle y obtienes un rendimiento casi nativo en el navegador. Ah, y la salida compilada es sorprendentemente legible por humanos.
Pros
- Bundles más pequeños y rápidos que React o Vue
- Modelo de reactividad realmente simple
- Menos código repetitivo que cualquier otro framework
- Las animaciones están integradas
Contras
- El ecosistema aún es más pequeño que React/Vue
- SvelteKit aún está madurando y podría ser ligeramente menos estable que Next/Nuxt
- Para equipos grandes o proyectos enormes, las herramientas no son tan robustas
Mis opiniones
Construir en Svelte me hace feliz. Me gusta que sea moderno, intuitivo y rápido, pero también que sus SFCs estén muy alineados con las tecnologías web principales: solo HTML, CSS y JS.
Svelte ha sido mi opción preferida para construir cosas rápidamente y hermosamente, mientras envío un resultado eficiente. Pero he encontrado que si no presto atención a la estructura, un proyecto grande puede volverse desordenado rápidamente.
No necesariamente lo usaría para un enorme panel de control empresarial donde tienes 15 equipos trabajando en la misma base de código, React o Angular aún ofrecen más previsibilidad, estabilidad y herramientas en esos escenarios.
Lo que construí
Angular
Probablemente estés pensando que Angular es un framework antiguo, solo utilizado en aplicaciones heredadas y entornos corporativos. Y sí, lo último es correcto, pero las versiones recientes (sí, sigue siendo muy activo) tienen algunas características impresionantes, que lo hacen una opción muy viable en 2025.
A diferencia de otros frameworks, Angular viene con todo incluido: enrutamiento, formularios, HTTP, pruebas, internacionalización, animaciones, SSR y más, todo mantenido oficialmente e integrado profundamente. No hay necesidad de armar un stack.
Pero puede ser verboso de escribir.### Ventajas
- TypeScript desde el inicio
- Muy estable en la actualidad
- Todo lo necesario para aplicaciones grandes está incluido
- Compilación AOT de plantillas, lo que la hace más rápida que algunas
- Muchos empleos en el mundo corporativo
Desventajas
- Curva de aprendizaje más pronunciada (RxJS, inyección de dependencias, módulos, zonas)
- Verboso en comparación con frameworks como Svelte o Vue
- Comunidad más pequeña que React/Vue en código abierto o tutoriales
- Menos flexible — construyes a la manera de Angular
Mis Pensamientos
Angular no es cool, pero es consistente, potente y escalable. No hay realmente nada faltante, así que no necesitas hacer npm install de un montón de dependencias de terceros solo para hacer tareas comunes.
No me pareció complicado ponerse al día, pero había mucho que necesitaba aprender de la documentación, especialmente con la sintaxis de plantillas, definiciones de componentes, directivas, inyecciones, etc. Lo único con lo que luché fue inicialmente hacer funcionar la hidratación para mis rutas SSR. Todo lo demás fue muy fluido.
Consideraría Angular nuevamente para aplicaciones grandes, donde la estabilidad, estructura y soporte a largo plazo importan, pero no tanto para aplicaciones más pequeñas.
Lo que construí
Lit
Lit es un framework súper ligero para construir Web Components basados en estándares, construido alrededor de APIs modernas del navegador (como Custom Elements y Shadow DOM) y es excelente cuando quieres componentes de UI reutilizables y agnósticos del framework.
Ventajas
- Utiliza Web Components nativos y estándares comunes
- Eficiente, sin DOM virtual, y las actualizaciones son mínimas y directas
- Funciona con cualquier framework (o ninguno)
Desventajas
- Sintaxis verbosa: @click, ?disabled, .value, etc.
- Los componentes basados en clases se sienten obsoletos
- SSR es experimental y difícil de configurar
- El ecosistema y los recursos de aprendizaje son de nicho
Mis Pensamientos
Personalmente encontré que escribir componentes Lit era un poco como retroceder a los viejos tiempos de React. Los componentes están basados en clases, e incluso los componentes más simples son bastante verbosos, con una cantidad considerable de código repetitivo.
La sintaxis de expresión divertida (para atributos) me atrapó varias veces, olvidando preceder las propiedades con un ., booleanos con un ?, escuchadores de eventos con un @ y todos los valores con un $
La renderización en servidor aún es experimental, y fue muy difícil hacerla funcionar en un proyecto independiente de Vite + Lit.
Debido a que son web-components y usan Shadow DOM, cada componente está totalmente aislado. Lo que tiene sus pros y contras, pero si no estás acostumbrado a esto, podrías notar que cosas como tu reset de CSS global o estilos no funcionan como esperarías.
Lo que construí
Marko
Marko es un lenguaje declarativo y un framework web de alto rendimiento, construido y mantenido por eBay.
Ventajas
- Sintaxis concisa, con opciones abreviadas para markup, sin necesidad de importar componentes/etiquetas personalizadas
- SSR e isomórficos componentes de UI bastante fáciles
- Enrutamiento fácil con Marko run
Desventajas
- Muy de nicho y soporte limitado — definitivamente no podrías colaborar en código con Marko
- Increíble cuando funciona, pero si enfrentas un problema, tendrás que sumergirte en el código fuente de Marko y resolverlo tú mismo
- Documentación faltante (p. ej. Low level APIs está simplemente vacío)
Mis Pensamientos
Realmente me gustó lo que Marko estaba intentando hacer, el templating tenía mucho sentido. Pero se siente ligeramente como usar un framework del futuro, pero en el pasado, es tanto futurista como anticuado al mismo tiempo.
El principal inconveniente, y es uno grande — fue que hay información muy limitada en línea. La documentación es escasa, no puedes simplemente buscar en github para encontrar ejemplos, las herramientas de IA no tienen idea de los conceptos básicos de Marko, hay soporte comunitario limitado e incluso el intellisense es muy limitado. Así que, si enfrentas problemas, tendrás que sumergirte en el código fuente de Marko tú mismo. Y tiene algunos quirks, que a menudo no están documentados (p. ej. si usas class {} en una vista o layout de nivel superior, toda la interactividad simplemente se romperá, sin un mensaje de error).
Así que por mucho que me encantó trabajar con Marko, no siento que pueda recomendarlo para ningún proyecto serio, simplemente porque la comunidad es tan pequeña. Tampoco creo que vaya a ser mantenido activamente por mucho más tiempo, ya que la actividad del repositorio ha estado disminuyendo durante los últimos años, y eBay parece ser los únicos mantenedores principales.
Lo que construí
jQuery
¿Pensaste que me olvidaría de nuestro viejo amigo jQuery?! Casi 20 años desde su primer lanzamiento, y jQuery sigue presente en más del 70% de los 100k sitios principales (eso está en gran medida correlacionado con el uso de WordPress).
Ese número ahora está comenzando a disminuir, y con buena razón — para aplicaciones simples, muchas de las características de jQuery ahora se pueden hacer nativamente con JavaScript moderno, y para aplicaciones más complejas los frameworks modernos simplemente hacen el trabajo mucho mejor.
…pero a principios de este año, y por primera vez desde 2016, se publicó una nueva versión principal, jQuery 4.
Ventajas
- Sin herramientas de compilación, gestores de dependencias, transpiladores, etc.
- Está muy probado en batalla
- Útil para soportar navegadores (muy) antiguos que no tienen las características más nuevas de JavaScript
Desventajas
- No hay mucho que jQuery pueda hacer, que no se pueda hacer con JavaScript vanilla
Dicho esto, no pude traerme a mí mismo a construir una aplicación moderna usando jQuery. Aunque lo he usado (hace muchos años) para revision-quizzes, intern-magnet y user-monkey.
Alpine
Te permite fácilmente agregar reactividad a HTML renderizado en servidor (sin SPAs, sin hidratación, sin SSR). Es ideal para mejoras de UI simples sin una configuración de compilación completa.
Lo que es inteligente es cómo Alpine se mantiene fuera de tu camino. El HTML sigue siendo legible, el JavaScript es mínimo, y todo se degrada gracefully si Alpine no carga. Es mejora progresiva hecha correctamente — la página funciona sin JavaScript, pero se vuelve interactiva cuando carga.
La sintaxis se lee naturalmente: x-on:click="searchWeather()", x-text="temperature", x-bind:class="{'active': isExpanded}". Es declarativa como plantillas Vue pero vive directamente en el HTML. Las actualizaciones reactivas suceden automáticamente cuando modificas los datos.
Ventajas
- Cero configuración — funciona con solo un ``` tag
- Ideal para pequeñas mejoras en SSR o sitios estáticos
- Sintaxis fácil y declarativa inspirada en Vue
- Mejora progresiva por defecto
Contras
- No está diseñado para aplicaciones grandes — carece de enrutamiento, gestión de estado, SSR, etc
- Herramientas y estructura limitadas para equipos grandes
- Puede volverse desordenado si metes mucha lógica en atributos HTML
Mis Pensamientos
Alpine encuentra un punto muy dulce para la interactividad simple. Cuando no quieres un framework completo y solo necesitas modales, menús desplegables, interruptores o comportamiento ligero del lado del cliente, entonces Alpine es perfecto.
Lo que construí
Solid
Solid se parece mucho a React a primera vista, pero bajo el capó es completamente diferente y mucho más rápido. En lugar de un DOM virtual, Solid utiliza reactividad de grano fino (similar a los internos de Svelte y Vue) para actualizar solo lo que realmente cambió. El resultado es paquetes diminutos, casi ninguna sobrecarga de tiempo de ejecución y un excelente rendimiento.
Aún escribes JSX, aún defines componentes, aún usas hooks, pero todo es reactivo por defecto. Las Señales (createSignal) reemplazan useState, los cálculos se ejecutan automáticamente cuando sus dependencias cambian, y nada se re-renderiza innecesariamente. Se siente familiar, pero sin las partes incómodas de React.
Pros
- Extremadamente rápido: sin DOM virtual, reactividad de grano fino, paquete diminuto
- Se siente familiar, si vienes de un trasfondo de React
- Muy escalable, para interfaces altamente interactivas grandes
Contras
- Ecosistema y comunidad mucho más pequeños
- SSR es sólido, pero frameworks full-stack como SolidStart aún están madurando
- JSX.
Mis Pensamientos
Solid se siente como “lo que React podría haber sido” si se diseñara hoy. Obtienes la ergonomía de React sin el baile de re-renderizado, hacks de memoización o trampas de rendimiento. Genuinamente se siente ágil para construir. Pero como aún es relativamente nicho, no encontrarás tantas bibliotecas, tutoriales u ofertas de trabajo.
Lo que construí
Astro
Astro es menos un framework y más un constructor de sitios orientado al contenido.
Astro construye tu sitio estáticamente y usa apenas nada de JavaScript por defecto. La interactividad proviene de “islas”, que son componentes aislados diminutos, escritos con cualquier framework de tu elección (como React, Svelte, Vue, Solid, etc), y se usan para rociar interactividad que se hidrata del lado del cliente, solo cuando sea necesario.
Pros
- Mejor opción para SEO (SSG, SSR), más todos los beneficios de la interactividad solo cuando la necesites.
- Soporte de MD/MDX de primera clase
Contras
- Es bueno para sitios con mucho contenido, pero definitivamente no es una buena opción para SPA/aplicaciones interactivas
Mis Pensamientos
Para un blog, documentación, un sitio de marketing, o un proyecto “principalmente estático con algunos bits interactivos”, honestamente es difícil de superar. Me encanta Astro, su DX y flexibilidad, pero tiene un caso de uso muy específico.
Lo que construí
Van.js
Van es un framework de UI reactivo diminuto (en serio, diminuto - menos de 1kb) Grab 'n Go sin DOM virtual, sin herramientas de construcción, sin dependencias y sin abstracciones pesadas. Funciona enteramente con nodos DOM simples, usando primitivas reactivas simples (van.state, van.derive) para actualizar la UI cuando los datos cambian. Se siente más cercano a “JavaScript vanilla reactivo” que a un framework tradicional.
La API es intencionalmente mínima. Creas componentes como funciones que devuelven elementos DOM, vinculan estado directamente en tus llamadas similares a marcado, y eso es… prácticamente todo. Sin JSX, sin compilador, sin empaquetador, sin hooks de ciclo de vida sofisticados. Solo JavaScript y APIs de DOM con un toque de reactividad.
Pros
- Extremadamente pequeño y rápido, perfecto para pequeños widgets o componentes incrustados
- Sin paso de construcción; funciona en una etiqueta
<script> - Modelo de reactividad muy simple
- Fácil de aprender si estás cómodo con JavaScript vanilla
Contras
- Definitivamente no es adecuado para aplicaciones más grandes
- Sin abstracción de componentes más allá de funciones, sin sistema de plantillas, sin sistema de eventos
- Increíble para reactividad simple, pero se vuelve engorroso rápidamente para cualquier cosa más grande
Lo que construí
Qwik
Qwik es bastante salvaje. Replantea completamente cómo funcionan las aplicaciones web haciendo algo llamado “reanudabilidad” - tu página se carga instantáneamente sin JavaScript, luego componentes individuales se despiertan solo cuando interactúas con ellos. Es como tener una página web que está dormida hasta que la pinches.
Pros
- TTFB súper bajo, con <1KB JS en carga inicial
- Se escala muy bien para aplicaciones grandes con rutas complejas o contenido dinámico
- Ergonomía de desarrollador familiar, con JSX + Vite + signals + enrutamiento basado en archivos
Contras
- SSR es requerido, no puede funcionar puramente del lado del cliente
- Curva de aprendizaje más pronunciada, y algunos conceptos (como reanudabilidad y serialización) pueden parecer ajenos a los desarrolladores al principio
- La depuración puede ser compleja, porque la lógica se divide entre límites de servidor
Mis Pensamientos
Si estás trabajando en una aplicación muy grande o compleja, que también necesita ser altamente performante, entonces Qwik es una opción natural. Claro que tiene una comunidad más pequeña, una curva de aprendizaje más pronunciada, y es más complejo que otras opciones, pero cuando cada byte importa entonces este es solo el precio a pagar.
Lo que construí
Espera - ¡No es una prueba justa si construiste aplicaciones diferentes!
Ese es un punto muy justo, ¡pero no te preocupes!
Para comparar estos frameworks de manera más imparcial, también he construido una mini-aplicación idéntica en cada uno de ellos, y he hecho un benchmark de cada una para comparar el rendimiento.
Puedes verlo aquí: GitHub - Lissy93/framework-benchmarks: 🌈 The same app built in 10 different frontend frameworks. For automated performance benchmarking.
Hay un conjunto de pruebas compartidas para confirmar que cada aplicación cumple con requisitos idénticos, cada aplicación usa todos los mismos activos y estilos compartidos, y luego tengo un conjunto de scripts de benchmark de rendimiento que ejecutan todas las pruebas de rendimiento reales. Estos resultados se procesan y se colocan en la rama results, junto con algunos gráficos y resúmenes que están en el readme principal y en la página de inicio de framework-benchmarks.
Conclusión
Así que ahí lo tienes, 12 frameworks, 12 aplicaciones (y 12 años de dolor). Si estás intentando elegir un framework para tu próximo proyecto, consulta Stack Match la herramienta de comparación de frameworks.
Y si te gusta este tipo de contenido, considera seguirme 
Soy @Lissy93 en GitHub, y @lissy93 aquí en DEV. Construyo muchas herramientas para desarrolladores, aplicaciones de seguridad y privacidad y cosas auto-hospedables para Linux, que puedes ver en mi sitio https://010000010110110001101001011000110110100101100001.com (¡sí, un nombre de dominio realmente memorable!)
De todas formas, gracias por leer, ¡feliz codificación y feliz año nuevo!
Oh, y casi olvido - ¿cuál es el framework verdaderamente mejor? Bueno, ese tendría que ser obviamente [límite de caracteres alcanzado]