DEV Community

Cover image for Demasiados frameworks de JS, pero por qué?
Jose Ventura
Jose Ventura

Posted on

Demasiados frameworks de JS, pero por qué?

A menudo se puede pensar que ya es repugnante la cantidad de frameworks que hay en el mercado, o pensar que algunas personas han quedado fuera del tren de la tecnología y están en camino de quedarse sin trabajo pronto.

¿Por qué cada día nace una nueva tecnología que cambia el método y la forma de trabajar con las interfaces web?

La razón más simple es que es difícil agregar o cambiar ciertas características a los frameworks ya establecidos.

Como comenta Fernando Herrera en su podcast semanal “Devtalles”, todos los frameworks nuevos salen con la intención de incluir algo nuevo, además de partir de una buena base de código que pueda escalar e implementar algunas técnicas que les permitan ser más eficientes y ocupar menos espacio y recursos. Increíble, ¿verdad?

Aunque, sinceramente, si me preguntas cuál considero que le ha ido mejor, yo te respondería: Astro.

¿Por qué José???👀

Tantos nuevos frameworks que han implementado funcionalidades interesantes e ingeniosas que incluso han sido llevadas a los frameworks más utilizados, o esos mismos frameworks están buscando una manera de implementar su propia solución para no quedarse fuera de la tendencia.
Y para ti sólo Astro lo ha hecho bien ¿verdad? ¡Exactamente! 😉

Otros frameworks han incluido características valiosas para mencionar, como lo hizo SolidJS con las señales que todos quieren o tienen (incluso ya están en camino de estandarizarse en ES). Qwik con capacidad de reanudación, reducción absolutamente sorprendente de Javascript al cargar un sitio web, y así sucesivamente.
¿Qué pasa con todo esto?

Lo único que veo, en mi opinión, es que han trabajado horas y horas con la intención de presentar algo nuevo y llamar la atención, sólo para que grandes frameworks lo recojan e implementen. Y crean el marco sólo con la intención de tener un lugar donde ejecutar estas nuevas funciones.

No parece que tengan la intención de que su marco sea el que se utilice.

Además, todo parece deberse a la falta de comunicación entre los desarrolladores, la envidia y el egoísmo con el que sólo quieren conseguir algo primero y que mencionen su nombre. Para que así puedan ocupar un lugar en la historia como desarrolladores de esa característica y no estar a la sombra de un equipo.

El factor más grave para ellos está en las librerías de npm. Para React, Angular y Vue por ejemplo, existen bibliotecas con todo tipo de soluciones. Quieres implementar algo en tu sistema, buscas un poquito y ahí está, una biblioteca para solucionarlo.

Ahora, los reto a encontrar una solución de este tipo para nuevos frameworks. Antes de que te canses de buscar, mejor tómate ese tiempo y crea algo tú mismo, para contribuir a la comunidad del framework y aprender cosas nuevas😉.

Este punto débil no permite la aceptación masiva de cada nuevo framework que vemos, porque una empresa no se va a permitir volver a desarrollar cientos de funcionalidades que ya tienen bibliotecas que utilizan en sus proyectos. Sólo para utilizar esta nueva tecnología con el objetivo de reducir tiempos de desarrollo, añadir algo nuevo o estar a la moda.

Por eso vemos que los sistemas bancarios siguen utilizando Cobol desde hace años, pero ese es otro tema.

Y aquí es donde me preguntas, José, ¿dónde está la que dices que fue la mejor idea en el momento de su creación? Ah si, estás hablando de Astro, este quedará pendiente para el próximo blog (no quiero extenderme tanto, lo siento😅).

Cada semana traeré contenido interesante y variado, de desarrollo, personal, lo que se me ocurra. ¡Apoye este contenido para seguir obteniendo lo mejor de él!🍀

Top comments (0)