Vy.no, a maior provedora de transportes da Noruega, reescreveu seu website em Elm, uma linguagem transpilável para javascript. Kjetil Valle e Robin Heggelund Hansen apresentaram recentemente em um artigo a jornada de 3 anos no qual a Vy gradualmente aderiu ao Elm nas partes não estáticas de seu website.
O website da Vy.no permite que milhões de visitantes comprem passagens de ônibus e trens todos os meses. De experimentos iniciais em 2016, que incluíram o Elm em partes do website, hoje praticamente todo site está escrito em Elm, com apenas poucas partes escritas em JavaScript para operações não suportadas pelo Elm. No total, treze aplicações em Elm compõem o website, representando um total de 83.000 linhas de código.
Kejtil Valle reportou que a jornada do Elm na Vy começou com a utilização da linguagem em pequenas aplicações internas, o que permitiu analisar os efeitos de um sistema fortemente tipado em alguns tipos de bugs. Um objetivo do teste foi obter uma primeira experiência na afirmação do Elm que diz não permitir erros de execução.
Após uma experiência positiva, menos de um ano depois, o próximo passo foi conceder ao Elm a responsabilidade de rodar uma parte maior do website. Para este propósito, um time de estagiários temporários, sem experiência prévia com Elm, foram designados a escrever um componente de processamento de passagens. O time de estagiários rapidamente incorporou a linguagem e produziu código que ainda executa em produção, com apenas algumas pequenas alterações durante esse intervalo.
Quando a decisão de reescrever completamente o processo de compra de passagens foi tomada, o time de desenvolvimento decidiu dar ao Elm a responsabilidade por grandes partes do website, iniciando um processo que terminou com o processo de compra sendo inteiramente reescrito em Elm, como também a maioria das outras partes do site. O time de desenvolvimento atualmente consiste de 15 desenvolvedores Elm distribuídos em vários times.
Enquanto a maior parte da experiência com o Elm foi boa, Valle cita algumas ressalvas importantes. O código em Elm pode ser repetitivo e conter muito boilerplate. Valle explica:
Vamos tomar como exemplo o tratamento de erros. No Elm, você tem que encapsular tudo que pode falhar em seu próprio tipo. Se desejar extrair valor deste tipo, primeiro é necessário verificar se algo de fato deu errado. Não tem como fugir disso. (...) Também não é possível escrever um tratamento de erros que funcione para todos os tipos de erros, pois o Elm não possui uma maneira de declarar que dois tipos diferentes aderem ao mesmo contrato.
Isto está relacionado a uma reclamação comum entre desenvolvedores que tentaram mas descartaram o Elm como linguagem, que é a ausência de type classes. De fato, o suporte a type classes foi uma das primeiras issues criadas (em 2012!). Enquanto a linguagem possui três type classes nativas, ela não suporta type classes customizadas. Isto significa que um desenvolvedor que quer mapear um estrutura de dados deve utilizar a função de map dedicada à estrutura de dados, por exemplo, List.map, Array.map ou Dict.map, ao invés de apenas utilizar um map polimórfico. Isto facilita a criação de boilerplate e limita a expressividade da linguagem, e a habilidade dos desenvolvedores de criar abstrações de tipos complexos. Além disso, o Elm removeu em sua última versão (0.19) operadores infixos customizados, adicionando mais código que deve ser explicitamente escrito pelo desenvolvedor.
Valle todavia argumenta que, em seu experiência, a ausência de type classes e outros tipos de conveniências são fatores positivos. Ele diz:
Como as aplicações escritas em Elm tendem a ser tão explícitas, é fácil entender o que o código está fazendo sem a necessidade de ser tão familiarizado com ele. Para saber se uma função tem algum tipo de efeito colateral, basta olhar rapidamente à sua assinatura.
Enquanto boilerplate tende a ser visto como negativo em muitas linguagens e frameworks, nós percebemos isso como um guia simples e importante de como uma aplicação frontend está construída, e ao ler essa aplicação somos capazes de entender melhor como um dado sistema funciona.
Outra dor mencionada por Valle é que a interoperabilidade com JavaScript pode ser complexa, dada as limitações impostas pelo Elm. O Elm não suporta pacotes privados, o que significa que o JavaScript não pode ser incluído em pacotes no sistema de registro de pacotes do Elm. Isto faz com que a interoperabilidade seja necessária, com a complexidade adicional de que esta operação é necessariamente assíncrona(devido à troca de mensagens assíncrona). Valle menciona que isto acabou causando alguns bugs difíceis de encontrar quando, por exemplo, foi necessário implementar o tratamento de validação de números de telefones no lado JavaScript.
Pelo lado bom, manter certa distância do JavaScript é uma forte razão por trás da habilidade do Elm de declarar a ausência de erros de tempo de execução. Isto também incentiva desenvolvedores a recorrer à interoperabilidade apenas quando absolutamente necessário. Valle cita que:
Felizmente para nós, a biblioteca "elm-phone-numbers" surgiu e fomos capazes de trocar todas as validações assíncronas por três linhas simples de código Elm. Mas a lição que aprendemos ainda é relevante: A interoperabilidade com Javascript por ser dolorosa, especialmente quando há a conversão entre uma API síncrona com uma assíncrona.
Valle conclui ao citar que os benefícios que a Vy experimentou ao utilizar Elm são a ausência de erros de execução, melhoria na produtividade, maior rapidez na integração de desenvolvedores e fácil refatoração. Em sua opinião, tudo isto é muito vantajoso sobre os pontos fracos encontrados quando Elm é utilizado (como a interoperabilidade com Javascript).
A última versão do Elm, 0.19.1, foi liberada em 21 de Outubro de 2019, mais de um ano depois da versão 0.19. Não há uma agenda conhecida para a versão 1.0. O Elm é uma DSL, uma linguagem funcional que transpila para Javascript e é utilizada para a criação de aplicações web. O processo de design do Elm é focado em usabilidade, performance e robustez.