Por que a recente mudança para remover / omitir ponto-e-vírgulas do Javascript?

Suponho que meu motivo seja o mais injusto: eu programo em muitos idiomas diferentes ao mesmo tempo (Java, Javascript, PHP) - que requerem ';' então, ao invés de treinar meus dedos e olhos, o ';' não é necessário para o javascript, apenas adiciono sempre o ';'

O outro motivo é a documentação: adicionando o ';' Estou declarando explicitamente a mim mesmo onde espero que a declaração termine. Então, novamente eu uso {} o tempo todo também.

Todo o argumento da contagem de bytes que considero irritante e inútil:

1) para bibliotecas comuns como jquery: use o google CDN e a biblioteca provavelmente já estará no cache do navegador

2) versão suas próprias bibliotecas e configurá-los para ser armazenado para sempre.

3) gzip e minimize se realmente, realmente necessário.

Mas quantos sites têm como maior gargalo a velocidade de download de seu javascript? Se você trabalha para um site top 100 como o twitter, google, yahoo, etc. talvez. O resto de nós deve apenas se preocupar com a qualidade do código e não com as guerras religiosas de semicolon.

Torna o encadeamento de métodos mais fácil e compromete os diffs cleaner

Então, digamos que eu esteja jQuerying e eu tenho

$('some fancy selector')
  .addClass()
  .attr();

Se eu quiser adicionar coisas e manter meu diff com base em linha pequeno , eu tenho que adicioná-lo acima de attr. Então, é um pensamento mais longo do que apenas "adicionar no final". E quem quer pensar? =)

$('some fancy selector')
  .addClass()
  // new method calls must go here
  .attr();

Mas, quando eu derrubar o ponto-e-vírgula, posso apenas acrescentar e chamar um dia

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate()
+   .click()

Além disso, se eu decidir usar o último método, não preciso reatribuir o ponto-e-vírgula e poluir meu commit novamente.

  $('some fancy selector')
    .addClass()
    .attr()
    .animate()
-   .click()

Versus o uggo

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate();
-   .animate()
-   .click();

ponto e vírgula em JavaScript são opcionais

Minha razão pessoal para não usar o ponto-e-vírgula é o TOC.

Quando eu uso semi-e-vírgulas eu me esqueço de 2% deles e tenho que checá-los / adicioná-los constantemente.

Quando eu não uso o ponto-e-vírgula, eu nunca coloco um em um por engano, então eu nunca preciso checá-los / removê-los.

Recentemente, escrevi um analisador / analisador para JavaScript, no qual tive de implementar meticulosamente o ASI, e também tenho minha cópia do JavaScript: The Good Parts de Crockford na minha estante, que defende sempre usando ponto e vírgula. A intenção era boa, mas nem sempre ajuda na prática.

Obviamente, as pessoas que escrevem frameworks como jQuery, zepto, etc. são mestres de sintaxe JavaScript e, portanto, sabem a diferença entre:

return
{
    status: true
};

e

return {
    status: true
};

O JavaScript, embora poderoso, também é um idioma para iniciantes e boa sorte explicando isso para alguém que está aprendendo o que é um for loop. Como introduzir a maioria das pessoas a uma nova habilidade, há algumas coisas mais complexas que você não quer explicar de imediato, então, ao invés disso, você escolhe incutir uma crença em "culto de carga" em certas coisas apenas para tirá-las do chão. Então, você tem duas opções ao ensinar um iniciante a escrever JavaScript:

