Las aplicaciones utilitarias de escritorio son cosa del pasado porque todo puede hacerse en un navegador. De hecho, las aplicaciones que necesitan utilizar APIs de bajo nivel que no est\u00e1n disponibles en el navegador tambi\u00e9n se escriben utilizando motores y lenguajes de navegador porque as\u00ed es m\u00e1s f\u00e1cil mantenerlas.<\/p>\n
Las aplicaciones m\u00f3viles pueden sustituirse f\u00e1cilmente por herramientas utilizadas para web<\/a> desarrollo - v\u00e9ase React<\/a> Nativo<\/strong>NativeScript. Adem\u00e1s, tenemos PWA, que \"imita\" f\u00e1cilmente el funcionamiento de las aplicaciones m\u00f3viles. Adem\u00e1s, los componentes que alimentan una aplicaci\u00f3n escrita en Vue<\/a><\/strong> o React<\/strong> puede compartir f\u00e1cilmente varios c\u00f3digo<\/a> elementos entre plataformas. <\/p>\n Tenemos que admitir una cosa: las aplicaciones web son actualmente una potencia que ser\u00e1 dif\u00edcil bajar a la planta baja. Como usuario, me veo utiliz\u00e1ndolas pr\u00e1cticamente en todas partes: comunic\u00e1ndome a trav\u00e9s de Slack, utilizando un editor de c\u00f3digo, haciendo presentaciones o incluso escribiendo un art\u00edculo en un blog.<\/p>\n Es dif\u00edcil predecir lo que ocurrir\u00e1 dentro de unos a\u00f1os. WebAssembly est\u00e1 entrando en juego, y permitir\u00e1 us<\/a> para trasladar las aplicaciones que requieren c\u00e1lculos m\u00e1s complejos al mundo de los navegadores. Un hecho, sin embargo, se mantiene sin cambios - es realmente dif\u00edcil encontrar un obst\u00e1culo para construir con el uso de tecnolog\u00edas web tal aplicaci\u00f3n que s\u00f3lo podemos so\u00f1ar. <\/p>\n Al grano: volvamos al pasado por un momento, antes de que aparecieran los primeros frameworks web m\u00e1s significativos y las aplicaciones se desarrollaran de forma imperativa. Cada mec\u00e1nica interactiva de una p\u00e1gina se manejaba manualmente y era responsable de una acci\u00f3n espec\u00edfica.<\/p>\n El mejor ejemplo que se puede citar es la biblioteca jQuery, en su momento una de las soluciones m\u00e1s populares para gestionar eventos sencillos. Con su ayuda se implementaron varios men\u00fas desplegables, transiciones, animaciones, calculadoras y mec\u00e1nicas similares.<\/p>\n Merece la pena mencionar que ya entonces se detectaron problemas en aplicaciones m\u00e1s complejas, en lugares en los que distintas partes independientes deb\u00edan, por ejemplo, reaccionar a un clic adecuado o a teclear algo. La mayor\u00eda de las aplicaciones no ten\u00edan un estado expl\u00edcito, y en su lugar eran rescatadas, por ejemplo, por los atributos de los elementos o las clases que ten\u00edan.<\/p>\n En aquel momento, estaba claro que el enfoque actual carec\u00eda de reactividad: una forma estructurada de que los componentes se comunicaran entre s\u00ed y compartieran, por ejemplo, su estado o distintos eventos, lo que facilitaba el mantenimiento de las aplicaciones y les permit\u00eda ofrecer una buena experiencia de usuario a bajo coste.<\/p>\n Con el tiempo, empezaron a aparecer en el horizonte los primeros frameworks front-end, destinados a estructurar la arquitectura de aplicaciones m\u00e1s complejas.<\/p>\n Estos frameworks se basaban principalmente en el patr\u00f3n MVC - algunos suger\u00edan un enfoque m\u00e1s manual, como Backbone.js, mientras que otros, como Knockout.js, se enganchaban en dos v\u00edas datos<\/a> encuadernaci\u00f3n.<\/p>\n Aun as\u00ed, se pod\u00eda pensar que escribir la aplicaci\u00f3n era m\u00e1s dif\u00edcil, requer\u00eda mucha m\u00e1s codificaci\u00f3n y no produc\u00eda necesariamente los resultados previstos ni compensaba el tiempo perdido en el desarrollo de la aplicaci\u00f3n.<\/p>\n La raz\u00f3n principal por la que encontrar la media \u00e1urea en el JS<\/a> ecosistema era dif\u00edcil era que era un poco una rareza entre conocidos lenguajes de programaci\u00f3n<\/a> que hace tiempo que tienen el camino allanado.<\/p>\n Y no quiero detenerme aqu\u00ed en cu\u00e1les han sido exactamente los caminos que han acompa\u00f1ado el desarrollo de los distintos frameworks a lo largo de la historia. Sin embargo, es importante se\u00f1alar una cosa - el tiempo de maduraci\u00f3n del ecosistema JS en los navegadores no fue f\u00e1cil y se enfrent\u00f3 a muchas pruebas.<\/p>\n Esta es la \u00fanica raz\u00f3n por la que hoy en d\u00eda podemos construir aplicaciones web y desarrollarlas de una manera muy f\u00e1cil y sin dolor.<\/p>\n En lugar de echar carne en el asador, como es habitual en Internet, echemos un vistazo a ambas bibliotecas, recabemos informaci\u00f3n sobre ellas y compar\u00e9moslas, tanto en la teor\u00eda como en la pr\u00e1ctica.<\/p>\n NOTA: La descripci\u00f3n de los mecanismos que funcionan en Vue <\/strong>se refiere espec\u00edficamente a la versi\u00f3n 2. La versi\u00f3n 3 introduce muchos cambios significativos, pero no es un competidor real de React<\/strong> por el momento, aunque s\u00f3lo sea por su madurez - Vue 3 fecha de lanzamiento: 18 de septiembre de 2020.<\/p>\n Dejemos una cosa clara: al profundizar en ambas bibliotecas, se puede ver que en realidad hay m\u00e1s similitudes que diferencias. Dejando a un lado la forma de utilizar las bibliotecas como tal - ambas tienen conceptos muy similares de c\u00f3mo funcionan. Ambas est\u00e1n impulsadas por un ecosistema similar y su uso no es diametralmente diferente.<\/p>\n \u25cf El diablo est\u00e1 en los detalles: cuanto m\u00e1s a menudo usamos una herramienta, mayores desventajas de sus diferentes soluciones notamos. Un buen ejemplo de ello puede ser la vinculaci\u00f3n bidireccional de datos, que se utiliza con mayor frecuencia en Vue<\/strong> como una propiedad v-model: a menudo facilita las cosas, se encarga de muchas cosas autom\u00e1ticamente y no requiere codificar soporte adicional para cambiar valores.<\/p>\n Sin embargo, hay casos en los que necesitamos hacer un seguimiento espec\u00edfico de un intento de cambio y reaccionar en consecuencia, en cuyo caso los componentes basados en v-model nos obligan a menudo a trastear con otros Vue<\/strong> mec\u00e1nica como la propiedad computada, haciendo que el efecto conseguido a menudo parezca mucho peor que con un enfoque manual;<\/p>\n \u25cf Otro aspecto interesante es JSX, que es una forma tan \"vaga\" de plantillas de contenido renderizado utilizando React<\/strong>. Tiene diferentes opiniones en la comunidad de desarrolladores.<\/p>\n Seg\u00fan mis observaciones, parece que los desarrolladores que utilizan un entorno distinto de JS, por ejemplo PHP<\/a> o C#, se inclinan m\u00e1s por las vistas de plantilla de forma que Vue<\/strong> lo hace.<\/p>\n En resumen - plantillas conocidas de Vue<\/strong> permiten definir vistas de una forma muy clara y elegante, mientras que JSX de React permite construirlas en muchos casos m\u00e1s r\u00e1pido, adaptadas a necesidades espec\u00edficas y a menudo requiere menos c\u00f3digo para construir diversas estructuras;<\/p>\n \u25cf Veamos tambi\u00e9n los ecosistemas de estas dos herramientas. En principio, podemos decir que no difieren en nada. Ambas se llaman bibliotecas por una raz\u00f3n: proporcionan lo m\u00ednimo para el soporte de aplicaciones web reactivas.<\/p>\n Mientras que el resto, relacionado con la comunicaci\u00f3n con API<\/a>, El flujo de datos, los componentes de la interfaz de usuario utilizados en las distintas subp\u00e1ginas son los denominados proveedores, es decir, bibliotecas externas que deben conectarse correctamente a la aplicaci\u00f3n. proyecto<\/a>. Es un poco como el mundo de Lego: si quieres construir un todo coherente, tienes que unirlo a partir de peque\u00f1os bloques individuales.<\/p>\n Esta alegor\u00eda se refiere precisamente a los componentes adjuntos, que son la fuerza de las aplicaciones creadas con React<\/strong> o Vue<\/strong>;<\/p>\n \u25cf Una cosa importante, especialmente para las personas que no tienen tanta experiencia en el entorno JS, es el nivel de entrada en una biblioteca en particular. En otras palabras - la complejidad de la herramienta, que consiste en el tiempo directo que necesita para pasar en la comprensi\u00f3n de su mec\u00e1nica.<\/p>\n Creo que hay una cosa que hay que afirmar inequ\u00edvocamente: en el caso de Vue<\/strong>es mucho m\u00e1s simple. Tenemos enlace de datos bidireccional, tenemos una plantilla elegantemente especificada que es enga\u00f1osamente similar a las soluciones en otros lenguajes, por ejemplo twig, y finalmente - no tenemos dolores de cabeza causados por el aprendizaje de teor\u00edas sobre el funcionamiento de los ganchos individuales y los casos en los que se deben utilizar mec\u00e1nicas espec\u00edficas.<\/p>\n Dejarse llevar directamente por la voz de la multitud no es precisamente una buena elecci\u00f3n. Sin embargo, un buen paso para tomar una buena decisi\u00f3n es analizar lo que dicen las personas que han interactuado con estas bibliotecas.<\/p>\n Y s\u00ed... estrellas en github <\/a> puede ser un indicador de hasta qu\u00e9 punto la comunidad de una biblioteca concreta participa en su desarrollo, c\u00f3mo la perciben los desarrolladores y si les interesa hacia d\u00f3nde se dirige. Ingenieros<\/a> que protagonizan un repositorio concreto suelen recibir notificaciones sobre nuevas versiones o cambios en el c\u00f3digo, lo que se traduce en su conocimiento directo de la biblioteca.<\/p>\n Sin embargo, el n\u00famero de estrellas en github no debe verse como un or\u00e1culo -no todos los desarrolladores a los que les gusta una herramienta dejar\u00e1n una marca-, sino que yo lo tomar\u00eda como un signo de la pura pasi\u00f3n que los desarrolladores sienten por un proyecto de c\u00f3digo abierto concreto.<\/p>\n Tendencias de Google <\/a> es un conocido servicio que permite estudiar el inter\u00e9s por determinados temas a lo largo del tiempo. Aunque no es un indicador racional de calidad o uso, puede proporcionar todo tipo de an\u00e1lisis.<\/p>\n Es f\u00e1cil ver que el transcurso de los \u00faltimos 5 a\u00f1os se ha perfilado de forma bastante similar cuando se trata de comparar a los dos protagonistas del art\u00edculo de hoy. La conclusi\u00f3n b\u00e1sica que puede extraerse del gr\u00e1fico es que React<\/strong> es superior en popularidad de b\u00fasqueda en relaci\u00f3n con su oponente.<\/p>\n Para que quede claro: estar en los primeros puestos de Google Trends no significa que una biblioteca sea mejor. Se trata de la popularidad de la multitud, como he mencionado antes - probablemente m\u00e1s personas han o\u00eddo hablar de esta herramienta, puede haber despertado m\u00e1s inter\u00e9s entre CTOs<\/a>, desarrolladores de software<\/a> <\/strong>o personas que s\u00f3lo quieren aprender una herramienta concreta.<\/p>\n \u00bfSe refleja este gr\u00e1fico en la realidad? En cierto modo, s\u00ed. En general, entre las personas encuestadas, son m\u00e1s las que muestran un conocimiento diverso y sofisticado de React<\/strong> que Vue<\/strong>. \u00bfQu\u00e9 opiniones puedes obtener hablando con estas personas? Intentar\u00e9 esbozarlo en el siguiente p\u00e1rrafo.<\/p>\n Estado de JS\u00a0<\/a> es un sitio web que encuesta anualmente a personas que trabajan en tecnolog\u00edas relacionadas con JavaScript. Su objetivo es recabar informaci\u00f3n de los desarrolladores sobre c\u00f3mo ven las herramientas con las que trabajan a diario.<\/p>\n Las preguntas abarcan herramientas individuales para distintos fines: por ejemplo, herramientas utilizadas en el front-end y en el back-end, pero tambi\u00e9n herramientas para pruebas, gesti\u00f3n del estado de la aplicaci\u00f3n, etc. Cada una de estas preguntas no es una simple respuesta de s\u00ed\/no, el sitio hace una serie de preguntas sobre la herramienta en s\u00ed, intereses, experiencias y una evaluaci\u00f3n general que se reduce a la frase \"\u00bfUtilizar\u00eda esta herramienta en futuros proyectos?\"<\/p>\n El sitio en s\u00ed te permite hacer un mont\u00f3n de an\u00e1lisis, comparar herramientas relevantes y, a veces, descubrir librer\u00edas menos conocidas a las que les est\u00e1 empezando a ir bien en el mundo del JS, ganando popularidad a la vez que disfrutan de un alto \u00edndice de \"felicidad de uso\". Le animo sinceramente a navegar por el contenido de este sitio.<\/p>\n Resumamos la secci\u00f3n con estad\u00edsticas. Analizar distintos tipos de gr\u00e1ficos puede ser a menudo una muy buena opci\u00f3n para comparar diferentes aspectos de determinados temas. Sin embargo, es importante tener en cuenta que seguir la voz de la multitud no ser\u00e1 necesariamente lo m\u00e1s inteligente. En su lugar, puede tomar una decisi\u00f3n informada utilizando algunas de las lecciones aprendidas de los an\u00e1lisis de gr\u00e1ficos.<\/p>\n Antes he mencionado el umbral m\u00e1s bajo de entrada a Vue<\/strong> - De hecho, permite centrarse un poco m\u00e1s r\u00e1pido en el desarrollo real de la aplicaci\u00f3n, utilizando la herramienta y reduciendo al m\u00ednimo el tiempo necesario para familiarizarse con el entorno, la mec\u00e1nica y los distintos casos de uso.<\/p>\n En general, mi opini\u00f3n es que Vue<\/strong> es m\u00e1s adecuado para las personas que a\u00fan no se han ocupado de las bibliotecas front-end. Sin duda, le permitir\u00e1 de una forma m\u00e1s alentadora obtener resultados satisfactorios en poco tiempo.<\/p>\n Sin embargo, dig\u00e1moslo en voz alta: la falta de conocimiento del lenguaje en el que utilizamos herramientas espec\u00edficas nos perjudicar\u00e1 tarde o temprano. Es un elemento insignificante para las cosas sencillas, pero a medida que aumente la complejidad de las aplicaciones creadas, ser\u00e1 cada vez m\u00e1s dif\u00edcil construir aplicaciones de forma decente sin un buen conocimiento de JavaScript<\/a>.<\/p>\n Realmente no me refiero a ser capaz de escribir algunas funciones sofisticadas, porque esta parte puede ser sustituida en gran medida por, por ejemplo, vendedores. Me refiero a algunos errores comunes que se pueden cometer en el lenguaje y no ser conscientes de que el comportamiento incorrecto no se debe al uso de la librer\u00eda, sino al uso del lenguaje. El error m\u00e1s com\u00fan que se manifiesta aqu\u00ed es la llamada inmutabilidad - es decir, el conocimiento del mecanismo de referencia en JavaScript.<\/p>\n No puedo sugerir qu\u00e9 librer\u00eda es mejor para los desarrolladores m\u00e1s o menos familiarizados con JavaScript. Pero s\u00e9 una cosa - si quieres tener una idea real de c\u00f3mo es el desarrollo con ambas herramientas \"desde dentro\" - intenta escribir aplicaciones en cada una de ellas. Esto te dar\u00e1 una idea, te permitir\u00e1 ver qu\u00e9 mecanismos te atraen m\u00e1s y cu\u00e1l es una mejor opci\u00f3n para ti.<\/p>\n Como he mencionado antes, ambas bibliotecas se nutren de ecosistemas similares y tienen puntos de vista parecidos sobre la creaci\u00f3n de aplicaciones con componentes peque\u00f1os. Ambas bibliotecas funcionan bien y no hay indicios de que vayan a desaparecer en un futuro pr\u00f3ximo. En consecuencia, las ofertas de empleo en ambas se mantendr\u00e1n a un nivel similar.<\/p>\n Las conclusiones son sencillas: utiliza lo que te convenga; acumula experiencia y eval\u00faa. Esto le ayudar\u00e1 a desarrollar un enfoque racional sobre si es mejor utilizar una u otra biblioteca en un proyecto concreto; adem\u00e1s, intente experimentar: nada ense\u00f1a tan profundamente como los errores cometidos en el pasado.<\/p>\n No es un secreto que no existe una media de oro que sea la mejor soluci\u00f3n para un proyecto concreto. Especialmente en el front-end, las herramientas utilizadas para construir aplicaciones envejecen r\u00e1pidamente y a menudo es dif\u00edcil encontrar los pies en las \u00faltimas tendencias.<\/p>\n Sin embargo, la elecci\u00f3n de la tecnolog\u00eda no es, o al menos no deber\u00eda ser, un cara o cruz sobre lo que encaja con las tendencias actuales. Por el contrario, deber\u00edamos orientarla hacia expectativas y supuestos concretos sobre la aplicaci\u00f3n que vamos a construir. Cada una de las bibliotecas comparadas tiene sus puntos fuertes y d\u00e9biles, que ajustados al caso de uso nos permitir\u00e1n hacer la elecci\u00f3n m\u00e1s razonable.<\/p>\n Una opci\u00f3n interesante pueden ser los res\u00famenes tecnol\u00f3gicos de las grandes empresas, que suelen describir sus casos de uso, c\u00f3mo iba o va el desarrollo de grandes aplicaciones y qu\u00e9 errores cometieron en el pasado. Tal vez encontremos entre ellos casos especialmente interesantes en el contexto de la elecci\u00f3n de una biblioteca para un proyecto concreto.<\/p>\n Las caracter\u00edsticas que debemos tener en cuenta para elegir las herramientas adecuadas para la aplicaci\u00f3n que se est\u00e1 construyendo son: el tiempo de desarrollo de la aplicaci\u00f3n, la facilidad de mantenimiento de aplicaciones<\/a>la complejidad de la aplicaci\u00f3n y la experiencia de los desarrolladores en el uso de bibliotecas espec\u00edficas.<\/p>\n Los desarrolladores son las personas que pasan m\u00e1s tiempo en las herramientas que comparo y son los que pueden ofrecerte los mejores consejos y ayudarte a hacer la mejor elecci\u00f3n en el gran choque de bibliotecas. Es durante el desarrollo de la aplicaci\u00f3n cuando se ven los diversos problemas que surgen directamente de la elecci\u00f3n de la tecnolog\u00eda, y tienen la mejor visi\u00f3n de qu\u00e9 cosas minan el uso de una herramienta concreta para unas funciones determinadas.<\/p>\n Como he mencionado antes - ambas bibliotecas no parecen estar desapareciendo de la mercado<\/a>al menos en los pr\u00f3ximos a\u00f1os. En lugar de tomar decisiones basadas en estad\u00edsticas y opiniones Pres\u00e9nteles lo que se espera de la aplicaci\u00f3n, de qu\u00e9 plazo disponemos para su entrega y permita un intercambio suelto de opiniones sobre lo que piensan de ambas soluciones antes de tomar la decisi\u00f3n final.<\/p>\n Las guerras en Internet suelen ser in\u00fatiles, o quiz\u00e1 lo sean en todos los casos. Siempre habr\u00e1 gente que se obstine en afirmar que su opci\u00f3n es mejor sin dar ning\u00fan argumento racional que confirme su decisi\u00f3n.<\/p>\n En lugar de cegarnos por opciones concretas, centr\u00e9monos en el an\u00e1lisis, intentemos sacar conclusiones adecuadas y utilic\u00e9moslas para ajustar o rechazar una soluci\u00f3n concreta.<\/p>\n Tal y como indica el t\u00edtulo, no pretendo coronar a ninguna biblioteca en particular como la cura para todos los males. En su lugar, se presentan algunas hip\u00f3tesis y se revelan los puntos fuertes y d\u00e9biles de ambas bibliotecas. He dado algunos consejos sobre lo que hay que tener en cuenta a la hora de elegir entre ellas para tomar una decisi\u00f3n acertada y no dejarse guiar por modas o personas al azar de internet.<\/p>\n Cada herramienta puede adaptarse bastante bien a las necesidades del proyecto. Ninguna de las dos desaparecer\u00e1 r\u00e1pidamente del mercado en los pr\u00f3ximos a\u00f1os. Ambas cuentan con potentes comunidades y bastante madurez, lo que nos demuestra que les va bastante bien.<\/p>\n La elecci\u00f3n final est\u00e1 en sus manos. No obstante, si tiene alguna duda o simplemente desea comentar su caso con The Codest<\/a> - no dude en ponerse en contacto con nosotros<\/p>\n M\u00e1s informaci\u00f3n:<\/b><\/p>\n Por qu\u00e9 deber\u00eda (probablemente) utilizar Typescript<\/a><\/p>\n \u00bfC\u00f3mo no matar un proyecto con malas pr\u00e1cticas de codificaci\u00f3n?<\/a><\/p>\nEl big bang en la realidad de Internet <\/h2><\/p>\n
Primeros pasos hacia marcos bien conocidos<\/h2><\/p>\n
Informaci\u00f3n b\u00e1sica y ligera comparaci\u00f3n<\/h2><\/p>\n
![\"React](\"\/app\/uploads\/2024\/05\/tabela-art-.jpg\")
<\/p>\n\u00bfQu\u00e9 dicen las estad\u00edsticas?<\/h2><\/p>\n
![\"vue](\"\/app\/uploads\/2024\/05\/bez-tytulu.png\")
<\/p>\n![\"react](\"\/app\/uploads\/2024\/05\/aaaaaabbb.png\")
<\/p>\n![\"Clasificaci\u00f3n](\"\/app\/uploads\/2024\/05\/1.png\")
<\/p>\n![\"estado](\"\/app\/uploads\/2024\/05\/2.png\")
<\/p>\n![\"React](\"\/app\/uploads\/2024\/05\/3.png\")
<\/p>\nLa mejor opci\u00f3n para desarrolladores<\/h2><\/p>\n
La mejor elecci\u00f3n para CTO<\/a> <\/h2><\/p>\n
\nde varias personas de Internet, tal vez una mejor opci\u00f3n sea simplemente hablar con los desarrolladores.<\/p>\nConclusiones<\/h2><\/p>\n