É um facto bem conhecido que as aplicações Web modernas são cada vez mais utilizadas, de dia para dia. O desenvolvimento é muito rápido e permite a publicação de aplicações em todas as plataformas, sendo que o único requisito é dispor de um ambiente que permita lidar com um determinado conjunto de tecnologias. A linguagem que pode ser considerada a rainha de todas as outras dentro deste ambiente é a JavaScript. Hoje, vou partilhar convosco alguns factos sobre o desenvolvimento de software relacionados com esta linguagem.
Definição de desenvolvimento rápido de aplicações
A expressão "desenvolvimento rápido" pode ser interpretada de muitas maneiras erradas. Para o evitar, vamos explicar quais são as nossas expectativas. Bem, o mais importante é o orçamento. Para criar várias versões da mesma aplicação, precisamos de muitos programadores de várias tecnologias e de pagar a cada um deles. Para criar aplicações móveis nativas, precisamos de duplicar o nosso código para funcionar bem em ambas as plataformas - Android e iOS. Uma abordagem comum é manter as duas aplicações semelhantes, usar a mesma API, manter o mesmo comportamento e assim por diante. Como resultado, temos de duplicar o código para criar duas versões da mesma aplicação. JS é uma linguagem que permite nós para criar aplicações móveis e aplicações Web ao mesmo tempo. Parece impossível? Deixe-me explicar do que estou a falar.
Móvel? Web? Não me interessa.
Digamos que queremos criar uma aplicação que utilize o React biblioteca. Esta biblioteca pode ser utilizada para construir aplicações web e aplicações móveis com o React nativo. Os mecanismos lógicos da aplicação, como autorização, computação, filtragem de dados, etc., podem ser feitos com Ganchos React. A questão é que estes hooks podem ser partilhados por ambas as versões da aplicação - web e móvel. Graças a esta opção, temos as seguintes gravações:
- Não há necessidade de duplicar o código responsável pela mesma coisa,
- Não há necessidade de contratar programadores móveis nativos para implementar a mesma parte das aplicações,
- Não há necessidade de misturar diferentes linguagens para implementar a mesma aplicação em diferentes plataformas móveis (Android/iOS),
- Um programador pode ser responsável pela implementação de caraterísticas específicas da aplicação em todas as plataformas.
Para resumir este parágrafo - não é que uma base de código alimente todas as versões da aplicação, embora possamos dividir o código partilhado e utilizá-lo em cada uma delas para fazer o processo de desenvolvimento realmente mais rápido.
Conclusão - se pretende criar uma aplicação Web e uma aplicação móvel ao mesmo tempo, considere a biblioteca React que pode partilhar uma base de código na versão móvel e na versão Web da aplicação.
Mas e o backend?
Há alguns anos atrás, quando se falava de backend, provavelmente poucas pessoas imaginariam que a sua manutenção poderia ser possível com a ajuda de uma linguagem como a JS. O desenvolvimento desta língua é espantoso e os seus frutos podem ser colhidos até aos dias de hoje.
De que é que estou a falar? Se contratar a pessoa certa Programadores JSNo entanto, a linguagem de programação é muito mais simples do que a linguagem de programação de software, uma vez que permite escrever não só o front-end da aplicação, mas também o back-end, ou seja, o processamento de dados no servidor, a comunicação com a base de dados, vários tipos de integrações, etc. Ainda hesita ou não está convencido sobre esta linguagem? Não há razão para ter essa atitude! Backend utilizando JS pode ser implementado de duas formas populares - num modo extensível e configurável, que o express.js nos pode fornecer, e num modo estruturado utilizando o padrão DI - nest.js.
Ambas as soluções são extremamente populares e alimentam muitas aplicações de produção cujos proprietários são "gigantes tecnológicos" no seu sector. Penso que já amadureceram o suficiente para o convencer a escolher qualquer uma delas.
Ainda não é suficiente? À semelhança da partilha de código entre aplicações Web e móveis, o backend pode partilhar recursos tanto com as primeiras como com as segundas. A palavra-chave a utilizar aqui é TypeScript - entre outras coisas, permite-nos partilhar uma base de código, ou seja, uma definição de tipo de dados comum a todas as plataformas.
Com aplicações construídas exclusivamente sobre o JavaScript / TypeScript Ao utilizar monólitos, poupamos muitas linhas de código, que teríamos de duplicar em linguagens de programação nativas. Por outro lado, ao utilizar a mesma linguagem em todas as frentes, podemos partilhar uma enorme quantidade de lógica entre todas as aplicações, o que aceleraria definitivamente o tempo de construção de uma determinada aplicação. Não parece ótimo?
O JS pode alimentar aplicações de ambiente de trabalho?
Acontece que as tecnologias para criar aplicações de browser são óptimas para manter as aplicações que utilizamos na sua forma de ambiente de trabalho - um bom exemplo pode ser o Slack. O Slack é uma aplicação utilizada para equipa comunicação - para além das mensagens normais, inclui muitas funcionalidades diferentes e vários tipos de integrações externas. Tudo isto faz com que seja uma das aplicações mais populares utilizadas principalmente no sector Setor das TI.
Acontece que o Slack também usa tecnologias web (e, portanto, JavaScript) para construir sua interface de aplicativo. A base que torna possível executar essas aplicações no ambiente de trabalho é o electron. Criar interfaces gráficas usando tecnologias da Web torna muito mais fácil, rápido e geralmente possível desenvolver aplicativos para diferentes plataformas ao mesmo tempo.
O JS é suficientemente maduro?
A parte frontal da aplicação não dá a ilusão de que JS é a única e exclusiva linguagem que alimenta o ecossistema aqui. Por enquanto, não existem alternativas viáveis que possam substituir esta parte da aplicação (embora eu ache que o WebAssembly nos possa surpreender no futuro). Portanto, falando da maturidade do JS no frontend - não há dúvida de que é o único real.
Falando sobre o backend, muitos programadores podem parecer chocados ou negar imediatamente que o JS seja adequado como linguagem de programação no backend. No entanto, a questão tem de ser analisada objetivamente.
Muitos fornecedores de serviços na nuvem fornecem SDKs que permitem utilizar diretamente nuvem métodos. Por estranho que pareça, um dos separadores mais populares, mesmo ao lado de C#, Go e Java, é Node.js. Acontece que esta plataforma é ideal para escalar e criar aplicações baseadas em microsserviços ou arquitetura sem servidor. Conclusão - JS é uma das linguagens mais populares para o desenvolvimento de aplicações baseadas em microsserviços/arquitetura sem servidor. Nos ecrãs abaixo, podemos ver que a santíssima trindade (Google Computing Services, AWS, Azulejo) dos fornecedores de serviços de computação em nuvem permite-nos criar aplicações utilizando nó.js.


