Capítulo 2. Qual JavaScript você está usando?

Isso pode parecer que tem uma resposta fácil.Quão variada pode ser uma língua?
Bem, no caso do JavaScript, qualquer um deles pode impactar bastante suas ferra-
mentas e fluxos de trabalho:

Versões e especificações
Plataformas e implementações
Idiomas pré-compilados
Estruturas
Bibliotecas
Qual JavaScript você precisa?
Qual JavaScript estamos usando?

Estes podem representar não apenas maneiras diferentes de fazer as coisas, mas tam-
bém um investimento de tempo significativo para decidir, aprender a proficiência e,
eventualmente, escrever fluentemente. Ao longo deste capítulo, exploraremos essas
complexidades para descobrir qual JavaScript podemos escrever e, no restante do li-
vro, seremos mais específicos sobre qual JavaScript devemos escrever.

Algumas das escolhas envolvidas em qual JavaScript usar serão impostas pelo projeto,
algumas pelo framework e algumas por seus próprios gostos pessoais.

Desenvolver o estilo de codificação é um dos maiores desafios em qualquer lingua-

gem. Devido à complexidade e diversidade do ecossistema JavaScript, isso pode ser es-
pecialmente desafiador em JavaScript. Para se tornar um programador completo, al-
gumas pessoas recomendam aprender uma nova linguagem de programação todos os
anos. Mas com JavaScript, talvez você nem consiga aprender todos os dialetos em toda
a sua vida. Para muitos idiomas, “aprender o idioma” significa ser competente com
APIs, recursos e uma ou duas extensões/bibliotecas populares. A aplicação desse
mesmo padrão ao JavaScript deixa muitos contextos inexplorados.
QUAL ESTRUTURA DEVO USAR?

Essa é uma pergunta perene feita por desenvolvedores de JavaScript e uma forma es-
pecífica de linguagem provavelmente a maior pergunta de novos desenvolvedores:
“Qual linguagem devo aprender?”A esteira do framework pode dar aos programado-
res uma sensação de que eles realmente precisam saber tudo. Descrições de cargos
com requisitos inflados e até mesmo contraditórios não ajudam. Quando se trata de
JavaScript, existem tantos frameworks, plataformas e, em última análise, tipos distin-
tos de código que você pode escrever que alguma forma dessa pergunta surge uma e
outra vez.

No final, você não pode aprender tudo. Se você tem um emprego ou trabalho-alvo que
realmente requer certas habilidades, gaste seu tempo com elas primeiro. Se você não
tem um trabalho específico em mente, encontre amigos e mentores em encontros e
siga o que eles fazem. Ou, se você está apenas preocupado em aprender algo que é in-
teressante para você, escolha algo que pareça legal* e vá tão fundo quanto quiser, en-
tão siga em frente e, em algum momento, considere se tornar muito hábil com um pu-
nhado dessas tecnologias.

Você pode aplicar esse mesmo processo (filtrando por exigência de trabalho, o que
seus amigos estão usando e o que você acha legal) em linguagens, frameworks, biblio-
tecas de teste ou instrumentos musicais. Em todos eles, vá fundo de vez em quando e,
se você me perdoar um pouco de conselho grosseiro, fique de olho onde está o
dinheiro.

*“Parece legal” pode soar vago, e é. Para mim , isso significa encontrar a tecnologia
mais inovadora ou alucinante para mim . Não é provável que eu aprenda 14 variantes
de algo que resolva o mesmo problema. Para outros, cool significa novo e moderno.
Para outras pessoas significa popular ou lucrativo. Se você não sabe o que “parece le-
gal” significa para você, resolva isso fazendo viagens superficiais em algumas possibi-
lidades, em vez de gastar muito tempo imaginando qual escolher.

Versões e especificações

Se você quiser saber onde está o JavaScript e para onde está indo, você devesiga o que
está acontecendo com a especificação ECMAScript . Embora os recursos do JavaScript
possam surgir de bibliotecas e implementações específicas, se você estiver procu-
rando a fonte canônica de recursos que provavelmente permanecerão, observe a es-
pecificação ECMAScript.

Especificamente (no momento da redação deste artigo), o comitê responsável por ras-
trear e adotar novos recursos na especificação é chamado TC39. As propostas de espe-
cificações passam por um processo de várias etapas para adoção. Você pode acompa-
nhar as propostas em todos os cinco estágios (0–4) no GitHub .

M O D O E S T R I TO

