Enfoques para Programar (Panorama OnMind)

Decodificando la informática.
Advertencia! El presente texto tiene incidencia técnica, espero sea de su interés.

Para aclarar alguna noción esencial referente a las maneras o enfoques relacionados con la programación de computadores, sobretodo desde el punto de vista técnico de la interfaz, revisaremos algunos conceptos generales sobre software para el escritorio así como la arquitectura Web y el desarrollo para móviles, y finalmente plantear el camino tomado por OnMind en términos de nuestro objetivo y de allí los lenguajes de programación que usamos (Javascript and Kotlin, y quizás un poco de otro como ABCode).

Panorama de lenguajes para proyectos modernos

Si eres un reciente interesado en el desarrollo de software, espero que esta visión general te ilustre para animarte a empezar con un panorama enfocado. Veamos un panorama general inicial.

Agregamos también Typescript que, en principio, es un superconjunto de Javascript y suele funcionar como sustituto (compilando a Javascript) con las mismas tecnologías. Además HTML5 que es un lenguaje de marcado que se combina con Javascript y CSS3 (para estilos) en el navegador, también con PHP en un modo distinto (desde el servidor). Dart/Flutter no necesita HTML5 ni CSS3 y también está hecho para la interfaz de usuario (el aspecto visual).

Entre tantos lenguajes, es preciso mencionar a Swift que es un lenguaje para desarrollar aplicaciones en sistemas iOS y macOS que usan los dispositivos de Apple, así como los lenguajes clásicos que siguen teniendo acogida, tales como Java, C#, C++.

Las librerías son conjuntos de programas normalmente disponibles (aunque puedes fabricar tus propias librerías). Un gestor de paquetes puede administrar programas disponibles (librerías) por la comunidad, esto se ha introducido gracias a Internet (antiguamente era el fabricante del lenguaje quien principalmente brindaba las librerías y no existía un gestor de paquetes).
Ver glosario

GUI, CLI y API

Una manera sencilla de iniciar a programar es desde la línea de comandos (que es la base, al modo Matrix). En relación a esto la sigla CLI significa Interfaz de Línea de Comandos, que es cuando se hacen programas para correr, por ejemplo, en el servidor dirigidos a un rol capacitado (o técnico). Por otra parte, cuando se desea empezar de un modo visual en un nivel de usuario, se designa la sigla GUI refiriéndose a la Interfaz de Usuario Gráfica. De modo que la GUI se refiere a pantallas de escritorio o ventanas, así como pantallas de formularios, la interfaz de una aplicacion basada en el navegador o la interfaz de una aplicación para móviles, en general lo relacionado con lo visual (usándose frecuentemente el ratón, pantalla táctil u otro periférico) y que dista de usar un comando de texto como en una CLI.

Quizás el concepto de GUI es más técnico, suene menos o ha evolucionado en la actualidad, escuchándose actualmente UI (genérico y para interfaz de usuario web) o UX en términos de diseño y experiencia de usuario mejorada, pero los principios siguen siendo en el fondo los mismos. Como antecedente, pienso que la distinción viene de lo que hacían ingenieros al respecto a pasar a involucrar recurso experto en diseño, dado que pocos ingenieros pueden tener esa habilidad gráfica o similar, mas en un proyecto también está el factor de presupuesto y una visión coherente a lo que se quiere lograr. Para fines prácticos, en el presente texto podemos referirnos a la Interfáz Gráfica de Usuario como GUI o simplemente UI.

Por otra parte nos encontramos con el término API, significa Interfaz de Programación de Aplicaciones, ha tenido gran acogida cuando se trata de servicios a través de internet, dónde lo ideal es establecer un mecanismo de comunicación (API) para llamar funciones de aplicación que podrían ser usadas por otros programas o servicios. Actualmente, es común escuchar tecnologías que usan este concepto (ejemplo: API-Rest, como también una API GraphQL). Una CLI bien diseñada es en últimas una API, o bien, puede relacionarse con este concepto salvo que la CLI implique un nivel mas bajo. También podría diseñarse un software para que tanto la GUI como una CLI consuman como base una misma API.

Software de Escritorio

