\u00bfM\u00f3vil? \u00bfWeb? Me da igual.<\/h2>\n
Supongamos que queremos crear una aplicaci\u00f3n que utilice el m\u00f3dulo React<\/a> biblioteca. Esta biblioteca se puede utilizar para construir aplicaciones web y aplicaciones m\u00f3viles con React nativo. Los mecanismos l\u00f3gicos de la aplicaci\u00f3n, como autorizaci\u00f3n, computaci\u00f3n, filtrado datos<\/a> etc., se puede hacer con ganchos React. La cuesti\u00f3n es que estos hooks pueden ser compartidos por ambas versiones de la aplicaci\u00f3n - web y m\u00f3vil. Gracias a esta opci\u00f3n, tenemos los siguientes ahorros:<\/p>\n Para resumir este p\u00e1rrafo - no es que una base de c\u00f3digo impulsar\u00e1 todas las versiones de la aplicaci\u00f3n, aunque podemos dividir el c\u00f3digo compartido y utilizarlo en cada en hacer que el proceso de desarrollo<\/a> realmente m\u00e1s r\u00e1pido.<\/p>\n Conclusi\u00f3n - si quieres construir una aplicaci\u00f3n web y una aplicaci\u00f3n m\u00f3vil al mismo tiempo, considera la librer\u00eda React que puede compartir un c\u00f3digo base en la versi\u00f3n m\u00f3vil y web de la aplicaci\u00f3n.<\/p>\n Hace unos a\u00f1os, al hablar del backend, probablemente pocos imaginar\u00edan que su mantenimiento podr\u00eda ser posible con la ayuda de un lenguaje como JS<\/strong>. El desarrollo de esta lengua es asombroso y sus frutos pueden recogerse hasta el d\u00eda de hoy.<\/p>\n \u00bfDe qu\u00e9 estoy hablando? Si contratas al Desarrolladores JS<\/strong>resulta que pueden escribir no s\u00f3lo el frontend de la aplicaci\u00f3n, sino tambi\u00e9n el backend, es decir, ser responsables del procesamiento de datos en el servidor, la comunicaci\u00f3n con la base de datos, diversos tipos de integraciones, etc. \u00bfTodav\u00eda dudas o no est\u00e1s convencido de este lenguaje? \u00a1No hay raz\u00f3n para tener esta actitud! Backend con JS <\/strong> se puede implementar de dos formas populares - en un modo extensible y configurable, que express.js nos puede proporcionar, y en un modo estructurado usando el patr\u00f3n DI - nest.js.<\/p>\n Ambas soluciones son extremadamente populares y alimentan muchas aplicaciones de producci\u00f3n cuyos propietarios son \"gigantes tecnol\u00f3gicos\" en su sector. Creo que han madurado lo suficiente como para convencerte de que elijas cualquiera de ellas.<\/p>\n \u00bfA\u00fan no es suficiente? Al igual que ocurre con el c\u00f3digo compartido entre aplicaciones web y m\u00f3viles, el backend puede compartir recursos tanto con las primeras como con las segundas. La palabra clave es TypeScript<\/a> - entre otras cosas, nos permite compartir un c\u00f3digo base, es decir, una definici\u00f3n de tipos de datos com\u00fan a todas las plataformas.<\/p>\n Con aplicaciones creadas \u00fanicamente en el JavaScript<\/a> <\/strong>\/ TypeScript<\/strong> stack usando monolith, tenemos un mont\u00f3n de l\u00edneas de c\u00f3digo ahorradas, que tendr\u00edamos que duplicar en lenguajes de programaci\u00f3n nativos. Por otro lado, al utilizar el mismo lenguaje en todos los frentes, podemos compartir una enorme cantidad de l\u00f3gica entre todas las aplicaciones, lo que definitivamente acelerar\u00eda el tiempo en el que se puede construir una aplicaci\u00f3n concreta. \u00bfNo suena genial?<\/p>\n Resulta que las tecnolog\u00edas para crear aplicaciones de navegador son estupendas para mantener las aplicaciones que utilizamos en su forma de escritorio: un buen ejemplo puede ser Slack. Slack es una aplicaci\u00f3n utilizada para equipo<\/a> comunicaci\u00f3n: adem\u00e1s de la mensajer\u00eda est\u00e1ndar, cuenta con muchas funcionalidades diferentes y varios tipos de integraciones externas. Todo ello la convierte en una de las aplicaciones m\u00e1s populares utilizadas principalmente en el sector inform\u00e1tico.<\/p>\n Resulta que Slack tambi\u00e9n utiliza tecnolog\u00edas web (y, por tanto, JavaScript) para construir la interfaz de su aplicaci\u00f3n. La base que hace posible ejecutar este tipo de aplicaciones en el escritorio es el electr\u00f3n. Crear interfaces gr\u00e1ficas utilizando tecnolog\u00edas web hace que sea mucho m\u00e1s f\u00e1cil, r\u00e1pido y, en general, posible desarrollar aplicaciones para diferentes plataformas al mismo tiempo.<\/p>\n Por la parte frontend de la aplicaci\u00f3n, no hay ilusi\u00f3n de que JS <\/strong>es el \u00fanico y exclusivo lenguaje que potencia el ecosistema aqu\u00ed. Por el momento, no hay alternativas viables que puedan sustituir esta parte de la aplicaci\u00f3n (aunque creo que WebAssembly puede sorprendernos en el futuro). As\u00ed que, hablando de la madurez de JS en el frontend, no cabe duda de que es el \u00fanico real.<\/p>\n Hablando del backend, muchos desarrolladores pueden parecer escandalizados o negar inmediatamente que JS sea adecuado como lenguaje de programaci\u00f3n en el backend. Sin embargo, hay que analizar la cuesti\u00f3n objetivamente.<\/p>\n Muchos proveedores de servicios en la nube ofrecen SDK que permiten utilizar directamente nube<\/a> m\u00e9todos. Curiosamente, una de las pesta\u00f1as m\u00e1s populares, justo al lado de C#, Go y Java<\/a>es Node.js<\/a>. Resulta que esta plataforma es ideal para escalar y construir aplicaciones basadas en microservicios<\/a> o arquitectura sin servidor. Conclusi\u00f3n - JS es uno de los lenguajes m\u00e1s populares para desarrollar aplicaciones basadas en microservicios\/arquitectura sin servidor. En las pantallas de abajo, podemos ver que la sant\u00edsima trinidad (Google Computing Services, AWS<\/a>, Azure<\/a>) de los proveedores de nube nos permite crear aplicaciones utilizando nodo<\/a>.js.<\/p>\n En cuanto al ecosistema node.js, probablemente todo el mundo est\u00e9 familiarizado con una biblioteca llamada express.js - es una herramienta simple y directa que permite definir rutas y luego alimentarlas con datos apropiados que han sido debidamente procesados en el lado JS. Es m\u00e1s, el patr\u00f3n utilizado entre las solicitudes HTTP gestionadas en express.js se ha convertido en uno de los m\u00e1s populares en todo el ecosistema y es una especie de patr\u00f3n para varias otras bibliotecas que utilizan, por ejemplo, la arquitectura sin servidor.<\/p>\n Conclusi\u00f3n - JS es un lenguaje lo suficientemente maduro como para poner todas las cartas sobre la mesa y construir tanto frontend como backend. Adem\u00e1s, es un lenguaje bastante fresco que se integra f\u00e1cilmente en las arquitecturas de aplicaciones modernas. Es genial que un programador que conozca un lenguaje pueda dominar ambos lados (full stack) de una aplicaci\u00f3n.<\/p>\n Pues bien, el motor m\u00e1s utilizado para ejecutar c\u00f3digo JS es el v8, potenciado por el lenguaje C++. Este motor desarrollado por Google est\u00e1 dedicado a ejecutar aplicaciones para plataformas web. Una cosa interesante es que este motor no interpreta el c\u00f3digo JS. En su lugar, hace lo que se llama \"JIT\" - \"compilaci\u00f3n justo a tiempo\". Gracias a ello, no tenemos que interpretar el c\u00f3digo JS l\u00ednea por l\u00ednea, simplemente lo compilamos y lo ejecutamos. Es incluso m\u00e1s r\u00e1pido y nos da unos resultados de rendimiento realmente buenos.<\/p>\n \u00bfEs JS lo bastante justa en cuanto a rendimiento? S\u00ed, lo es. Mientras mantengas tus algoritmos lo suficientemente justos, no hay ning\u00fan problema en utilizar JS en el lado del servidor. La otra cosa es mantener tu c\u00f3digo lo m\u00e1s as\u00edncrono posible. Con estas pr\u00e1cticas tu c\u00f3digo puede manejar peticiones paralelas sin ning\u00fan problema. No tienes que preocuparte del intercambio de tecnolog\u00eda por el rendimiento - especialmente cuando la arquitectura de la aplicaci\u00f3n es escalable.<\/p>\n Ya he hablado en detalle del rendimiento y los puntos de referencia en este art\u00edculo. <\/p>\n Bueno, son decenas de opiniones de que el lenguaje JS se comporta raro en algunos casos y manejarlo es algo que te har\u00e1 explotar la cabeza durante el proceso de desarrollo. No puedo estar de acuerdo \ud83d\ude42 Al igual que cualquier otro lenguaje, tiene varios patrones \/ comportamientos que no son elegantes, pero con la comprensi\u00f3n de c\u00f3mo funcionan y cu\u00e1les son sus objetivos el desarrollo de aplicaciones con JS no es desagradable.<\/p>\n Especialmente el comentario \"as\u00edncrono\" justo antes de JS hace temblar a algunos desarrolladores. Es dif\u00edcil de entender cuando no se ha tenido ninguna experiencia con ello. Sin embargo, es una parte de JS que nos permite construir soluciones modernas de forma sencilla. Echemos un vistazo a los websockets: al estar basados en eventos, cada una de las unidades conectadas, el usuario y el servidor, pueden emitir y recibir eventos en paralelo. Si el c\u00f3digo que alimenta esta aplicaci\u00f3n es lo suficientemente as\u00edncrono y no bloquea el hilo principal, podemos manejar f\u00e1cilmente miles de peticiones en poco tiempo.<\/p>\n Comparemos JS y PHP<\/a> con el contexto de los websockets. PHP es un lenguaje de programaci\u00f3n s\u00edncrono, por lo que resolver temas de websockets da muchos quebraderos de cabeza. Podemos ver que PHP obtiene patrones de JS para construir aplicaciones backend interactivas que pueden utilizar tecnolog\u00edas modernas, como webrtc o websockets.<\/p>\n Reuniendo todos los p\u00e1rrafos, podemos afirmar algunos hechos:<\/p>\n JavaScript<\/strong> es un lenguaje que puede utilizarse para crear todo tipo de aplicaciones, desde web hasta m\u00f3viles o de escritorio; Para dar mi opini\u00f3n, ciertamente sesgada, aprovechar la opci\u00f3n de JavaScript de reutilizar el mismo c\u00f3digo en todos los frentes disponibles es algo que sin duda acelerar\u00e1 el desarrollo de aplicaciones y reducir\u00e1 el n\u00famero de desarrolladores implicados en el mantenimiento del backend de aplicaciones escritas en otras tecnolog\u00edas. Como confirmaci\u00f3n, recordemos el hecho de que un gran n\u00famero de los llamados gigantes inform\u00e1ticos siguen este patr\u00f3n y comparten bastante c\u00f3digo base entre plataformas. A pesar de las diferentes opiniones sobre este lenguaje, hay que tener en cuenta el hecho de que las estad\u00edsticas de uso y satisfacci\u00f3n con el uso de JS <\/strong>crecen de a\u00f1o en a\u00f1o, y sus desarrolladores pueden engancharse f\u00e1cilmente a la tendencia del full stack.<\/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>\n\n
Pero, \u00bfqu\u00e9 pasa con el backend?<\/h2>\n
\u00bfPuede JS impulsar aplicaciones de escritorio?<\/h2>\n
\u00bfEs JS lo suficientemente maduro?<\/h2>\n
![\"Node.js](\"\/app\/uploads\/2024\/05\/zrzut-ekranu-2021-08-24-o-12.13.12.png\" "\\"Inicio")
<\/p>\n![\"Comparaci\u00f3n](\"\/app\/uploads\/2024\/05\/zrzut-ekranu-2021-08-24-o-12.13.25.png\" "\\"Arranques")
<\/p>\n\u00bfEs JS lo suficientemente r\u00e1pido?<\/h2>\n
\u00bfNo es JS una rareza entre otros idiomas?<\/h2>\n
M\u00e9zclalo todo<\/h2>\n
\nLas aplicaciones escritas en JS pueden compartir varios fragmentos de c\u00f3digo entre s\u00ed, como los responsables del formato de los datos o los tipos en Typescript;
\nGracias al crecimiento de la web, el rendimiento que ofrece JS es lo suficientemente bueno como para optar por el desarrollo de aplicaciones tanto frontend como backend;
\nGracias a su dise\u00f1o poco habitual, JavaScript es compatible con infraestructuras de aplicaciones modernas, como websockets y WebRTC;
\nSi contrata a un desarrollador debidamente cualificado, podr\u00e1 aprovechar su potencial en todos los frontend disponibles que funcionan con este lenguaje;
\nJS es un lenguaje que lleva varios a\u00f1os subiendo en las listas de popularidad, y no hay indicios de que esto vaya a cambiar en modo alguno.<\/p>\n![\"Consultor\u00eda](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/p>\n