Como há uma variedade de implementações (principalmente navegadores) no uso da web, e

“quebrar sites antigos” geralmente é visto como algo ruim, é improvável que os recursos do Ja-
vaScript sejam preteridos a ponto de cair em desuso.

Infelizmente, o JavaScript contém alguns recursos que causam imprevisibilidade e outros que
prejudicam o desempenho apenas por serem disponibilizados.

Existe um subconjunto opcional de JS mais seguro, rápido e disponível para desenvolvedores

que fazem escopo de arquivos ou funções com "use strict" .

Geralmente, é considerado uma boa prática usar o modo estrito. Alguns frameworks e lingua-
gens pré-compiladas o incluem como parte do processo de compilação/compilação. Além disso,
os corpos das expressões e declarações de classe incluem "use strict" por padrão.

Dito isso, seguir as especificações do ECMAScript tem duas grandes desvantagens. Pri-
meiro, a documentação bruta pode ser intimidante em tamanho e ênfase. Geralmente
é escrito para aqueles que criam navegadores em vez de aplicativos ou sites. Em ou-
tras palavras, para a maioria de nós, meros mortais, é um exagero. Alguma exposição
a ele é útil, no entanto, para aqueles que gostam de descrever os recursos de uma ma-
neira mais acessível por meio de postagens de blog ou preferem não ter que confiar
nessas postagens de blog como sua fonte de verdade.

A segunda desvantagem é que mesmo quando uma proposta de especificação é finali-

zada (estágio 4), não há garantia de que suas implementações de destino (ou seja, nó
ou navegadores de destino) tenham disponibilizado a funcionalidade descrita. No en-
tanto, a especificação está longe de ser hipotética, pois as especificações são influenci-
adas pelos implementadores (por exemplo, fornecedores de navegadores) e, em mui-
tos casos, uma implementação específica pode ter um recurso implementado antes
mesmo de ser finalizada na especificação.
Se você estiver interessado em recursos que uma especificação disponibiliza, mas que
ainda não são suportados pela implementação escolhida, três palavras que você de-
seja saber são shims , polyfills e transpilers . Pesquisando “como posso dar suporte a
<qualquer recurso> em <alguma plataforma>” (node, Firefox, Chrome, etc.), combi-
nado com esses termos, provavelmente fornecerá a resposta que você está procu-
rando.

Plataformas e Implementações

Quando o node entrou em cena, os desenvolvedores da web experimentaram uma

combinação de alívio e entusiasmo com a perspectiva de escrever a mesma lingua-
gem tanto no back-end quanto no front-end.Outros lamentaram o fato de JavaScript
ser a linguagem a ter um papel tão proeminente.

Essa promessa teve resultados mistos. O ecossistema JavaScript floresceu com o bac-
kend empurrando o frontend para ser tratado mais como código real (organizacional-
mente e paradigmaticamente), enquanto a pura massa de desenvolvedores frontend
disponíveis garantiu que as plataformas de backend sempre atraíssem contribuidores
novos e curiosos.

Por outro lado, até o momento em que este artigo foi escrito, embora tenham sido fei-
tas tentativas, os frameworks JavaScript full-stack (às vezes chamados de “isomórfi-
cos” para executar o mesmo código em dois lugares) não eram tão populares entre os
desenvolvedores quanto os frameworks dedicados de front-end e back-end. estive. En-
quanto dentro do Rails do Ruby e do Django do Python há um claro centro de ativi-
dade de framework, nenhum “grande framework unificador” surgiu no cenário vi-
brante mas volátil do JavaScript.

No navegador, o código JavaScript gravita naturalmente em direção ao window objeto

base, interações com o DOM e outros recursos do navegador/dispositivo.No lado do
servidor de um aplicativo da Web, o gerenciamento de dados e as solicitações de pro-
cessamento são a preocupação fundamental.Mesmo que a linguagem no front-end e
no back-end seja “a mesma”, os tipos de código escritos estão de acordo com a tarefa
em questão, de modo que é improvável que sigam padrões semelhantes de organiza-
ção de código.

Embora a especificação ECMAScript determine quais recursos provavelmente serão

implementados e suportados, você só pode usar o que é suportado por sua implemen-
tação (ou bibliotecas que você traz). Em qual versão do nó ou em qual versão do nave-
gador você está confiando é onde a especificação encontra a realidade.

Para rastrear quais recursos estão disponíveis nativamente nos navegadores,