Basándonos en lo anterior, el software de escritorio básicamente se refiere a una GUI para el escritorio, llámese vista, pantallas o ventanas, la interfaz que funciona sobre el sistema operativo (bien sea Windows, macOS o Linux para el escritorio). Así que si piensas en el paquete de oficina que suele usarse con sus diferentes aplicaciones (Procesador de Palabras, Hoja de Cálculo, Presentador de Diapositivas, etc.) es el ejemplo más claro de un software de escritorio. En lo concerniente a la programación es común que se deba hacer el programa de escritorio para cada sistema operativo, salvo que se use algún lenguaje o plataforma cruzada que acepten los sistemas operativos, por ejemplo, con Java o Python (aunque su apariencia se note distinta o más simple respecto a otros programas de escritorio). Otro camino es el de las Aplicaciones Web Progresivas (PWA) que implica desarrollar en arquitectura Web (que ya describiremos) y usar un marco de visualización web (WebView) para la aplicación de modo que opere como una aplicación de escritorio y funcione en los diversos sistemas operativos, no obstante el desarrollo Web implica mayor complejidad y es un tema que trataremos.

Aplicaciones Cliente/Servidor

En un sentido práctico, podrían verse como aplicaciones de escritorio que principalmente involucran datos, donde el término “cliente” se asocia a éstas, pero que se conectan con el mecanismo que gestiona los datos, el cual se encuentra generalmente en un “servidor”, es decir, los datos no estarían en el computador sino en otra máquina dentro de una red y la comunicación es directa (como cuando se comparten archivos en una red) o al menos genera la sensación como si todo ocurriera en el computador del usuario cuando una parte no es así (en realidad son dos capas). En desarrollos actuales es menos probable que se encuentre esta arquitectura dado que al involucrar datos en su lugar es preferible desarrollar algo que funcione a través de Internet, aunque el concepto cliente/servidor podría traducirse de otro modo.

Un poco de Arquitectura Web

Si asociamos la palabra Web con tecnologias en el navegador suele pensarse en la combinación o trinomio HTML5 + CSS3 + Javascript. Como antecedente, es preciso tener presente que en los orígenes de Internet lo que se hacía era publicar contenido o páginas web informativas, dónde principalmente se usaba HTML y un poco de CSS. Las páginas más sofisticadas incorporaban el uso de Javascript. El concepto clásico de publicar páginas web con un proveedor de alojamiento web (web-hosting) sigue siendo un principio aplicable y se ilustra a continuación.

Por otra parte, cuando hablamos de arquitectura Web pensamos en aplicaciones que se relacionan directamente con Internet, o bien, con sus protocolos de comunicación aunque se trate de algo interno o local (conocido también como Intranet). En una arquitectura Web convencional (como se ilustrará en un gráfico posterior) se pueden identificar al menos 3 capas: el cliente o navegador, la lógica del lado del servidor (o capa media) y la base de datos (motor para gestionar y almacenar los datos). Entre el navegador y el servidor es importante mencionar el protocolo web para hipertexto (http o https, aquel que se puede observar en la barra de direcciones de tu navegador) dado que se usa HTML como plantilla y sus acompañantes (CSS para el estilo visual y Javascript para el aspecto lógico, dinámico o funcional).

Básicamente, la complejidad resulta en incorporar como intermediario un elemento de comunicación específico (http) a diferencia de cuando piensas en programas para el escritorio (que se hace mas sencillo sin este tipo de intermediario). Dado lo anterior, siguiendo las nociones de comunicación, se debe iniciar una petición bajo un canal (o protocolo respectivo) para que un receptor lo procese y devuelva un resultado o respuesta. En una arquitectura Web convencional la respuesta generalmente es un HTML. El ciclo y dinámica se repite, lo que se envían son paquetes de datos y se reciben otros paquetes con un tipo que se convierte en respuesta procesable por el navegador. A finales de los 90, lo más sencillo para programar con esta dinámica era usando PHP y se popularizó con los servicios de alojamiento web (web-hosting), hoy día promovido por varias herramientas para marketing digital, quizás también por el bajo costo de estos servicios y por ser en buena medida auto-gestionables pensando en pequeños negocios, aunque el siguiente nivel de servicio (si pensamos en máquinas virtuales o instancias de computo) resulta muy cercano en costos y se encamina a una infrestructura de computo. De cualquier manera tales servicios tienen hoy día un costo disminuido, distinto es que requieras contratar personal capacitado para gestionarlos. Una buena opción en el escenario del alojamiento web (web-hosting) es el lenguaje Ruby. Por otra parte, Python cubre igualmente este aspecto pero actualmente no encuentras tantos proveedores que te permitan usarlo en alojamiento web (web-hosting), siendo PHP el principal enfoque de ese tipo de servicio. De hecho, no se ha mencionado Java o .Net porque no funcionan en este tipo de servicios, orientándose a infraestructura empresarial (a partir de instancias de computo o un VPS - Virtual Private Server).