1. Diga a eles "sigam esta regra e não perguntem por quê", dizendo a eles para colocarem um ponto e vírgula sempre ao final de cada linha. Infelizmente, isso não ajuda no exemplo acima, ou em qualquer outro exemplo em que a ASI atrapalhe. E o Sr. ou Ms. programador iniciante fica confuso quando o código acima falha.
2. Diga-lhes "siga estas duas regras e não pergunte porquê", dizendo-lhes para não se incomodarem com ponto e vírgula no final de cada linha e para sempre a) Siga return com a { eb) Quando uma linha começa com ( , prefixá-la com ; .

Escolher a opção 2 é um conjunto melhor de regras de "carga cult" a serem seguidas (resultará em muito poucos bugs relacionados ao ASI), e mesmo que você tenha uma compreensão profunda do tópico, você terá menos caracteres desnecessários no tela.

There’s no such thing as information overload, only bad design.

— Edward Tufte

É um regra geral em design gráfico para deixar de fora elementos desnecessários e ornamentação para reduzir o ruído.

Menos elementos visuais na tela significam menos trabalho para nossos cérebros para analisar as informações úteis reais.

let foo = 1

vs.

let /* variable */ foo = 1; // EOL

Um exemplo exagerado, é claro, mas ilustra o princípio geral: Elementos visuais adicionais devem ser adicionados se, e somente se, eles servem a um propósito. Então, o ponto-e-vírgula tem um propósito?

Os motivos históricos para usar ponto e vírgula em JavaScript foram:

• Mantenha a similaridade com C / Java
• Evite problemas de compatibilidade com navegadores e ferramentas mal escritos
• Ajudar os humanos e as máquinas a detectar erros de código
• A inserção automática de ponto e vírgula aplica uma penalidade de desempenho

Os problemas de compatibilidade são praticamente um problema hoje. Linters modernos podem detectar qualquer erro de código tão bem sem ponto e vírgula. Similaridade com C / Java / PHP ainda pode ser uma consideração (veja a resposta aceita por Pat), mas apenas porque outras linguagens contêm elementos de sintaxe supérfluos não significa que devemos mantê-las em JavaScript, especialmente porque muitas outras linguagens (Coffeescript, Python, Ruby, Scala, Lua) não as requerem.

Eu fiz um teste rápido para ver se havia uma penalidade de desempenho no V8. Isso é Io.js analisando um arquivo JavaScript de 41 MB (Lodash repetido 100 vezes) com ponto e vírgula e, em seguida, com ponto e vírgula removido:

$ time node lodashx100.js
node lodashx100.js  2.34s user 1.30s system 99% cpu 3.664 total
$ time node lodashx100s.js
node lodashx100s.js  2.34s user 1.15s system 99% cpu 3.521 total

Todo mundo tem que decidir seu próprio estilo de codificação preferido para seus projetos, mas eu não vejo mais nenhum benefício tangível em usar ponto e vírgula, então, para reduzir o ruído visual, parei.

Escolher uma convenção de programação é efetivamente o mesmo que escolher o subconjunto do idioma de destino. Todos nós fazemos isso pelas razões usuais: legibilidade do código, manutenibilidade, estabilidade, portabilidade, etc. - enquanto potencialmente sacrifica a flexibilidade. Estas razões são razões reais de negócios.

Razões como "salvar pressionamentos de tecla" e "programadores devem aprender as regras JavaScript" são razões comerciais marginais, por isso têm pouco peso prático.

No meu caso, eu precisava acelerar muito em JavaScript, então aproveitar um subconjunto limitado de idiomas foi uma vantagem para mim. Por isso, escolhi o subconjunto JSLint de JavaScript, liguei os aplicativos Rockstar JSLinter no Eclipse para as configurações mais restritivas que pude suportar e não olhei para trás.

Sou grato por poder evitar os detalhes da diferença entre "==" e "===", ou os detalhes da inserção de ponto-e-vírgula, porque eu já tenho uma lista de tarefas com uma milha de altura e esses detalhes não vai ajudar a fazer esses trabalhos um segundo antes.

É claro que a coisa mais importante sobre uma convenção é a consistência, e pensar nela como um subconjunto de idiomas ajuda a reforçar esse imperativo. E, embora isso possa não ajudar a responder à pergunta do OP, acho que pode ajudar no enquadramento prático dele.

Uma pergunta bastante antiga, no entanto, estou surpreso que ninguém tenha mencionado:

Minification: Se você minificar um snippet de JavaScript que não encerre explicitamente as instruções com um caractere de ponto-e-vírgula, poderá acabar tendo dificuldades para descobrir o que está errado com um trecho que estava apenas trabalhando antes da minificação e agora não funciona.

Ambigüidade: O ponto-e-vírgula é opcional, é verdade, mas eliminando-os do código-fonte, você pode deixar alguns cenários ambíguos para o analisador decidir por conta própria. Se você está escrevendo 100 linhas de código para uma loja online, sim, talvez isso não importe, mas tarefas mais sérias exigiriam uma clareza de 100%.

Há muito tempo, eu li uma analogia muito boa sobre outra coisa, mas também é bem verdade neste caso: (No nosso caso) Eliminar o ponto-e-vírgula é como cruzar em um sinal vermelho. Você pode ficar bem no final ou pode ser atropelado por um caminhão.

Por que está se tornando mais popular nos dias de hoje?

Eu pessoalmente acredito que ter o JavaScript executado no lado do servidor teve muitos efeitos na própria comunidade JavaScript. No nosso caso, obviamente, ninguém vai minimizar o JavaScript no lado do servidor (como o código-fonte não deve enviar para o navegador da web do cliente), portanto, não ter ponto-e-vírgula parece muito mais seguro, o que é verdade; no entanto, os outros desenvolvedores que aprendem com esses livros, artigos e vídeos, eles infelizmente descartam o fato de que o JavaScript no lado do servidor não é exatamente o mesmo que o JavaScript no lado do cliente.

Existem boas razões para mantê-los.

Eles não são realmente opcionais, o JS pode adicioná-los de volta com inserção automática de ponto-e-vírgula quando eles estão faltando, mas isso não é a mesma coisa.

O JavaScript de Douglas Crockford: The Good Parts diz em duas ocasiões distintas que é uma má ideia. A inserção automática de ponto-e-vírgula pode ocultar erros no seu programa e cria ambiguidade.

O JSLint não aprova.

O JavaScript não precisou de ponto-e-vírgula para terminar as declarações em mais de uma década. Isso porque os caracteres de nova linha são considerados terminadores de instruções (acredito que isso também seja mencionado nas primeiras especificações do ECMAScript). Realmente faz muito sentido, especialmente porque realmente não há uma boa razão [que eu saiba] por que o JavaScript precisaria de uso freqüente de ponto e vírgula, mas não de outras linguagens declarativas interpretadas como Ruby ou Python.

A exigência de ponto-e-vírgula pode facilitar a gravação de um analisador para um idioma, mas se todo interpretador for compatível com a omissão de ponto e vírgula, qual é exatamente o ponto?

O que parece melhor para você; tomar decisões informadas ou decisões cegas / mentalidade de rebanho?

Eu tenho duas teorias:

A)