caniuse.com mantém uma lista atualizada do que está disponível em relação não ape-
nas a APIs JavaScript, mas também a HTML e CSS.Para considerar implementações de
front-end e back-end, você pode encontrar um rastreamento de recursos mais amplo
nas tabelas de compatibilidade ECMAScript da Kangax .

Se você estiver especificamente interessado em quais novas propostas ECMA/TC39são

implementados em uma determinada plataforma, você pode filtrar essa tabela para
mostrar propostas que ainda não fazem parte do padrão atual .

As implementações de uma linguagem de programação também podem ser chamadas

de runtimes ou instalações .Versões específicas de JavaScript, especialmente quando
existem implementações em um navegador, às vezes são chamadas de mecanismos Ja-
vaScript .No que diz respeito às versões, além de ter os tradicionais números de versi-
onamento, a relação da versão com seu ciclo de lançamento faz com que seja possível
ver as palavras build ou release usadas para descrever onde ela está no processo.Você
pode ver termos como compilação noturna , compilação semanal , versão estável ou
versão de suporte de longo prazo .

Recursos experimentais (não da especificação ECMAScript), recursos não normativos

(não especificados pela especificação) e lacunas na especificação variam de navega-
dor para navegador e de compilação para compilação. Alguns recursos que acabaram
em uma especificação finalizada existiam em bibliotecas ou implementações de anos
anteriores. Outros recursos dentro das implementações murcham e se tornam obsole-
tos quando são substituídos ou ignorados pela especificação ECMAScript e outros
implementadores.

Alguns lugares em que o JavaScript está aparecendo não se encaixam perfeitamente

na linguagem de “plataforma” ou “implementação”. O JavaScript pode ser usado
como linguagem de origem para aplicativos executados em dispositivos móveis, siste-
mas operacionais de desktop e até microcontroladores.

Embora todos esses sejam caminhos interessantes para o ecossistema, acompanhar

quais recursos JavaScript estão disponíveis em cada contexto, infelizmente, não é
uma tarefa trivial.
Idiomas pré-compilados

Até agora, vimos que implementações, plataformas e cada versão da especificação EC-
MAScript têm seu próprio conceito do que é JavaScript.Então, qual JavaScript você
deve escrever?

Primeiro, vamos pegar o caso mais simples de JavaScript “compilado” versus “fonte”:
um processo chamado minificação .Um minifier irá comprimir seu código para reduzir
o tamanho do arquivo, deixando o mesmo significado. No contexto do navegador, isso
significa um download menor para o usuário do site e, consequentemente, um carre-
gamento mais rápido da página.

No entanto, a minificação está longe de ser o único caso de uso para compilar JavaS-
cript em outro JavaScript. Um projeto particularmente bem-sucedido, Babel.js, come-
çou com o objetivo de permitir que os desenvolvedores fizessem uso de recursos futu-
ros do JavaScript, tomando como entrada o código-fonte que potencialmente ainda
não funcionaria na implementação de destino e, em seguida, compilando-o em uma
sintaxe mais antiga com melhor adoção .

Outras linguagens pré-compiladas visam especificamente um conjunto de recursos

que pode não ter nada a ver com a especificação ECMAScript, mas ainda parece inspi-
rado em JavaScript.Sweet.js permite que os desenvolvedores adicionem novas pala-
vras-chave e macros ao JavaScript. O React como um todo está fora do escopo desta
seção, mas a linguagem frequentemente usada com ele, JSX, também é uma lingua-
gem pré-compilada que se lê como uma mistura de JavaScript e HTML. Como evidên-
cia da expansão do Babel, tanto Sweet.js quanto JSX são compilados em JavaScript
usando-o.

Um efeito interessante da relação de amor/ódio que muitos desenvolvedores têm com

JavaScript é que isso levou a uma explosão de bibliotecas, algumas com uma etapa de
compilação que as define como linguagens pré-compiladas. Eles visam tratar o JavaS-
cript como um “alvo de compilação”.

Em uma raiva contra chaves e uma (antiga) falta declasses, CoffeeScript ganhou popu-
laridade como uma forma de escrever (preferível a alguns) código compilado em Ja-
vaScript. Muitas outras pré-compilações adotam uma abordagem semelhante: escreva
o código da maneira que você deseja (usando uma linguagem nova ou preexistente) e
ele será compilado em JavaScript. Embora o CoffeeScript tenha caído em desuso, ou-
tras linguagens pré-compiladas estão aumentando para preencher outras lacunas per-
cebidas (ou apenas falta de consistência) no JavaScript.