Un modo convencional de diseñar una aplicación en PHP, Ruby o Python es mediante múltiples páginas (conocido ahora como MPA - Multiple Pages Application) que llevan al usuario paso a paso en una operación, donde el desarrollador practicamente tiende a evitar el uso del trinomio HTML5 + CSS3 + Javascript al enfocarse en la modalidad que ofrece el lenguaje (ej. motor de plantillas), y aunque esto aún es aplicable la mayoría de procesos pueden mejorarse con la filosofía de una página por aplicación (conocido como SPA - Single Page Application). Las SPA han sido posibles gracias a la evolución de Javascript y el lanzamiento de librerías reconocidas como React, Angular, Vue, incluso otras menos populares como Preact y Riot (la elegida para OnMind actualmente) que promueven una UI fluida (aunque utilice un recurso estático puede renderizar la página).

Una arquitectura Web moderna también está influenciada por un nuevo concepto (el diseño de microservicios Web), en donde se retornan datos con una notación o formato (principalmente JSON) en lugar de centrarse en una plantilla HTML, esto implica que el componente visual o cliente sea enriquecido en su lógica, de allí que el desarrollo del lado del cliente toma fuerza con el lenguaje Javascript, dando un giro para encargarse de la vista o GUI dominando sobre HTML, cuando antiguamente se usaba basicamente para validaciones sencillas o para algún impacto visual con animaciones. En 2014 se apreciaba la necesidad de fortalecer nuevamente este lenguaje de “script”, el cual ha tenido una actualización significativa desde 2015 para dar respuesta a esta tendencia. De hecho, actualmente es posible correr Javascript fuera del navegador gracias a entornos o tecnologías en el lado del servidor, tales como Node.js, Deno y GraalVM.

El concepto de microservicios Web (siendo debidamente enfocado y diseñado, preferiblemente para infraestructura o al menos máquinas virtuales) puede dar apertura a lo que se conoce como el Internet de las Cosas (IoT) que permitiría interactuar con máquinas o electrodomésticos actuales. No obstante, hacer una API de microservicios Web implica aún una mayor complejidad (imagina que cada componente o tabla de una base datos se vuelva un microservicio) sin contar que la interfaz visual requiere ser desarrollada practicamente por completo. Así que cuando se mencionaba anteriormente la sigla PWA (Aplicaciones Web Progresivas) y lograr que una aplicación Web se acerque al nivel visual y funcional de una de escritorio, el camino es bien largo, dónde lo que debe medirse es la eficiencia en función de lograr una base de código (al menos en alto porcentaje) para que el mantenimiento sea menor que en un esquema convencional o nativo. Por ejemplo, si se hace una aplicación para gestión interna que funcione en Windows, macOS, iOS y Android compartiendo su código en gran medida es más eficiente que tener un equipo para cada plataforma o que se mantengan a través del tiempo diversas versiones por separado y con equipos de trabajo distintos. Si la eficiencia se mide en términos inmediatistas puede ser tanto cuestionable como considerable según el caso. Más que algo práctico el criterio debe apuntar a lo apropiado evaluando las variables específicas de una empresa o proyecto, o sus objetivos.

La velocidad (operaciones o conexiones por segundo) es otro aspecto a considerar. Por ejemplo, digamos que una universidad recibe matrículas con una plataforma hecha para una versión antigua de PHP (la 5), mientras otra universidad usa una tecnología de Java clásica que para ser eficiente requiere mucha infrastrucutra de computo e inversión abismal. Ambos casos son cuestionables. En el caso de PHP se admitían alrededor de 100 conexiones por segundo (combinándolo con Apache, que es una tecnología comunmente encontrada en alojamiento web) y en otro escenario se mejoraba notablemente pero en ambos escenarios se llegaba al punto en que colapsaba el sistema cuando los estudiantes y/o sus padres dejaban la matrícula hasta último momento. Mientras no se actualice o modernicen estos sistemas encontrarás un caso real, incluso en servicios del estado. Por otra parte, las nuevas tecnologías han enfrentado el reto de superar las 10 mil conexiones por segundo sin requerir una inversión millonaria (el software ayuda en cierta medida). Hace una década, Node.js fué pionero en este sentido y esto hizo que tecnologías con otros lenguajes mejoraran su propuesta, por ejemplo, encuentras interesantes tiempos de respuesta en últimas versiones de PHP y tecnologías o librerías recientes poco convencionales (tal es el caso de FastAPI para Python y así otras).

