La guerra de los frameworks de JavaScript terminó

Y hay un solo ganador.

Participantes: la guerra entre frameworks ha sido un tema candente en la comunidad de JS. Backbone, Sencha y otros desaparecieron. Sorprendentemente, jQuery todavía tiene una comunidad grande. También hubo casos como Angular que no salieron tan bien.

jQuery: el participante más antiguo. Se hizo popular porque solucionaba la compatibilidad entre navegadores. Pero era difícil escalar aplicaciones con él. Hoy ya no es dominante y no es la mejor opción.

AngularJS: ya está en modo LTS y retirado. Fue un gran salto dentro del ecosistema de frameworks y mucha gente lo extraña. Como ya no recibe mantenimiento, ya no es un participante.

Angular:

• Apareció para competir con React. Por los problemas de rendimiento y solidez de AngularJS, muchos programadores veían a React con envidia. Angular intentó modernizar AngularJS y aprovechar las mejoras de ES6 para competir con React.
• Su mayor dificultad fue la curva de aprendizaje pesada. Requería muchos conceptos. Heredó la curva de aprendizaje de AngularJS, pero añadió nuevas dificultades como RxJS o la inyección jerárquica de dependencias (DI).
• Otra preocupación fue que incumplió muchas promesas. Por ejemplo, V2 podía crear páginas con server-side rendering (SSR) de forma sencilla, pero al 2022/2/24 no podía funcionar sin JS.
• El mayor problema fue la fragmentación y las actualizaciones de versión. Actualizar de versión era tan difícil que los usuarios no querían asumir el riesgo. Eso se ve en las estadísticas del sitio de npm.

VueJS:

• Fue la respuesta para desarrolladores que querían algo con mejor rendimiento que AngularJS, más estable que Angular y más fácil de usar. En su sistema de plantillas, Vue era muy cercano a AngularJS, así que mantenía su simplicidad mientras tomaba fuerza de React.
• Pero VueJS tuvo problemas serios en las versiones 1 y 2. No manejaba bien los arrays y sus autores culparon a JavaScript por haber elegido mal el algoritmo de actualización. Dependía de librerías como Vuex o Redux.
• Ese problema se resolvió en la versión 3. Sin embargo, culpar a otros por sus propios errores no encajó bien en la comunidad.

SvelteJS:

• Un competidor en crecimiento. Está haciendo grandes promesas. Afirma que su principal ventaja es traducir componentes a un lenguaje imperativo. Según ellos, eso es mejor que las declaraciones de React.
• Es sencillo de usar. Pero los componentes que resultan de esa traducción imperativa no son tan predecibles como parecen. En algunos casos no pueden detectar correctamente los cambios. En ese caso, el estado puede corromperse y la vista puede no actualizarse correctamente. Esta cuestión ha generado mucha preocupación, por lo que resulta difícil justificar proyectos de SvelteJS, igual que ocurrió antes con VueJS.

StencilJS:

• En sentido estricto, no es un framework. Permite escribir componentes y convertirlos a otros frameworks. Actualmente puede convertir a Angular, React, Vue y Web Components.
• Plantea la pregunta: ¿es código que se parece al de otros frameworks? (ver texto original)

Mitosis:

• Quizá nunca hayas oído hablar de él, pero es la razón por la que se escribió este artículo. Es el framework más reciente creado por Misko Hevery, quien creó Angular.
• Tiene el mismo objetivo que StencilJS. Traduce componentes a muchísimos frameworks.
• Del mismo modo, plantea la pregunta: ¿es código que se parece al de otros frameworks? (ver texto original)

React:

• Es uno de los frameworks más antiguos guardados en el repositorio de npm, con más de 10 años. Ha cambiado mucho, pero en su mayoría sigue siendo compatible con versiones anteriores. Todos los cambios fueron para mejor. Algunas personas dicen que hacer React con hooks lo convirtió en un framework mucho mejor.
• Su mejor cualidad no está en los hooks ni en las funciones visibles, sino en lo contrario. Aplica los estándares modernos de JS y JSX. Esto ya no es un framework. Tal vez nunca lo fue. React se esforzó tanto por los estándares que terminó eliminándose a sí mismo del código del usuario.

Entonces el ganador es...

• JSX. También React, pero sobre todo la filosofía detrás de React. React en sí es una librería. Además, puede reemplazarse por muchas otras librerías como Preact o React Native. Si se mira de cerca, StencilJS o Mitosis son muy similares a React, y eso no es coincidencia.
• "El mejor framework es el que se elimina a sí mismo del código del usuario"
• React aprovecha mucho JS y JSX. El código del usuario no depende de React. El mismo código puede funcionar en otros frameworks sin grandes cambios.
• Por eso, sin ninguna duda, React es el ganador de la guerra de frameworks.
• Porque no es un framework dentro del código del usuario.

[piriri11]

Lo importante es llevar a la práctica al máximo eso que dice el tío Bob de "no te cases con un framework"; si escribes el código así, ¿no podrías disfrutar desarrollando ya sea con React, Vue o Angular?

[polygon]

