Recentemente fui abordado por um cliente sobre um aplicativo javascript de "avaliação financeira" em seu site Wordpress que não funcionava mais. Teve uma série de problemas e, no final, o caminho mais fácil foi reconstruí-lo.

Neste aplicativo, os usuários podem inserir informações financeiras e pessoais básicas, e o aplicativo informa se estão no caminho certo em termos de planejamento financeiro. Não é uma lógica supercomplexa, mas existe bastante.

Não sou, principalmente, um desenvolvedor front-end. Estou mais confortável no back-end. Mas já implementei projetos em Vue, Angular, React... Eles funcionam, mas não confio totalmente neles. E com o passar dos meses e anos, sempre desenvolvo uma ansiedade crescente sobre o quão desatualizadas as dependências devem ter ficado, incluindo o próprio conjunto de ferramentas de desenvolvimento.

Entre no brilho

Gleam é uma linguagem amigável para a construção de sistemas de tipo seguro e escaláveis!
~ Site do Gleam

Estou animado com o Gleam desde que eles declararam que a v1 estava pronta para produção. Seu estilo funcional, imutabilidade, correspondência exaustiva de padrões, inferência de tipo e a estabilidade de simplicidade do Go fizeram com que o Gleam atingisse todos os meus pontos ideais.

O sistema de tipos praticamente garante que se o seu código for compilado, ele funcionará. Ainda não encontrei um bug em meu código Gleam que não fosse alguma versão de "que pena, esqueci de terminar de implementar isso".

Entre no brilho

Gleam foi construído para rodar no BEAM (a lendária VM testada em batalha de Erlang), mas também tem um alvo de compilação Javascript. Isso significa que ele pode ser facilmente enviado para o Node e para o navegador.

Lustre é a estrutura de front-end preeminente do Gleam. É uma versão fiel do Elm para o ecossistema Gleam e apresenta a arquitetura de gerenciamento de estado "Modelo -> Visualização -> Atualização" do Elm.

Este é um modelo conceitual drasticamente mais simples do que outros frameworks frontend. Em vez de oferecer gerenciamento de estado como uma biblioteca opcional (estou olhando para você redux), o modelo de gerenciamento de estado de Lustre é seu núcleo pulsante.

Você simplesmente descreve cada

verbo que pode ocorrer para modificar o estado em seu aplicativo e mapeia esse verbo para uma operação pura com segurança de tipo que retorna uma versão atualizada do modelo. As funções de visualização (também puras) fluem diretamente do estado desse modelo unitário.

Lustre também fornece um sistema de efeitos gerenciados para que mesmo com várias operações de E/S que possam falhar,

o código do seu aplicativo possa ser implementado usando funções totalmente puras.

O que há de legal nas funções puras? Eles têm a garantia de sempre fornecer a mesma saída com a mesma entrada. Isso os torna previsíveis, fáceis de testar e extremamente estáveis. Funções puras não quebram. Eles meio que matematicamente

não podem.

Doce, doce padrão

Os aplicativos Lustre podem envolver

um pouco mais padronizados na configuração do aplicativo e na criação de todos os tipos e tal. Mas ...

Nunca houve uma estrutura mais adequada à qual o termo "padrão" fosse aplicado. Isso me dá a mesma sensação de confiança que eu teria ao cravar um rebite em uma chapa de aço. Uma vez instalada, essa coisa não vai a lugar nenhum

. Eu me esforço para expressar o quão diferente isso parece em comparação com minhas experiências anteriores com javascript. Meu aplicativo poderia ter menos LOC se eu tivesse feito isso em outra estrutura. Mas eu confiaria que não quebraria? Seria tão simples de entender?

O produto final

Enviei meu aplicativo dentro do prazo e do orçamento. O cliente está muito feliz com isso. E durmo tranquilo sabendo que este projeto está bem e verdadeiramente

feito

. Não só isso, mas ele vive confortavelmente no

Wordpress

de todos os lugares. Criei um shortcode para carregar os assets compilados, coloquei na página e pronto. O pacote JS tem 18,1 kb, reduzido e compactado. Isso é quase tão pequeno quanto

htmx

. Pelo amor de Deus! Tenho algumas reservas sobre enviar um projeto usando uma linguagem e estrutura ainda relativamente obscuras. Mas essas reservas são amenizadas sabendo que o aplicativo não irá quebrar e que o próprio Gleam pode ser aprendido em uma tarde.

Mais importante - honestamente, não acho que estaria tão confiante no produto final, na estabilidade do conjunto de ferramentas ou na minha capacidade de atualizá-lo no futuro, se o tivesse construído usando qualquer outra coisa .

Minha frequência cardíaca

Agora estou recuperando toda a minha motivação para escrever este post: a sensação de ter um aplicativo Lustre em produção

Já se passaram algumas semanas desde que este aplicativo foi lançado e ainda gosto de revisitá-lo de vez em quando. Não porque o cliente tenha solicitado alterações. Só para olhar o código.

Quase me sinto envergonhado de dizer isso, mas a maior parte do meu outro código parece uma desvantagem em algum nível.

Especialmente

javascript. Mesmo que seja Typescript, mesmo que tenha testes. Isso me deixa ansioso, como se o lugar estivesse repleto de minas terrestres escondidas e armadilhas. Talvez seja um problema de habilidade. Talvez eu tenha me queimado muitas vezes.

Olhar para meu código Gleam/Lustre me faz sentir

calmo. É isso. Esse é o tweet.

Para encerrar, desejo sinceramente que outros desenvolvedores experimentem o Gleam e o Lustre, para que eles também possam desfrutar dessa mesma felicidade zen ao contemplar seu código de front-end.

Obrigado por ler.