En el mundo de Java también encuentras tecnologías como Vertx que puede llegar a superar las 100 mil conexiones por segundo (dependidendo de la implementación y la infraestructura). Hoy día los lenguajes brindan una manera más común de desarrollar aplicaciones web, sin embargo, en el caso de Java sería bueno tan solo ilustrar en restrospectiva la arquitectura clásica (Java Enterprise Edition) que ha tenido acogida en compañías desde décadas atrás.

Ahora haces aplicaciones para la computación en la nube (que involucran infraestructura y es diferente al alojamiento web). OnMind por su parte ya tiene un camino recorrido en este aspecto, pensando precisamente en las necesidades de innovación que pueden tener las empresas al respecto. Por ello se ha implementado nuestra propia arquitectura o esquema.

Desarrollo para Moviles

En el software para móviles se ve resaltado el uso de una GUI para móviles, y dada la tendencia comercial de los sistemas operativos para móviles, se podría decir que actualmente existen marcados dos caminos, para Android y para iOS. Lo que se busca con el desarrollo para móviles es aprovechar las características de los dispositivos, como su cámara, el geolocalizador, notificaciones, etc. No obstante, existen casos en que lo que se requiere principalmente es extender el software de gestión interna sin mayor necesidad de los recursos específicos de los móbiles, o que una página web se vea como una aplicación móvil. Para esto, nos remitimos al término de Aplicaciones Móviles Hibridas, distinguiéndose de las Nativas por el tipo de integración que no es natural al sistema Android o iOS, sino que se usa un componente intermedio (llámese marco de trabajo para móviles, Cordova, o desarrollo bajo el componente WebView tanto en Android como en iOS, es decir, un modo de integrar casi un navegador para habilitar desarrollos en web: HTML5 + Javascript). Ionic Capacitor es un buen ejemplo de este tipo de implementación tecnológica.

Si el caso es el planteado (software de gestión interna convencional) las aplicaciones híbridas en la actualidad dan un tiempo de respuesta favorable y salvo que fracciones de segundos sea un criterio y el presupuesto no es un problema, bien puede abrirse un equipo de desarrollo especializado en aplicaciones móviles nativas. Si lo que deseas no tiene nada que ver con software de gestión, o es una aplicación específica para móviles o para reloj o se trata de un juego, entonces es preferible el desarrollo nativo. Actualmente Google promueve su marco de trabajo denominado Flutter, el cual plantea un desarrollo nativo tanto para Android como iOS. Mientras en una aplicación móvil hibrida generalmente se usa Javascript, en una nativa preexistente con Android se ha venido usando el lenguaje Java o Kotlin, y para iOS el lenguaje Objective-C o Swift, con Flutter se usaría Dart tanto para iOS como para Android, incluso para la Web (aún en beta), y dejas de usar Javascript, HTML y CSS. Facebook por su parte ha dispuesto desde años atrás React Native que permite programar en Javascript y traducir a nativo, aunque cada característica de un dispositivo no sea sencillo cubrir, quizás ayude otro tanto usando el marco de trabajo Expo (sobre React Native). Al menos ese es el escenario a 2021.

Otros Escenarios

A modo de panorama y cultura general, dado que cada día surgen nuevos enfoques y tendencias, podrían considerarse otros escenarios como el análisis de datos o aprendizaje de máquina y las criptomonedas, en donde como constante encontramos a Python (así como Java y otros) por encima de Javascript, el cual no parece ser el más ideal para procesar lo que se conoce en criptomonedas como blockchain (cadena de bloques), aunque en ese caso es de anotar que Solidity (lenguaje usado para la máquina virtual Etherium - EVM) se inspira precisamente en Javascript (mas no sería lo mismo). Por otra parte, si se trata de juegos la plataforma Unity (que correspondería al desarrollo de una GUI especializada) usa principalmente C# (aunque existe Unreal para C++), y si se trata de programar sistemas (la Matrix a fondo) o microcontroladores lo más probable es que se requiera C o C++, y recientemente Rust (lenguaje interesante por su interoperabilidad con otros como Javascript, usando WebAssembly o Deno). Una buena opción en muchos casos es Go, un lenguaje creado por Google.