Quanto ao ecossistema node.js, provavelmente todos estão familiarizados com uma biblioteca chamada express.js - é uma ferramenta simples e direta que permite definir caminhos e depois alimentá-los com dados apropriados que foram devidamente processados no lado JS. Além disso, o padrão utilizado entre os pedidos HTTP tratados no express.js tornou-se um dos mais populares em todo o ecossistema e é uma espécie de padrão para várias outras bibliotecas que utilizam, por exemplo, a arquitetura sem servidor.
Conclusão - JS é uma linguagem suficientemente madura para colocar todas as cartas e construir tanto o frontend como o backend. Além disso, é uma linguagem bastante recente que se integra facilmente nas arquitecturas de aplicações modernas. É ótimo que um programador que conheça uma linguagem possa dominar ambos os lados (pilha completa) de uma aplicação.
O JS é suficientemente rápido?
Bem, o motor mais utilizado para executar código JS é o v8, baseado na linguagem C++. Este motor desenvolvido pela Google está vocacionado para executar aplicações para plataformas Web. Um aspeto interessante é que este motor não interpreta o código JS. Em vez disso, faz uma coisa chamada "JIT" - "just in time compilation". Graças a isso, não temos de interpretar o código JS linha a linha, apenas o compilamos e executamos. É ainda mais rápido e dá-nos resultados de desempenho muito bons.
O JS é suficientemente justo no que respeita ao desempenho? Sim, é. Desde que mantenha os seus algoritmos suficientemente justos, não há qualquer problema em utilizar JS no lado do servidor. A outra coisa é manter o seu código tão assíncrono quanto possível. Com estas práticas, o seu código pode lidar com pedidos paralelos sem qualquer problema. Não tem de se preocupar com a troca de tecnologia por causa do desempenho - especialmente quando a arquitetura da aplicação é escalável.
Já discuti o desempenho e os parâmetros de referência em pormenor neste artigo.
O JS não é uma peculiaridade das outras línguas?
Bem, são dezenas de opiniões de que a linguagem JS tem comportamentos estranhos em alguns casos e que lidar com isso é algo que vai fazer a cabeça explodir durante o processo de desenvolvimento. Não posso concordar 🙂 Tal como qualquer outra linguagem, tem vários padrões/comportamentos que não são elegantes mas com a compreensão de como funcionam e quais os seus objectivos desenvolver aplicações com JS não é desagradável.
Especialmente a observação "assíncrono" logo antes de JS faz tremer alguns programadores. É difícil de entender quando não se tem qualquer experiência com ele. No entanto, é uma parte do JS que nos permite construir soluções modernas de uma forma fácil. Vejamos os websockets: como são baseados em eventos, cada uma das unidades ligadas - o utilizador e o servidor - pode emitir e receber eventos em paralelo. Se o código que alimenta esta aplicação for suficientemente assíncrono e não bloquear a thread principal, podemos facilmente lidar com milhares de pedidos num curto espaço de tempo.
Vamos comparar JS e PHP com o contexto de websockets. O PHP é uma linguagem de programação síncrona, pelo que resolver tópicos de websockets dá uma enorme dor de cabeça. Podemos ver que a PHP obtém padrões de JS para construir aplicações backend interactivas que podem utilizar tecnologias modernas, como webrtc ou websockets.
Misturar tudo
Juntando todos os parágrafos, podemos afirmar alguns factos:
JavaScript é uma linguagem que pode ser utilizada para criar todo o tipo de aplicações - desde a Web, a dispositivos móveis e a computadores de secretária;
As aplicações escritas em JS podem partilhar vários fragmentos de código entre si, como os responsáveis pela formatação de dados ou tipos em Typescript;
Graças ao crescimento da Web, o desempenho que o JS oferece é suficientemente bom para optar pelo desenvolvimento de aplicações front-end e back-end;
Graças ao seu design invulgar, o JavaScript é capaz de suportar infra-estruturas de aplicações modernas, como websockets e WebRTC;
Ao contratar um programador devidamente qualificado, poderá tirar partido do seu potencial em todos os front-ends disponíveis que utilizam esta linguagem;
O JS é uma linguagem que tem vindo a subir nas tabelas de popularidade há vários anos e não há qualquer indicação de que isso vá mudar.
Para dar a minha opinião, assumidamente parcial, tirar partido da opção do JavaScript de reutilizar o mesmo código em todas as frentes disponíveis é algo que irá certamente acelerar o desenvolvimento de aplicações e reduzir o número de programadores envolvidos na manutenção do backend de aplicações escritas noutras tecnologias. Como confirmação, recordemos o facto de um grande número dos chamados gigantes das TI seguirem este padrão e partilharem uma grande parte da base de código entre plataformas. Apesar das diferentes opiniões sobre esta língua, há que ter em conta o facto de as estatísticas de utilização e de satisfação com a utilização de JS crescem de ano para ano, e os seus programadores podem facilmente aderir à tendência da pilha completa.

Ler mais:
Porque é que deve (provavelmente) utilizar Typescript
Como não matar um projeto com más práticas de codificação?
Estratégias de obtenção de dados no NextJS