No entanto, à medida que avançamos mais em direção ao código dirigido por Teste de unidade e à integração contínua, a quantidade de tempo (e interação humana) necessária para pegar um erro de sintaxe diminuiu maciçamente. O feedback dos testes indicará rapidamente se o seu código está funcionando como esperado, bem antes de chegar perto do usuário final, então por que perder tempo adicionando verbosidade opcional?

B)

Os programadores preguiçosos farão de tudo para facilitar suas vidas a curto prazo. Menos digitação - > menos esforço - > Mais fácil. (Além disso, não ter que usar ponto-e-vírgula evitará forçar o dedo anelar da mão direita, evitando alguma SRI).

(NB não concordo com a idéia de omitir algo que desambigua uma declaração).

Eu não os excluo, mas altero as regras quando inseri-los.

As regras que a maioria das pessoas usa é

• Antes de cada linha terminar
• Exceto que a linha termina com um } proveniente de uma instrução de função
• Mas apenas uma instrução de função, não a atribuição a um literal de função

Minha regra é: no início de cada linha, começando com uma chave de abertura / colchete.

O meu é mais simples, portanto mais fácil de seguir e menos propenso a erros. Além disso, o baixo número de pontos-e-vírgulas facilita a localização de bugs, deixando de fora.

Outro argumento é que o infame erro return\nvalue vem de não saber sobre o ASI. Minha regra obriga você a saber sobre o ASI, então é menos provável que as pessoas que usam minha regra caiam na armadilha desse bug.

Contagem de bytes. Você vê, pessoas maliciosas geralmente tentam se encaixar em uma única linha de código. Tecnicamente falando, isso não seria possível sem ponto e vírgula. Minha suposição é que é mais uma medida de segurança do que apenas um requisito programático. De alguma forma, isso reduziria significativamente o XSS quando se tornasse um requisito, em vez de uma sugestão.