FrontEnd, BackEnd y FullStack

A buen entendedor y enfocándonos en la arquitectura Web, estos términos se resumen relacionando FrontEnd con la GUI y BackEnd con una API de microservicios Web o desarrollos detrás de la capa Web, conocida también como capa media (incluso se puede usar el término BackEnd cuando se trata de desarrollos sobre la base de datos). FrontEnd y BackEnd se usan para referirse tanto a una categoría o concepto de un componente técnico como para quién se ocupa de ellos, hablándose de un desarrollador BackEnd o FrontEnd según corresponda, mientras FullStack se refiere a un desarrollador que cubre ambos aspectos (incluso algunas veces DevOps, el cual veremos adelante), en últimas se refiere a un experto de modo integral, no necesariamente especializado, puede dominar una más que otra (o un par).

DevOps

De un modo convencional, se requiere administrar la infraestructura de una plataforma Web o de la base de datos, alguién que podría recibir una versión para ser instalada siendo remitida por el equipo de desarrollo o un desarrollador. Actualmente se evidencia un despliegue continuo dado el ciclo de software con versiones liberadas con más frecuencia dónde se requiere, por ejemplo, involucrar un desarrollador para automatizar algunas labores de la administración. No obstante, un profesional que aborda esta faceta generalmente no es un experto en administración o seguridad, o si se trata de un recurso que viene de la faceta de administrar servidores quizás requiera involucrarse como desarrollador de la plataforma Web, eso sin contar el aspecto de validación o calidad del software a instalar (que deberían automatizarse por el equipo de desarrollo).

Existen posiciones sobre el término inclinándose hacia una práctica o metodología, sin embargo, comprendiendo lo mencionado y siendo prácticos DevOps significa desarrollo y operaciones que se orienta a la automatización del despliegue de aplicaciones en la nube. Podría verse como un campo en el que evoluciona un administrador de sistemas con enfoque mixto en función del despliegue o entrega continua. Si retomamos los primeros conceptos, estaría muy relacionado con una CLI de una plataforma Web o con una tecnología con otro enfoque, el de despliegue o entrega (ejemplo: docker, kubernetes).

¿Cómo sería un equipo de trabajo?

Salvo que hagas un recorrido o travesía con el conocimiento asimilado, como ha sido mi caso desde 2014 con OnMind, podrías cubrir con cierto alcance las facetas de FrontEnd, BackEnd, desarrollo para móviles y el rol de un ingeniero administrador de sistemas que aplica prácticas de DevOps, además de tener una estrategia para el soporte y la operación (incluyendo un aspecto comercial). Sin embargo, cuando se trata de un proyecto informático que opera respaldado en un equipo de trabajo los roles aumentan. No abordaremos cada rol, simplemente con el objetivo de comprender la incidencia de algunas facetas informáticas ilustraremos a continuación un equipo de trabajo de un proyecto en ejecución, a modo de ejemplo.

Gestor de Proyectos, Promotor Comercial, Analista de Proyectos, Líder Técnico, Desarrollador de Software, Analista de Pruebas & Documentación, Administrador de Sistemas en la Nube, Analista de Soporte & Mantenimiento (del Software), Personal de Soporte (Analista Funcional o Agente, dependiendo del nivel del servicio empresarial)

El camino de OnMind

Desarrollamos aplicaciones Web modernas considerando cierta experiencia digital para el usuario, orientada básicamente a datos y el factor de la movilidad (“first mobile”). No obstante para cuestiones de desarrollo móvil, dado que nos enfocamos en productos que generalmente son para gestión interna de negocios, se ha visto conveniente seguir cierta arquitectura (con aplicaciones móviles Hibridas usando el componente WebView). En OnMind, para nuestro núcleo, se usan básicamente los lenguajes Javascript y Kotlin, a modo de extensión para ciertas características consideramos introducir ABCode. Esto puede sugerir una apertura en el camino que se ha tomado, centrando el aspecto visual con el uso de Javascript y el desarrollo Web (al menos una relación de 2/3 de partes del código de nuestra primera versión corresponde a Javascript).