¿Qué perspectiva tiene marko js? Me interesó recientemente porque cuenta con el respaldo de eBay, pero ni siquiera se menciona en el texto original...

[minhoryang]

React de “ha cambiado mucho, pero en su mayor parte sigue siendo compatible con versiones anteriores” — yo no tuve mucho esa experiencia de compatibilidad.
Angular de “fragmentación y actualizaciones de versión” — pero en esa parte sí tuve muchas experiencias fluidas.

[roxie]

Creo que JSX debería clasificarse no como un framework, sino como una especificación. Entiendo lo que quiere decir, pero la introducción es demasiado larga para algo que podría omitirse y, sobre todo, el título es clickbait. Está usando un estilo de redacción que termina rebajando la calidad del propio texto.

[xguru]

¡Gracias por el resumen y los buenos comentarios~! Creo que este tipo de conversaciones les serán de mucha ayuda a otras personas ;)

[plastic041]

En general, me parece que es un artículo bastante extraño.

Primero, la parte de Svelte.
Al ver el texto original, dice que es un problema que al actualizar un arreglo usando algo como array[0] += 1 no se refleje el cambio, pero en la documentación oficial de Svelte también se indica que los arreglos deben reasignarse para que se actualicen, y desde el principio en React tampoco se puede actualizar un arreglo de esa manera, ¿no?

También está la parte de VueJS.
Habla de las desventajas de Vue comparándolo con Angular, pero no entiendo qué sentido tiene decir que Vue no es muy bueno poniendo un código de Angular que sí funciona junto a un código de Vue que no funciona.

[pppqqq]

Creo que es una crítica totalmente válida. La diferencia entre reasignación y mutación puede resultar confusa para quienes están empezando, y tanto Svelte como Vue, al usar una sintaxis separada aunque similar a JavaScript, merecen críticas cuando hay partes que no funcionan como uno esperaría.

En particular, Vue actualiza el estado cuando ocurre un set mediante proxies; a primera vista parece fácil, pero hay mucho margen para caer en trampas, así que yo también empatizo profundamente con que se critique ese aspecto.

React es mucho más libre frente a este problema: el estado no se actualiza mediante reasignación, sino llamando explícitamente a una función como setUpdate, de modo que ofrece actualizaciones unidireccionales dentro del estándar de JavaScript. Por eso, desde el inicio no se da el problema de confundir cambiar solo una parte de un arreglo con una reasignación, por ejemplo.

[tequila]

Es un comentario un poco tangencial, pero en Vue 3 sí se soportan de forma reactiva las actualizaciones de arreglos de ese tipo, así que me da la impresión de que este artículo solo critica duramente a versiones antiguas de Vue y pasa por encima del tema de manera algo superficial... ^^;; De hecho, que en React este tipo de actualización no funcione no es para nada una desventaja menor, pero siento que ese rasgo no se señala ni se examina como corresponde, jaja.

[tenshi]

También hubo muchos comentarios en el texto original, y vi bastantes que señalaban varios problemas.

[riddler]

Me confundió la parte de StencilJS y Mitosis con la explicación de "¿es código parecido al de otros frameworks?", así que revisé el texto original, y al parecer lo que preguntan es si el código que usan esos dos frameworks no se parece al que uno ha visto en otros frameworks.

Creo que lo escribieron con la idea de que la forma de escribir código es parecida a la de React.

[jjpark78]

La evaluación sobre VueJS es demasiado dura..

La dependencia de redux tampoco es algo de lo que React esté completamente libre..

Si hablamos del tamaño de la base de usuarios, es cierto que React es abrumadoramente el número 1,

pero tampoco se puede decir que sea un proyecto inferior a React desde el punto de vista técnico.

[cckn1985]

¿No será que el punto principal que se está discutiendo aquí sobre VueJs, más que la dependencia de bibliotecas externas, es la actitud de trasladarle a JS la responsabilidad por los problemas que ellos mismos generaron?

De todos modos, creo que sí es cierto que la opinión pública sobre vueJS no es buena.

Si van a leer el texto completo, la parte donde se menciona la dependencia de Vuex y Redux también se refiere a que, para resolver los problemas que surgieron en VueJS 2, bibliotecas como Vuex y Redux eran "imprescindibles".

[jjpark78]

Esto ya aparece en varios comentarios del texto original, pero

cuando aumenta la complejidad, tanto en Vue como en React, las librerías de manejo de estado/caché como Redux terminan siendo todas "imprescindibles".

Entonces, en el texto original se señala esto como una desventaja de VueJS, pero en React omitieron mencionarlo de forma "intencional".

El comportamiento de la comunidad no me parece algo muy importante desde mi punto de vista..

[road4one]

En React, redux no es obligatorio. Puedes gestionar el estado usando contextAPI o useReducer, entre otras opciones. No creo que eso sea una base para decir que React es mejor que Vue, de todos modos.

[cckn1985]

Sí jaja, en general no parece ser un buen artículo.

El autor ya decidió la conclusión de antemano y está menospreciando a los otros frameworks para llegar a esa conclusión.