Seria ótimo dar uma visão geral de todas as linguagens que compilam em JavaScript,
mas existem 337 delas documentadas no wiki do projeto CoffeeScript até o momento.
Se você precisava de mais evidências da importância das plataformas JavaScript, da
desconfiança da própria linguagem ou da complexidade do ecossistema do JavaScript,
esse é um bom número para se ter em mente.

Estruturas

Vamos voltar à pergunta original do capítulo: “qual JavaScript você está usando?”

Com nosso conhecimento atual de especificações, plataformas, implementações e lin-

guagens pré-compiladas, poderíamos “escolher um JavaScript” para um site para
quaisquer navegadores que desejássemos usar usando recursos suportados.Ou pode-
mos optar por construir um programa fora do navegador usando node. Poderíamos
até usar uma linguagem pré-compilada para preencher ou estender o código que que-
remos escrever e evitar escrever JavaScript real . Mas os frameworks fornecem outra
possibilidade.

Os frameworks podem unificar plataformas e implementações, bem como estender o

vocabulário do JavaScript que estamos usando. E se você sentir, por algum motivo,
que não tem decisões suficientes a tomar para determinar qual JavaScript está
usando, os frameworks estão aqui para fornecer mais opções (por favor, bata
palmas).
BAUNILHA.JS

Um framework JavaScript paródico chamado Vanilla.js defende o uso de nenhum fra-

mework (“vanilla” às vezes é usado como sinônimo de “simples” ou “sem adornos”). À
medida que os padrões melhoram e as implementações se unem em torno de recursos
comuns, o caso parece ficar mais forte.

Por outro lado, a falta de vontade de descontinuar funcionalidades confusas, fora do

padrão e duplicadas (olhando para você, prototype , __proto__ e
Object.getPrototypeOf ) garante um conjunto de recursos fragmentado e extenso.

Talvez algo como "use strict" permita a unificação de implementações (e obvia-

ção de frameworks) no futuro, mas eu não apostaria nisso.

Os frameworks jQuery, Ember, React, Angular e similares são basicamente superbibli-

otecas. Muitos, como o Ember, lidam com questões de organização, empacotamento,
distribuição e teste de código.Alguns criam uma nova sintaxe para escrever HTML,
como Angular. O React ainda contém sua própria linguagem pré-compilada (o JSX
mencionado anteriormente), que não será executado sem compilação.

A pegada do jQuery ainda é sentida em muitos aplicativos. Os recém-chegados acham

que a diferença entre JavaScript e jQuery é significativa o suficiente na sintaxe e no
propósito de que eles ainda perguntam o que devem aprender. Esta é uma questão
permanente que qualquer framework (frontend ou backend) enfrentará.

A linha entre frameworks e bibliotecas é um pouco turva, mas sempre que você vê
essa pergunta sobre uma biblioteca, isso indica (além de um pouco de confusão por
parte do questionador) que você está lidando com um framework que não asseme-
lham-se ao JavaScript o suficiente para serem reconhecíveis para o iniciante.

O termo framework está incrivelmente sobrecarregado.Alguns frameworks que lidam

especificamente com a simplificação e unificação das interações do navegador, como
jQuery, usam o termo framework JavaScript , enquanto você podever coisas comoEm-
ber referido como estruturas da Web ou estruturas de aplicativos . As estruturas de
aplicativo/web tendem a vir com sua própria etapa de compilação/compilação, um
servidor de aplicativo, uma estrutura de aplicativo base e um executor de teste.

Para confundir ainda mais as coisas, praticamente qualquer biblioteca pode anexar a
palavra framework a si mesma (por exemplo, “framework de teste”) e parecer mais
importante. Por outro lado, o Electron, que permite que aplicativos de SO de desktop
sejam construídos usando HTML, CSS e JavaScript, também usa a palavra framework ,
enquanto na taxonomia deste capítulo está mais próximo de uma plataforma em si.

Bibliotecas

Independentemente de como se chamam, as bibliotecas geralmente se distinguem dos

frameworks, pois tendem a ter um propósito mais especializado e a serem menores
(ou pelo menos mais humildes).No momento da redação deste artigo, o Underscore.js
se autodenomina uma “biblioteca que fornece toda uma confusão de úteis auxiliares
de programação funcional”.