Kotlin es un lenguaje que corre en la Máquina Virtual de Java (JVM), aunque tiene características para cubrir el desarrollo FrontEnd, lo usamos para una capa adicional en nuestra propia arquitectura (que hemos denominado DAI - Interfaz Adaptadora de Datos). Ésta se relaciona con los datos y el BackEnd (la lógica funcional o de negocio). Se pretendía conservar experiencia, compatibilidad con un mercado objetivo y ventajas de la Máquina Virtual de Java (JVM) en la fabricación de aplicaciones empresariales usando un lenguaje moderno en lugar de Java y quizás reemplazar Javascript para unificar el lenguaje, pero esto último ha resultado innecesario dado que en el rumbo tomado ha sido favorable conservar éste lenguaje de “script” del navegador y de Node.js (tecnología que proporciona correr Javascript para el servidor) siendo fundamental para orquestar nuestra plataforma moderna. De este modo, puede convivir una tecnología de entorno mixto proporcionando un factor de innovación y de posibilidades para proyectos de aplicación empresarial. De hecho, Node.js y Kotlin funcionan actualmente en GraalVM (otra JVM, que además ha posibilitado nuestra versión nativa con el código escrito en Kotlin, optimizando el tiempo de ejecución).

Se puede decir que el camino nos ha llevado a la interoperabilidad. Así, en lugar de un único lenguaje, como se deseaba en un principio, se usan varios en mayor o menor grado pero en todo caso todo se orienta y se orquesta con un sentido unificador. En una analogía sencilla, Javascript sería como el idioma Inglés en esta parte del mundo, quién es bilingue su segundo idioma sería Kotlin para otro territorio, y en ocasiones se pueden comprender aspectos básicos de un tercer idioma o ser políglota. No obstante, pienso que la prioridad puede cambiar con el tiempo.

Teniendo presente este antecedente para nuestra primera versión, los frentes de desarrollo de software de OnMind son los siguientes:

1. FrontEnd Común (Web). Javascript (bajo Navegador o Electron), además de HTML5 (+CSS3)
2. FrontEnd Core Components (UI). Javascript, además de HTML5 (+CSS3)
3. FrontEnd para Móviles. Javascript + Ionic-Capacitor (para desarrollo Nativo y un envoltorio Web: WebView)
4. BackEnd Común (Web). Javascript (bajo Node.js)
5. BackEnd para Datos. Kotlin (bajo JVM con Vert.x), además de SQL
6. DevOps. Javascript, Kotlin (CLI orientada a Linux)
7. Custom (otros). Para algunas personalizaciones empresariales a modo de extensiones específicas, ABCode podría ser considerado, y si lo amerita un proyecto, quizás Typescript, además de Javascript y Kotlin (este último para proyectos sobre la máquina virtual de Java - JVM).

Puedes consultar nuestra Ficha Técnica.

Comprendiendo que la visión ya es amplia y es importante un alcance, logrando cubrir nuestras necesidades con lenguajes como Javascript y Kotlin, incluso ABCode, si no se ha mencionado otro lenguaje en principio estaría fuera de nuestro radar, estando abiertos a algún otro para un proyecto concreto que significativamente amerite otro enfoque.

De modo simplificado, sigue tratándose de FrontEnd y BackEnd (además de DevOps) con enfoques que ayudan a enriquecer y obtener eficiencia de lo que se construya, con un método (como el Método OnMind) y alguna herramienta interna que posibilitaría un equipo con diferentes niveles de experiencia, bien sea que corresponda a un principiante (“beginner” o practicante, principalmente para FrontEnd), un desarrollador junior, quizás un nivel semi-senior antes de senior, incluso llegar a un enfoque distinto (ej. evangelista). Dado que mencionamos roles, es claro que existen distintos al de desarrollador de software que igual deberían tener cierta comprensión sobre el panorama planteado, tales como: gerente de proyectos, líder o arquitecto, analista funcional, diseñador gráfico, traductor y documentador, aseguramiento de calidad, ingeniero de seguridad informática, etc.

Si se plantea un lenguaje para empezar un proyecto como en nuestro caso, quizás el lenguaje más recomendado sea Javascript (2015+, también conocido como ES6 en adelante) siendo clave para el FrontEnt al menos orientado a la Web, pero esto varía dado el enfoque del caso y la preferencia del equipo.

© 2021 by César Arcila