Porque Javascript é Prazeroso

Hoje li um post que Allen Cheung escreveu sobre o porque Javascript é prazeroso pra ele. Pedi autorização para traduzir para português e repassar, onde ele diz de forma didática, o porque. Fiz isso porque concordo plenamente com todo o post :)

Eu, provavelmente, sou um pouco tendencioso - ser um desenvolvedor front-end por alguns anos fez isso - mas eu realmente gosto de escrever Javascript. Recentemente me afastei da programação "pura", mas eutive uma oportunidade na semana passada de voltar a algumas tarefas, e isso me lembrou o quão divertido é mergulhar em nossa(Square) base de código front-end.

Sim, Javascript pode ser surpreendentemente elegante mesmo que completamente enfurecedor, tudo isso na mesma linha de código; durante um bom tempo, era a piada da comunidade de programadores, o "primo pobre" que chega a ser mais feio que o mais bizarro do PHP e Perl. Hoje em dia, JS é uma linguagem sob os holofotes, e ter sido exposto gradativamente a mais desenvolvedores me faz feliz de ter ficado preso a linguagem, verrugas, pús e tudo mais. Aqui está minha tentativa de reunir exatamente o porque eu gosto de trabalhar com Javascript.

Velocidade

O engine de Javascript do Google, V8, faz com que seja possível uma execução rápida do código (tanto no browser quanto nos servidores), e isso melhorou caminho para complexidades e estruturas. Agora, enviamos centenas de kbytes de Javascript minificado para o cliente e esperamos que tudo rode suave. Além de animações aceleradas pelo hardware, aplicativos móveis estão rapidamente alcançando os nativos, em termos de aparência e experiência.

Além do mais, JS é realmente rápido de se escrever e testar. Escreva - salve - atualize(E se for uma página totalmente estática, nem é necessário um servidor); é um ciclo de desenvolvimento absurdamente ágil que nos deixa iterar proporções questionáveis de código muito mais rápido que em qulquer outro ambiente que trabalhei. Com o prontamente disponível (e rápidamente instanciável) console e debugger do webkit, que é um ambiente bem poderoso e produtivo (Então, novamente, eu sou das antigas e uso console.log muito mais do que deveria). Eu também estou me "aquecendo" para começar a usar o Jasmine para testes unitários; tem o conjunto perfeito de ferramentas para lidar com objetos modernos de MVC e ter centenas de testes executados em questão de segundos. Ainda melhor, ter uma solução completa de testes executado e completo é um capricho para melhores práticas com TDD.

Simplicidade

Javascript é uma linguagem "leve" por assim dizer. A lista de palavras reservadas não intimida e existe um conjunto de tipos também nada intimidador, uma vez que você passa pela infeliz fusão automática de "string-number". JSON se transformou em um formato preferêncial de transferência, exatamente pela sua simplicidade, concisão e facilidade na leitura.

A web tem considerado o Javascript parte de sua linguagem nativa, e existem uma tonelada de outras ferramentas disponíveis, a maioria com setup mínimo. Minha questão favorita numa entrevista é colocar o candidato em frente a um computador com nada alem de um navegador e um editor de textos; não temos apenas o já mencionado navegador e console, mas também temos acesso a APIs, estruturas de dados para interfaces do usuário.

Ainda, eu não gosto de gerenciar versões de GEM, especialmente como pré-requisito para rodar minha instância de dev.

Liberdade

Com simplicidade vem o maior patrimônio do Javascript - a liberdade de programar do jeito que faça sentido pra você e os camaradas malucos que programam contigo.

Talvez, autores de frameworks querem manter os downloads pequenos, ou talvez eles estejam nessa filosofia compartilhada de manter as coisas simples, mas honestamente ainda não achei isso muito popular em libs/frameworks Javascript que os façam acreditar em seus sistemas, o mesmo com Rails, Django e CakePHP, configurando convenções estritas para seus respectivos frameworks (Sencha e Sproutcore são os únicos que me lembre agora. Cappuccino não conta). Os mais populares (ex. jQuery, Underscore.js, Backbone.js) além de serem completamente legíveis, mantidos e ter uma base de código limpa, limita seu escopo ativamente. Eles são projetados para fazer algumas coisas e felizmente são interoperáveis.

Um tema que surgiu sobre frameworks que eu tenho usado em ambos os lados (cliente e servidor) que é inevitável, eu reluto em lidar com convenções forçadas que quebram um ou mais problemas de interesse. Sou forçado a descer para camadas de abstração, buscando aquela atribuição da variável que eu desfaço novamente ao topo da pilha do software. Tanto corrigindo middleware no Pylons, controlando estruturas DOM em widgets GWT ou tunando alguns modals do Win32, ekes são significantes para começar mas oneram na sua cara, requisitos não tão convencionais.

Maleabilidade

Existe algumas verdades para a felicidade apagar um código: isso reduz a complexidade, arruma bugs e diminui o "footprint" da manutenção.

Então, de uma maneira estranha, sou feliz do jeito meio bagunçado que escrevo Javascript as vezes, mas isso tende a não durar muito. Por natureza, código front-end tem uma vida curta: páginas são reprojetadas, testes A/B melhoram em uma curta sucessão e minha dolorosa implementação de um carrossel pode não ter lugar num novo design. A natureza modular do Javascript me deixa refatorar um widget que não existe sen ter que provocar tipos hierárquicos e "desmetaprogramar" funções classe. É especialmente fácil quando tenho alguns testes dando apoio para o procedimento.

Sério, isso é tudo. Mais fácil para escrever que desescrever, Javascript é prazeroso.

Você pode ver o post original no blog de Allen Cheung.