Conteúdos
  1. 1. Syntatic sugar
  2. 2. Mas eu quero fazer X!
  3. 3. Mas a sintaxe não permite!
  4. 4. Mas não dá pra fazer polyfill de X!
  5. 5. Mas…

Reclamar do JavaScript é um dos atuais hypes na programação, alguns reclamando das novas features que estão surgindo, outros reclamando que deveria estar indo ainda mais rápido, outros ainda reclamando que a linguagem é simplesmente ruim e ponto. Sinceramente, acho que a única resposta que serve para todos esses tipos de reclamação é: adicione açúcar a gosto e pare de reclamar.

Antes que comece com “ah, mas não dá pra fazer X com JavaScript, minha linguagem tem X no core” eu espero que você leia o post até o fim.

A primeira coisa que você deve considerar quando for reclamar que JavaScript não faz algo é: a não ser que os desenvolvedores dos browsers mais usados implementem hoje a tal feature que você quer, e todos os usuários atualizem seus navegadores assim que o update sair, a linguagem passar a ter a tal feature na especificação não vai fazer que todos que acessem seu site tenham acesso à ela. Compreendeu agora?

Diferentemente da sua linguagem que tem X no core, JavaScript roda no navegador do cliente (NodeJS não se encaixa nesta parte da discussão, mas ao longo do post ele voltará a equação). Então, ao invés de ficar reclamando que JavaScript não faz algo, simplesmente adicione açúcar e faça-o fazer.

E mais, se você usa o argumento de o fato de o JavaScript “monopolizar” o front-end ser uma coisa ruim, pense um pouco: se só com JavaScript e CSS já existe essa fragmentação imensa de hoje em dia, já imaginou se existisse ainda mais linguagens com diferentes especificações? É, pois é, então vamos lá.

Syntatic sugar

Se você ainda não sabe, adicionar syntatic sugar à uma linguagem/código significa implementar algo nesta linguagem para deixar ela mais simples de compreender por humanos, enquanto o funcionamento “por baixo dos panos” continua utilizando somente o que a linguagem oferece inicialmente.

O uso de syntatic sugar é de grande importância no JavaScript, principalmente quando se trata de uma feature que pode ser adicionada usando-se um polyfill, pois isso faz com que JavaScript tenha uma quantidade ainda maior de possibilidades a oferecer ao programador. Mas se é algo que parece não ser ser possível usando polyfill, não se precipite, você pode se surpreender!

Mas eu quero fazer X!

Ok, vamos lá, você quer que JavaScript consiga fazer algo. Porque não parar de reclamar e adicionar esta feature de alguma maneira? As pessoas reclamavam que era difícil manipular o DOM com a API original, e daí nasceram bibliotecas como o MooTools e o jQuery, nem tudo tem que vir built-in na linguagem.

Reclamar que algo não vem no core da linguagem está longe de ser um motivo para você dizer que JavaScript é uma linguagem ruim. Se você já ouviu falar de LISP alguma vez na sua vida vai saber muito bem do que eu estou falando.

O core do LISP não possui tantas capacidades assim, a quantidade de palavras reservadas da linguagem é bastante limitada, mas ainda assim as pessoas consideram o LISP como a maior das linguagens de programação. Porque? Entre outros motivos, pela capacidade de a linguagem poder ser incrementada através de macros. Os macros do LISP permitem adicionar syntax sugar à linguagem de uma maneira impressionante. O que nos leva ao próximo ponto.

Mas a sintaxe não permite!

Dizer que a sintaxe de uma linguagem de JavaScript não é amigável ou não te permite fazer também não é um desculpa.

Você já ouviu falar das linguagens que compilam para JavaScript? Pois é, existem várias, pra todo tipo de gosto, cada um com seu syntax sugar diferente.

Prefere algo mais tradicional, que continue usando a sintaxe do JavaScript mas adicione novas features? O Babel ou o sweet.js devem ser o suficientes pra você (E mais: se você optou pelo Babel, saiba que tudo que ele adiciona tem a pretensão de estar no core do JavaScript alguma hora, já que ele trabalha com stages, inclusive para ser usado nativamente dentro de um app NodeJS, que vai rodar dentro do seu servidor e não vai depender do navegador do cliente). Não gosta de ter que usar um transpiler de código? Dê uma olhada no ease.js, então.

Você é do tipo de pessoa que prefere uma sintaxe diferente, com blocos baseados em indentação? Talvez CoffeeScript seja o seu negócio. E se você gosta da sintaxe do Coffee mas ainda assim acha que falta algo para melhorar sua vida quando está trabalhando com código assíncrono, dê uma olhada no IcedCoffeeScript.