Qual JavaScript você está escrevendo?

Até agora, você tem a opção de segmentar plataformas e implementações específicas.

Além disso, você pode decidir usar “frameworks”, que podem simplificar processos,
unificar implementações, habilitar "use strict" e introduzir uma etapa de
compilação/compilaçãoque pode incluir uma linguagem pré-compilada antes que o
JavaScript seja gerado.

Tudo o que as bibliotecas tendem a adicionar a isso é uma combinação de mais recur-
sos e possível depreciação de outros (à la "use strict" ).

Qual JavaScript você precisa?

É uma pergunta difícil. Aqui estão quatro coisas para tentar.

1. Siga o hype.
Honestamente, se você não tiver certeza, seguir o hype é a melhor coisa que você
pode fazer. Escolha estruturas populares. Escolha bibliotecas populares. Segmente
as plataformas e implementações mais populares que fazem sentido para seus
aplicativos e programas. Ter uma grande comunidade significa que eles provavel-
mente também terão uma quantidade razoável de documentação e código de
exemplo.
2. Tente algo obscuro.
Depois de explorar as opções mais populares, procure um framework que seja
único e o ajude a pensar sobre as coisas de uma maneira diferente. Procure seme-
lhanças e diferenças na versão mais popular que você tentou.
3. Use todas as ferramentas possíveis.
 Veja o quão inchado e complicado você pode tornar seu processo de teste apresen-
tando todas as bibliotecas que puder.
4. Vá minimalista.
Veja até onde você pode chegar com Vanilla.js em uma determinada implementa-
ção. Depois de ganhar alguma experiência com ferramentas, pode ser revigorante
começar do zero, trazendo ferramentas apenas quando elas se justificarem. Esse
processo é abordado quando introduzimos gradualmente uma estrutura de teste
no Capítulo 4 .

Que JavaScript estamos usando?

Com tantas opções para JavaScript, pode parecer impossível escolher qualquer forma
para este livro. Veja como estamos lidando com isso:

Sem frameworks (exceto por algumas menções).

Sem etapas de compilação/transpilação/minificação.
A maior parte do código é executável sem um navegador, usando pacotes de nú-
cleo de nó padrão.
Algumas bibliotecas são trazidas para testes (mocha, tape, testdouble, wish).
Mais dois são usados ​para programação funcional (Ramda, Sanctuary).

Quanto ao estilo,este livro destina-se a prepará-lo para adaptar e aprimorar bases de

código de estilos e qualidades variados. Vamos explorar programação procedural,
POO e programação funcional.

Você verá muito código ruim antes que as melhorias sejam aplicadas. Mas o código
depois pode não ser o ideal, ou no seu estilo preferido (ou mesmo no meu). Damos pe-
quenos passos seguros e, para demonstrar uma ampla variedade de técnicas, não po-
demos levar cada trecho de código à perfeição desde sua primeira forma.

Você encontrará a mesma situação em bases de código legadas e, em geral, a quanti-

dade de código ruim provavelmente supera a boa, tanto em tamanho quanto em vari-
ações. Através deste livro, nos movemos incrementalmente para melhorar as coisas.
Há uma tentação ao olhar para uma base de código legada de pensar: “Isso é lixo. Pre-
cisamos jogar tudo fora e usar essa estrutura/estilo/qualquer coisa.” Mas aí você pro-
vavelmente está descrevendo uma reescrita , que é um processo ambicioso (leia-se
“caro e arriscado”). Nos estilos e mudanças apresentados neste livro, algumas vezes
passamos de ruim para bom, e outras vezes de bom para melhor. Mas através dessa
amplitude, exploraremos uma gama de opções para você aplicar em seu próprio
trabalho.

Empacotando

Conforme abordamos neste capítulo, suas opções de como usar JavaScript são incri-
velmente amplas. Essa situação pode mudar no futuro, mas eu não apostaria muito
em nenhum JavaScript verdadeiro . O ecossistema é tão variado que você pode explo-
rar maneiras completamente diferentes de codificação e ainda ficar um pouco perto
de casa. Embora o fato de “conhecer JavaScript” ser algo como um alvo em movi-
mento tenha suas frustrações, também significa que a perspectiva é ótima para en-
contrar novos interesses e trabalhar com JavaScript(s) .

Apoiar Sair

© 2022 O'REILLY MEDIA, INC.  TERMOS DE SERVIÇO POLÍTICA DE PRIVACIDADE