{
  "path": "/porque-elm.html",
  "site": "at://did:plc:3272gdrjsuikiff7qsgokgas/site.standard.publication/3mjaxtes2yf2v",
  "tags": [
    "pt",
    "Elm",
    "Dev",
    "Frontend"
  ],
  "$type": "site.standard.document",
  "title": "Porquê Elm: chega de dor de cabeça com front-end, chega de JavaScript",
  "publishedAt": "2016-09-17T00:00:00.000Z",
  "textContent": "> Baseado na palestra que ofereci no encontro do Grupy-SP, em 17 de setembro de 2016. O código dessa atividade está disponível no GitHub.\n\nO problema que o Elm resolve\n\nPara entender o porquê eu gosto do Elm precisamos falar sobre duas coisas: JavaScript e DOM.\n\nPrecisamos falar sobre JavaScript\n\nAlguém aqui gosta de JavaScript? Eu confesso que dou risada com algumas coisas do JavaScript:\n\nMas deixemos os _memes_ de canto. Arrisco dizer que quem gosta de Python não gosta de JavaScript por três motivos:\n\n1. Existem muitas formas de fazer a mesma coisa, nem todas são óbvias e nem todas funcionam em todos os navegadores. Por exemplo, aqui temos uma lista de 535 formas de recarregar uma página. Bateu aquela saudades do _there should be one – and preferably only one – obvious way to do it_, né?\n1. Debugar JavaScript é difícil pois as mensagens de erro padrão são péssimas.  Por exemplo, tentar pegar o primeiro elemento de uma lista vazia, no JavaScript, vai te retornar apenas undefined. Bateu saudades do IndexError: list index out of range, né?\n1. O código é verboso demais no JavaScript — mas reconheço que isso é muito subjetivo. De qualquer forma, quem está acostuamdo com as _list comprehensions_ do Python acha um absurdo usar for (var i = 0; i < myList.length; i++) { … }.\n\n<blockquote class=\"twitter-tweet\" data-lang=\"en\"><p lang=\"en\" dir=\"ltr\">“Maybe this new JavaScript framework will compensate for the fact I haven’t actually learned JavaScript properly” - every front-end dev.</p>&mdash; I Am Devloper (@iamdevloper) <a href=\"https://twitter.com/iamdevloper/status/646377503708180480\">September 22, 2015</a></blockquote> <script async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\"></script>\n\nMas não podemos nos livrar do JavaScript – pelo menos não tão cedo. Ele roda em todos os navegadores, assim é a linguagem padrão disponível para UI e UX na web, seja em computadores, tablets ou celulares.\n\nE, por sorte, existem coisas boas no JavaScript!\n\n<p class=\"center\"><a data-flickr-embed=\"true\"  href=\"https://www.flickr.com/photos/nathansmith/4704268314/in/photolist-7GpUK-6ST9B3-8aGB5o-fTCL3F-9TWvEB-gaya1o-9YqyAw-5f36kS-b57b8-25HCdL-4asvCK-fhJHmi-6a5wWc-9tcEHs-qzq6Zh-7LgmGg-4Xbkrh-a7irkb-friuJ-3X6Eva-kAdNa-8YFiDS-ddoqGv-ir5k7h-5Gs23D-5kxRd2-qNti2-3zS6bR-kAdMR-nYNyx4-tp1D5-9odX5P-gKTzb3-QWFGA-d9UrEv-6an3df-4EcFGg-8KotxH-2yZBLA-6TAYsz-K23BZ-9fZ1Uo-nMEeFu-7JdAbX-73pVad-nVhADg-9p9eiR-pUYo2G-ed9n87-b7diEe\" title=\"JavaScript: Good Parts vs. The Rest\"><img src=\"https://c3.staticflickr.com/5/4066/4704268314_bb0e9d0ff3.jpg\" width=\"500\" height=\"299\" alt=\"JavaScript: Good Parts vs. The Rest\"></a><script async src=\"//embedr.flickr.com/assets/client-code.js\" charset=\"utf-8\"></script></p>\n\nEsse livro da foto, e essa palestra do mesmo autor, desmisitificam uma crítica muito comum: _JavaScript é lento_. Não é. O que é lento é o DOM, ou, mais precisamente, alterar o DOM. Então vamos falar sobre o DOM.\n\nPrecisamos falar sobre DOM\n\nO problema com o DOM é que a cada alteração mínima na página, o JavaScript tem que processar a nova entrada, pedir permissão ao navegador para alterar o DOM, destruir o nó que vai ser substituído no DOM, criar o novo nó, recalcular como renderizar a página atualizada (incluindo processar todos os estilos CSS), avisar o navegador que a mudança foi feita e atualizar as referências ao DOM no JavaScript. Tudo isso, digamos, a cada mudança que ocorre na tela (sem que a página toda seja recarregada).\n\n<p class=\"center\"><a data-flickr-embed=\"true\"  href=\"https://www.flickr.com/photos/w32blaster/7602439048/in/photolist-czNugj-9MXNBX-8YVBdG-8r7Uxg-bWE9EF-6awWxx-2HL4KW-8ukJBe-bE86Mn-2GUYkr-6YJVE4-2ASEPt-5oL6vv-qYJFbv-ekvCg-7Vgjq8-eUxXgA-dVjz68-qbnyg3-jHxg5v-bF4kw2-9EG24D-9sN9Az-9UFbdX-mwjKqK-9p5MN6-97SGSG-fTp6AY-qQcex6-r92iPe-4n4YMA-5NswtU-5zzEc5-5Fggna-7azyaC-d6dswj-zgpzS8-aGaPmc-pLxNkR-gUUGnv-6XDrCu-73wbZe-3cYXt7-hE7nxY-qGEDTv-9LpCVN-aSPbL8-9xgzry-4FCUZX-9toZqH\" title=\"Facebook notifications\"><img src=\"https://c1.staticflickr.com/8/7113/7602439048_e6e4436115_o.jpg\" width=\"355\" height=\"211\" alt=\"Facebook notifications\"></a><script async src=\"//embedr.flickr.com/assets/client-code.js\" charset=\"utf-8\"></script></p>\n\nImagine você no Gmail ou Facebook: uma mensagem nova chega no chat, tem uma notificação com o número de mensagens que aparece, a janela de chat aparece e pisca, o nome da pessoa fica diferente na lista de amigos. E ao mesmo tempo a página segue mudando com mais um email, mais um comentário, etc. Cada coisinha dessa requereria uma sequência como a do parárafo anterior. É muita alteração no DOM e isso tende a ser custoso.\n\nPara resolver esse problema a ideia foi criar um DOM virtual. A cada mensagem nova no chat, ao invés do JavaScript sair alterando cada coisinha no DOM, primeiro ele processa _todas_ as alterações em um DOM virtual. Depois ele compara o DOM virtual com o DOM real e altera-o uma única vez. Essa é a estratégia de vários _frameworks_ como o React e o Vue, ou mesmo a estratégia de front-end do AngularJS ou do Ember.js.\n\n<blockquote class=\"twitter-tweet\" data-lang=\"en\"><p lang=\"en\" dir=\"ltr\">“The Top 100 JavaScript Frameworks of 2015″<br><br>ಠ_ಠ this is an issue.</p>&mdash; I Am Devloper (@iamdevloper) <a href=\"https://twitter.com/iamdevloper/status/661168082572939265\">November 2, 2015</a></blockquote> <script async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\"></script>\n\nIsso resolveu o problema do custo da alteração do DOM. Mas não resolveu a nossa dependência do JavaScript para isso. Até que chegou o Elm.\n\nBem vindo, Elm\n\nO Elm chegou com várias promessas ótimas. Ele promete ser mais rápido que as alternativas mencionadas anteriormente:\n\n<img src=\"media/2016-09-17-porque-elm-01.png\" alt=\"Elm: Blazing Fast HTML, Round Two\">\n\nE, entre outras coisas, promete _no runtime exceptions_, ou seja, sem erros na hora do usuário executar a aplicação. A NoRedInk, pioneira na adoção do Elm, tem uma aplicação em Elm de mais ou menos 36 mil linhas, rodando há 1 ano. Zero erros reportados.\n\nMas… como o Elm consegue? Esse é o foco da palestra.\n\nPrimeiros passos\n\nO primeiro passo para entender como o Elm consegue resolver esse problema é entender que ele não é só uma linguagem que compila para JavaScript. Ele oferece um ambiente de desenvolvimento único, sem paralelos com JavaScript. No final, por _acaso_, ele vira um .js para você integrar na aplicação. Por _acaso_ pois ele não depende do JavaScript e, se um dia os navegadores suportarem outra linguagem, ou mesmo Elm, o JavaScript some de cena sem deixar vestígios no ambiente de desenvolvimento Elm.\n\nElm é uma outra linguagem, com outra lógica, e com compilador próprio. Ela é uma linguagem funcional, trabalha com constantes e expressões — sempre.\n\nConhecendo a sintaxe e as mensagens de erro\n\nDepois de instalar o Elm, vamos brincar um pouco para sentir como ele é. Faremos isso abrindo o console, o _read–eval–print loop_, com $ elm-repl:\n\nNo Elm os tipos importam muito. E ele usa isso para verificar várias possibilidades de erro no código — e não compila enquanto você não resolver esses problemas em potencial. Vamos a alguns exemplos:\n\nQue tal tentar juntar um número inteiro com uma string?\n\nReparem como a mensagem de erro é clara: TYPE MISMATCH te diz qual o tipo do erro (o tipo de um valor não é o que o compilador espera), tem um ^^^^^^ sublinhando, na devida linha, qual valor é esse. Ainda tem uma dica: para concatenar texto, use ++ ao invés de +. E, por fim, um exclarecimento: ele diz que é o texto, e não o número, que ele acredita ser o problema pois ele começa avaliando o valor da esquerda, sempre. Se a gente tivesse colocado \"Ahoy\" ++ 42, ele reclamaria que o 42 não é texto.\n\nOutro exemplo: o Maybe. Imagine uma cenário onde, por algum motivo, você precisa do primeiro elemento de uma lista. Mas imagine que por algum motivo (talvez ainda desconhecido) aquela lista chegou ali vazia. No Python temos um IndexError, como já vimos. E no Elm?\n\nFaríamos assim com uma lista contendo três elementos. Mas repare no detalhe do tipo que essa função retornou, Just 1, e no tipo que essa mesma função retorna quando passamos uma lista vazia, o Nothing:\n\nO Elm sabe que uma lista pode ser vazia. E não te deixa esquecer disso. Quando você for usar um valor que vem de uma lista, você tem que prever esse cenário. Por isso ele não retorna um número, no nosso caso, logo de cara. Ele retorna Just 1 ou Nothing — sendo que 1 é o primeiro item da nossa lista.\n\nSe quisermos somente o número, sem o tipo Just <número>, podemos dizer qual é o valor padrão:\n\nÉ com estruturas e lógicas como essa que o Elm consegue prometer – e cumprir — a promessa de não deixar passar erros.\n\nCompilando e colocando a mão na massa\n\nMas e como desenvolvemos algo _de verdade_? Bom, vamos por partes.\n\nComecemos com um arquivo simples, Main.elm:\n\nTodo arquivo Elm que vai ser compilado espera uma função main. E essa função main tem que retornar um Html — afinal, o Elm é pensando para produzir interfaces para navegadores.\n\nEntão importamos uma função, text, que retorna um Html. Depois definimos que a função main: ela retorna seja lá o que for que aquela função Html.text produzir quando passarmos a ela um texto \"Ahoy\".\n\nA primeira linha é padrão em todo arquivo Elm: você dá um nome ao módulo que está criando ali naquele arquivo (e esse nome tem que bater com o nome do arquivo). O (..) define o que desse módulo é acessível externamente — algo com o que não precisamos nos preocupar agora (.. define que tudo é acessível externamente).\n\nFeito isso, é só compilar: $ elm-make Main.elm. Inspecionando o diretório, vamos ver quatro arquivos:\n\n Main.elm é o nosso código fonte.\n index.html é o nosso código compilado em HTML, com o JavaScript embutido, pronto para rodar no navedagor — não tenha medo, abra para ver como ficou!\n elm-package.json e elm-stuff são criados pelo próprio Elm para controlar teu projeto.\n\nSe quisermos compilar somente o JavaScript, para incluí-lo no HTML separadamente, podemos: $ elm-make M",
  "canonicalUrl": "https://cuducos.me/porque-elm.html"
}