Prefere linguagens tipadas? Acha que elas são mais seguras e te ajudam a desenvolver melhor? Sem problemas, talvez antes de reclamar por este motivo você deva dar uma chance ao TypeScript, da Microsoft, ao Dart, do Google, ou ao Flow, do Facebook. Empresas grandes adicionando seus próprios açúcares ao JavaScript, qual sua desculpa? :)

É um fã de programação funcional? Acha que JavaScript “puro” não é funcional o bastante (e não é mesmo)? Olha, acho que você ainda não deve conhecer o Elm nem o LiveScript para estar reclamando assim. Se você se sente confortável programando em Haskell, a curva de aprendizagem destas linguagems vai ser bem suave para você.

Mas não dá pra fazer polyfill de X!

Bom, agora espera lá. Não dá pra fazer polyfill do que você quer fazer, ou não dá pra fazer isso de maneira que você conhece?

Vou te dar um exemplo de algo que o JavaScript não suporta, e te mostrar um exemplo de syntax sugar que torna possível, o que acha? Que tal implementar algo como o method_missing do Ruby em uma linguagem que compila para JavaScript? Bom, clique aqui e veja com seus próprios olhos :)

Entendeu agora o que eu quero dizer? Falar que JavaScript não é capaz de algo só mostra que você está se limitando ao que te parece confortável, porque muito possívelmente o que você quer é possível de ser implementado sim.

Quer usar o sistema de classes, módulos e tipos do Ruby no front-end? Dê uma olhada no Opal. Já existem até adapters de bibliotecas bem conhecidas do JavaScript para ele, como o jQuery e o React. Além de frameworks produzidos especialmente para a linguagem, como o Inesita e o Volt.

É mais fã do Python? Que tal experimentar o Brython, o Skulpt ou o PyPy.js antes de falar algo? Já existe até um pessoal fazendo a comparação da velocidade do CPython às do Brython, do Skulpt e do PyPy.js.

Prefere Clojure e linguagens LISP-like? O ClojureScript tem uma comunidade maior e mais forte do que você pode imaginar, o Om que o diga! O Om é um adapter do React para ClojureScript, que é usado, por exemplo, para fazer o front-end do CircleCI. Não acredita? Veja com seus próprios olhos.

Gosta mesmo é de Scala? Talvez te supreenda então a existência do Scala.js, que inclusive também tem adapters para bibliotecas como o React e o Angular.

Bom, eu não vou ficar aqui citanto todas as possiblidades que possam te levar a reclamar que a sua linguagem faz isso mas JavaScript não. O Jeremy Ashkenas, criador do CoffeeScript, já fez uma lista de linguagens que compilam para JavaScript para que você dê uma olhada antes de reclamar. Que tal?

E, me desculpe, mas se você vai usar agora a desculpa de que o código gerado por esses compiladores não é performático, vou precisar te lembrar que existem por aí linguagens que alegam que a programmer experience é mais importante que a performance, além de citar o Kyle Simpson, aka @getify, autor da série You don’t know JS com a seguinte frase:

Transpiled code isn’t great code, but it’s probably better than the code you’ve been writing for the last 20 years.

Mas…

Ok, talvez você só reclame porque é o que você gosta de fazer, nesse caso eu não tenho muito a dizer além de: keep calm and stop complaining.

Mas se você entendeu o que eu quis dizer, notou que as capacidades do JavaScript estão limitadas apenas pela quantidade de açúcar que você adiciona na linguagem: parabéns. Você sacou que o JavaScript é praticamente o assembly do desenvolvimento web, uma grande quantidade de pessoas não entende, mas criam alternativas mais alto nível que permitem gerar assembly no final.

Se você ainda tem algumas reclamações quanto a coisas como o this do JavaScript, ou como funciona a prototype chain da linguagem, temos duas alternativas aqui:

  1. Aprenda a linguagem direito antes de sair reclamando por aí;
  2. Simplesmente não use essas coisas que você não entende.

Existe uma vertente de programadores JavaScript que simplesmente não usam mais o this, por exemplo, e isso não faz deles maus programadores.

E, por fim, se gostou dessa ideia de adicionar açúcar mas ainda não achou algum JavaScript-like que te satisfaça, o que pode ser dito a você é: stop complaining and bring your own JavaScript.

Fonte das imagens:

Conteúdos
  1. 1. Syntatic sugar
  2. 2. Mas eu quero fazer X!
  3. 3. Mas a sintaxe não permite!
  4. 4. Mas não dá pra fazer polyfill de X!
  5. 5. Mas…