JavaScript

Em 1993, o Centro Nacional de Aplicações de Supercomputação (NCSA), uma unidade da Universidade de Illinois em Urbana-Champaign, lançou o NCSA Mosaic, o primeiro navegador gráfico popular da Web, que desempenhou um papel importante na expansão do crescimento da nascente World Wide Web além do nicho NeXTSTEP onde a World Wide Web havia se formado três anos antes. Em 1994, uma empresa chamada Mosaic Communications foi fundada em Mountain View, na Califórnia, e empregou muitos dos autores originais do NCSA Mosaic para criar o Mosaic Netscape. No entanto, não compartilhou intencionalmente nenhum código com o NCSA Mosaic. O codinome interno do navegador da empresa era Mozilla, uma junção de "Mosaic and Godzilla". A primeira versão do navegador da Web, Mosaic Netscape 0.9, foi lançada no final de 1994. Em quatro meses, já havia conquistado três quartos do mercado de navegadores e se tornado o principal navegador da Web nos anos 90. Para evitar problemas de propriedade de marca registrada com o NCSA, o navegador foi posteriormente renomeado para Netscape Navigator no mesmo ano, e a empresa assumiu o nome de Netscape Communications. A Netscape Communications percebeu que a Web precisava se tornar mais dinâmica. Marc Andreessen, o fundador da empresa, acreditava que o HTML precisava de uma "linguagem de cola" que fosse fácil de usar por Web designers e programadores de meio período para montar componentes como imagens e plugins, onde o código poderia ser escrito diretamente na Web.^[9]

Em 1995, a Netscape Communications recrutou Brendan Eich com o objetivo de incorporar a linguagem de programação Scheme em seu Netscape Navigator.^[10] Antes que ele pudesse começar, a Netscape Communications colaborou com a Sun Microsystems para incluir na linguagem de programação mais estática do Netscape Navigator Sun, Java, a fim de competir com a Microsoft pela adoção de tecnologias e plataformas da Web.^[11] A Netscape Communications decidiu então que a linguagem de script que eles queriam criar complementaria o Java e deveria ter uma sintaxe semelhante, o que excluía a adoção de outras linguagens como Perl, Python, TCL ou Scheme. Para defender a ideia do JavaScript contra propostas concorrentes, a empresa precisava de um protótipo. Eich escreveu um em 10 dias, em maio de 1995.

Embora tenha sido desenvolvido sob o nome Mocha, a linguagem foi oficialmente chamada de LiveScript quando foi lançada em versões beta do Netscape Navigator 2.0 em setembro de 1995, mas foi renomeada para JavaScript^[12] quando foi lançada no Netscape Navigator 2.0 beta 3 Dezembro.^[13] A escolha final do nome causou confusão, dando a impressão de que a linguagem era uma derivação da linguagem de programação Java, e a escolha foi caracterizada como uma manobra de marketing da Netscape para dar ao JavaScript o status da linguagem da moda, o Java.

Há um equívoco comum de que o JavaScript foi influenciado por uma linguagem de script de página da Web desenvolvida pelo Nombas chamada Cmm (não confundir com o C posteriormente - criado em 1997).^[14] Brendan Eich, no entanto, nunca tinha ouvido falar de Cmm antes de criar o LiveScript.^[15] Os Nombas lançaram seus scripts de página da Web incorporados no Netscape, embora o script de página da Web não fosse um conceito novo, conforme mostrado pelo navegador da Web ViolaWWW. Nombas mais tarde passou a oferecer JavaScript em vez de Cmm em seu produto ScriptEase e fazia parte do grupo TC39 que padronizava o ECMAScript.^[16]

Em dezembro de 1995, logo depois de lançar o JavaScript para navegadores, a Netscape introduziu uma implementação da linguagem para scripting server-side com o Netscape Enterprise Server.^[17]

Desde 1996, o servidor da Web do IIS tem suportado a implementação do JavaScript - JScript do lado do servidor - em páginas ASP e .NET.^[18]

Desde meados da década de 2000, foram introduzidas implementações adicionais de JavaScript no lado do servidor, como o Node.js em 2009.^[19]

O TypeScript é uma linguagem de programação que adiciona tipagem ao JavaScript, sendo popular para uso no back-end.^[20]

As tecnologias de script da Microsoft, incluindo VBScript e JScript, foram lançadas em 1996. JScript, uma implementação de engenharia reversa do JavaScript da Netscape, fazia parte do Internet Explorer 3. O JScript também estava disponível para scripts do servidor no Internet Information Server. O Internet Explorer 3 também incluiu o primeiro suporte da Microsoft para CSS e várias extensões para HTML, mas em cada caso a implementação era visivelmente diferente daquela encontrada no Netscape Navigator na época.^[21] Essas diferenças tornaram difícil para os designers e programadores fazerem um único site funcionar bem em ambos os navegadores, levando ao uso dos logotipos "melhor visualizado no Netscape" e "melhor visualizado no Internet Explorer" que caracterizaram esses primeiros anos de guerras de navegadores. O JavaScript começou a adquirir a reputação de ser um dos obstáculos a uma Web de plataforma cruzada e baseada em padrões. Alguns desenvolvedores assumiram a difícil tarefa de tentar fazer com que seus sites funcionassem em ambos os principais navegadores, mas muitos não podiam arcar com o tempo.^[21] Com o lançamento do Internet Explorer 4, a Microsoft introduziu o conceito de HTML Dinâmico, mas as diferenças nas implementações de linguagem e nos diferentes e proprietários Modelos de Objeto de Documento permaneceram e foram obstáculos à adoção generalizada de JavaScript na Web.

Em novembro de 1996, a Netscape submeteu o JavaScript à ECMA International para criar uma especificação padrão, que outros fornecedores de navegador poderiam implementar com base no trabalho feito na Netscape. Isso levou ao lançamento oficial da especificação de linguagem ECMAScript publicada na primeira edição da norma ECMA-262 em junho de 1997, sendo o JavaScript a mais conhecida das implementações. ActionScript e JScript eram outras implementações bem conhecidas do ECMAScript.

O lançamento do ECMAScript 2 em junho de 1998 deu continuidade ao ciclo de processo de padrões, conforme algumas modificações do padrão internacional ISO / IEC 16262. ECMAScript 3 foi lançado em dezembro de 1999 e é a linha de base moderna para JavaScript. O trabalho original do ECMAScript 4 liderado por Waldemar Horwat (então na Netscape, agora no Google) começou em 2000. A Microsoft inicialmente participou e implementou algumas propostas em sua linguagem JScript .NET.

Com o tempo, ficou claro que a Microsoft não tinha intenção de cooperar ou implementar o JavaScript adequado no Internet Explorer, mesmo que eles não tivessem uma proposta concorrente e tivessem uma implementação parcial (e divergente neste ponto) no lado do servidor .NET. Então, em 2003, o trabalho original do ECMAScript 4 foi desativado.

O próximo grande evento foi em 2005, com dois grandes acontecimentos na história do JavaScript. Primeiro, Brendan Eich e Mozilla juntaram-se novamente à Ecma International como um membro sem fins lucrativos e começaram a trabalhar no ECMAScript para XML (E4X), o padrão ECMA-357, que veio de ex-funcionários da Microsoft na BEA Systems (originalmente adquirida como Crossgain) . Isso levou a trabalhar em conjunto com a Macromedia (posteriormente adquirida pela Adobe Systems), que estava implementando o E4X no ActionScript 3 (o ActionScript 3 era um fork do ECMAScript 4 original).

Assim, juntamente com a Macromedia, o trabalho foi reiniciado no ECMAScript 4 com o objetivo de padronizar o que estava no ActionScript 3. Para isso, a Adobe Systems lançou a ActionScript Virtual Machine 2, codinome Tamarin, como um projeto de código aberto. Mas Tamarin e ActionScript 3 eram muito diferentes do JavaScript da web para convergir, como foi realizado pelas partes em 2007 e 2008.

Ainda havia turbulência entre os vários jogadores; Douglas Crockford — então no Yahoo! — juntou forças com a Microsoft em 2007 para se opor ao ECMAScript 4, o que levou ao esforço do ECMAScript 3.1. O desenvolvimento do ECMAScript 4 nunca foi concluído, mas esse trabalho influenciou versões subsequentes.

Enquanto tudo isso acontecia, as comunidades de código aberto e de desenvolvedores começaram a trabalhar para revolucionar o que poderia ser feito com JavaScript. Esse esforço da comunidade surgiu em 2005, quando Jesse James Garrett lançou um white paper no qual cunhou o termo Ajax e descreveu um conjunto de tecnologias, das quais o JavaScript era o backbone, usado para criar aplicativos da Web onde os dados podem ser carregados em segundo plano, evitando a necessidade de recargas de páginas completas e levando a aplicativos mais dinâmicos. Isso resultou em um período de renascimento do uso do JavaScript liderado pelas bibliotecas de código aberto e pelas comunidades que se formaram em torno delas, com bibliotecas como Prototype, jQuery, Dojo Toolkit, MooTools e outras.

Em julho de 2008, os diferentes partidos de ambos os lados se reuniram em Oslo. Isso levou ao eventual acordo no início de 2009 para renomear o ECMAScript 3.1 para o ECMAScript 5 e impulsionar o idioma usando uma agenda que é conhecida como Harmonia. O ECMAScript 5 foi finalmente lançado em dezembro de 2009.

Em junho de 2011, o ECMAScript 5.1 foi lançado para se alinhar totalmente com a terceira edição do padrão internacional ISO / IEC 16262. O ECMAScript 2015 foi lançado em junho de 2015. O ECMAScript 2016 foi lançado em junho de 2016. A versão atual é o ECMAScript 2017, lançado em junho de 2017.

JavaScript tornou-se uma das linguagens de programação mais populares da web. No entanto, muitos programadores profissionais inicialmente desacreditaram a linguagem devido ao público-alvo percebido de autores da Web e outros "amadores".^[22] O advento do Ajax devolveu o JavaScript aos holofotes e atraiu mais atenção da programação profissional. O resultado foi a proliferação de estruturas e bibliotecas abrangentes, práticas de programação JavaScript aprimoradas e aumento do uso de JavaScript fora dos navegadores da Web, conforme observado pela proliferação de plataformas JavaScript do lado do servidor.

Em janeiro de 2009, o projeto CommonJS foi fundado com o objetivo de especificar uma biblioteca padrão comum principalmente para o desenvolvimento de JavaScript fora do navegador.^[23]

Com o surgimento de aplicativos de página única e sites pesados em JavaScript, ele está sendo cada vez mais usado como um alvo de compilação para compiladores de origem para origem de linguagens dinâmicas e estáticas.

"JavaScript" é uma marca comercial da Oracle Corporation nos Estados Unidos.^[24] Ele é usado sob licença para tecnologia inventada e implementada pela Netscape Communications e entidades atuais, como a Fundação Mozilla.^[25]

As seguintes características são comuns a todas as implementações em conformidade com o ECMAScript, a menos que esteja explicitamente especificado ao contrário.

Todos os navegadores da Web modernos e populares suportam JavaScript com interpretadores integrados.

JavaScript suporta os elementos de sintaxe de programação estruturada da linguagem C como, por exemplo, if, while, switch. Uma exceção é a questão do escopo: o escopo em blocos ao estilo do C não é suportado. Em seu lugar, JavaScript utiliza escopo a nível de função. JavaScript 1.7, entretanto, suporta escopo a nível de bloco através do comando let. Como C, JavaScript faz distinção entre expressões e comandos. Uma diferença sintática do C é que a quebra de linha termina automaticamente o comando, sendo o ponto-e-vírgula opcional ao fim de uma instrução.

Como na maioria das linguagens de script, tipos são associados com valores, não com variáveis. Por exemplo, a variável x poderia ser associada a um número e mais tarde associada a uma ''string''. JavaScript suporta várias formas de testar o tipo de um objeto, incluindo duck typing.

JavaScript é quase inteiramente baseada em objetos^{[carece de fontes?]}. Objetos JavaScript são arrays associativos, aumentados com protótipos. Os nomes da propriedade de um objeto são strings: obj.x = 10 e obj["x"] = 10 são equivalentes, o ponto neste exemplo é apenas sintático. Propriedades e seus valores podem ser adicionadas, mudadas, ou deletadas em tempo de execução. A maioria das propriedades de um objeto (e aqueles em sua cadeia de herança via protótipo) pode ser enumerada usando-se uma estrutura de repetição for...in. JavaScript possui um pequeno número de objetos padrão da linguagem como window e document.

JavaScript inclui a função eval que consegue executar em tempo de execução comandos da linguagem que estejam escritos em uma string.

No JavaScript, as funções são de primeira classe, isto é, são objetos que possuem propriedades e métodos, e podem ser passados como argumentos, serem atribuídos a variáveis ou retornados como qualquer outro objeto.

Funções 'internas' ou 'aninhadas' são funções definidas dentro de outras funções. São criadas cada vez que a função que as contém (externa) é invocada. Além disso, o escopo da função externa, incluindo constantes, variáveis locais e valores de argumento, se transforma parte do estado interno de cada objeto criado a partir da função interna, mesmo depois que a execução da função interna é concluída.

JavaScript permite que funções aninhadas sejam criadas com o escopo léxico no momento de sua definição e possui o operador () para invocá-las em outro momento. Essa combinação de código que pode ser executado fora do escopo no qual foi definido, com seu próprio escopo durante a execução, é denominada, dentro da ciência da computação, fechamento.

JavaScript usa protótipos em vez de classes para o mecanismo de herança. É possível simular muitas características de orientação a objetos baseada em classes com protótipos.

function calcIdade(b) {
  var hoje = new Date();
  var a = hoje.getFullYear();
  var idade = a - b;

  return idade;
}

Diferente de muitas linguagens orientadas a objetos, não há distinção entre a definição de uma função e a definição de um método no JavaScript. A distinção ocorre durante a chamada da função; a função pode ser chamada como um método. Quando uma função é chamada como método de um objeto, a keyword this da função é associada àquele objeto via tal invocação.

JavaScript é oficialmente gerenciado pela Mozilla Foundation, e novos recursos de idioma são adicionados periodicamente. No entanto, apenas alguns mecanismos JavaScript suportam esses novos recursos:

• Funções de propriedade getter e setter (suportadas pelo WebKit, Gecko, Opera,^[26] ActionScript e Rhino).^[27]
• Cláusulas de captura condicional.
• Protocolo iterador (adotado do Python).
• Compreensões de array e gerador de expressões (adotado do Python)
• Escopo de bloco adequado através da palavra-chave let
• Desestruturação de matriz e objeto (forma limitada de pattern matching)
• Expressões de função concisas (function(args) expr)
• ECMAScript para XML (E4X), uma extensão que adiciona suporte XML nativo ao ECMAScript (não suportado no Firefox desde a versão 21^[28])

O uso primário de JavaScript é escrever funções que são embarcadas ou incluídas em páginas HTML e que interagem com o Modelo de Objeto de Documentos (DOM) da página. Alguns exemplos deste uso são:

• abrir uma nova janela (dialog) com controle programático sobre seu tamanho, posição e atributos;
• validar valores de um formulário para garantir que são aceitáveis antes de serem enviados ao servidor;
• mudar imagens à medida que o mouse se movimenta sobre elas.

Um recurso de interface útil baseada em janela, é um tipo de janela secundária da tela principal, ou janela principal, para solicitar ou exibir ao usuário determinadas informações complementares, semelhante a “caixa de diálogo” (dialog).

Existem dois tipos de associação entre uma janela de diálogo e a janela principal à qual está associada: "forma modal" (showModalDialog), quando a abertura da janela de diálogo flexível sobreposta a janela principal sem a necessidade de recarregar a página principal após o uso do modal, chamada de Lightbox, bloqueando a interação com a janela principal e esmaecendo/escurecendo o fundo até que o dialog seja encerrado; ou "forma não modal", em que pode haver interação concomitante nas duas janelas (principal e diálogo) sem bloqueio da principal, O caso mais comum é do dialog modal.^[29][30]

Pelo fato do código JavaScript rodar localmente no navegador do usuário, e não em um servidor remoto, o navegador pode responder a tais ações rapidamente, fazendo uma aplicação mais responsiva. Além disso, o código JavaScript pode detectar ações de usuário que o HTML sozinho não pode, tais como teclas pressionadas individualmente. Aplicações como Gmail tomam vantagem disso: muito da lógica da interface do usuário é escrita em JavaScript, e o JavaScript envia requisições de informação, tais como o conteúdo de um correio eletrônico, para o servidor. A tendência mais ampla de programação em Ajax explora de maneira similar este ponto forte. Uma JavaScript engine (também conhecida como interpretador JavaScript ou uma implementação JavaScript) interpreta código fonte JavaScript e o executa de forma adequada. A primeira implementação JavaScript foi criada por Brendan Eich na Netscape Communications Corporation, para o Navegador Netscape. A implementação, nomeada SpiderMonkey, é implementada em C e vem sendo atualizada para conformar com a edição 3 do ECMA-262. A implementação Rhino, criada primariamente por Norris Boyd (ex-empregado da Netscape; agora no Google) é uma implementação de JavaScript em Java. Rhino, como SpiderMonkey, é conformante com a terceira edição do ECMA-262.

Por ser o JavaScript a única linguagem que a maioria dos navegadores populares suportam, tem se tornado uma linguagem alvo para muitos frameworks em outras linguagens, a despeito do fato de não ter sido planejado para tal. Não obstante as limitações de desempenho inerente à sua natureza dinâmica, a crescente velocidade das implementações JavaScript tem feito da mesma uma prática linguagem intermediária.

Um exemplo minimalista de uma página conforme os padrões web (utilizando a sintaxe HTML5) que contém JavaScript pode ser representado pelo seguinte código:

<!DOCTYPE html>
<html lang="pt-BR">
    <head>
        <meta charset="UTF-8" />
        <title>Wikipédia</title>
        <script>
            window.onload = function() {
                document.getElementById("hello").addEventListener("click", function() {
                    alert("Bem-vindo à Wikipédia!");
                }, false);
            };
        </script>
    </head>
    <body>
        <noscript>Seu navegador não suporta JavaScript ou ele está desabilitado.</noscript>
        <button id="hello">Dizer "Olá"</button>
    </body>
</html>

No script acima, vimos que existe uma tag chamada <noscript>, ela está neste código HTML porque é um meio de acessibilidade com o cliente, fazendo com que seu texto seja renderizado pelo navegador quando o JavaScript estiver desativado.

Já que JavaScript roda em ambientes variáveis, uma parte importante do teste e depuração de seu código consiste na verificação de compatibilidade entre navegadores.

As interfaces DOM para a manipulação de páginas web não são parte do padrão ECMA, ou do próprio JavaScript. Oficialmente, são definidas por um esforço de padronização da W3C; na prática, implementações de navegadores diferem do padrão de uma para as outras, e nem todos navegadores executam JavaScript.

Para lidar com essas diferenças, programadores JavaScript com frequência tentam escrever códigos que conformam com o padrão comum a maioria dos navegadores; não sendo possível isso, tentam escrever de maneira ad-hoc um código que verifique a presença de certos recursos e que se comporte de maneira adequada caso tais recursos não estejam disponíveis. Em alguns casos, dois navegadores podem ambos implementarem uma funcionalidade com comportamentos diferentes, e programadores podem achar prático detectar qual navegador está rodando e mudar o comportamento de seus scripts para se adequar a isso. Programadores podem também usar bibliotecas ou ferramentas que abstraem tais diferenças entre navegadores.

Além disso, scripts podem não funcionar para alguns usuários. Por exemplo, um usuário pode:

• Usar um navegador antigo ou raro com suporte DOM incompleto ou incomum.
• Usar um navegador de um PDA ou telefone móvel que não está apto a executar JavaScript.
• Ter a execução do JavaScript desabilitada por normas de segurança.

Para suportar tais usuários, programadores web tentam criar páginas que sejam robustas a agentes que não suportem o JavaScript da página. Em particular, uma página deve funcionar a despeito das funcionalidades extras que um JavaScript provê. Uma abordagem alternativa que muitos acham preferível é a página se desenvolvida por primeiro a partir de tecnologias básicas que funcionem em todos os navegadores, e então aprimorá-la para os usuários que possuam JavaScript.

Assumindo que o usuário não tenha desabilitado sua execução, pode-se utilizar JavaScript do lado cliente para melhorar a experiência de um usuário com deficiência física ou visual.

Leitores de tela utilizados por pessoas cegas ou com visão parcial podem detectar a presença de JavaScript e dessa forma acessar e ler o DOM da página depois que seus scripts foram executados. Nestes casos recomenda-se que o HTML seja o mais conciso, navegável e rico semanticamente possível, tendo a página scripts ou não. Não se recomenda que o código JavaScript de uma página seja totalmente dependente dos eventos provenientes do mouse já que usuários que não conseguem ou optam por não usar o mouse não estarão aptos a colher os benefícios de tal código. Da mesma forma, embora hyperlinks e webforms possam ser navegados e operados do teclado, JavaScript voltado para acessibilidade não deve requerer um teclado para acessar tais eventos. JavaScript conta com eventos independentes do dispositivo de usuário tais como onfocus e onchange que são mais recomendados na maioria dos casos.

Não se recomenda utilizar JavaScript de um jeito que seja confuso ou desorientador para qualquer usuário da internet. Por exemplo, usar JavaScript para alterar ou desabilitar a funcionalidade normal de um navegador, tal como mudar a forma com que o botão direito ou o evento de atualização funcionam, deve ser evitado. Da mesma forma, eventos de interrupção que o usuário pode não estar ciente reduzem a sensação de controle do usuário, assim como scripts inesperados que mudam o conteúdo da página.

Frequentemente o processo de fazer páginas web complexas tão acessíveis quanto possível se transforma em um problema não trivial, onde certas decisões são assunto de debate e opinião. Entretanto, tecnologias assistivas estão constantemente evoluindo e novas recomendações e informações relevantes vem sendo continuamente publicadas na web.

JavaScript e o DOM representam uma potencialidade para programadores maliciosos escreverem scripts para rodarem em um cliente via web. Navegadores são projetados para conter este risco de duas maneiras. A primeira é que scripts são rodados em uma sandbox na qual só podem executar ações relacionadas à internet, não tarefas de programação de propósito geral como criar arquivos. A segunda é que scripts são limitados pela regra da mesma origem: scripts de um website não têm acesso a informações como nomes de usuário, senhas ou cookies enviados de outro site. A maioria dos bugs em JavaScript relacionados à segurança são brechas de uma das regras.

Um problema comum relacionado à segurança é a escrita de scripts inter-site, ou XSS, uma violação da regra da mesma origem. Tais vulnerabilidades ocorrem quando um atacante está apto a causar em um site alvo, como um site de banco, a inclusão de um script malicioso na página web apresentada à vítima. O script neste exemplo pode então acessar a aplicação do banco com privilégios da vítima, potencialmente revelando informações secretas ou transferindo dinheiro sem a autorização da vítima.

Alguns navegadores incluem proteção parcial contra ataques XSS refletidos, no qual o atacante fornece uma URL incluindo o script malicioso. No entanto, mesmo usuários destes sites estão vulneráveis a outros ataques XSS, como aqueles onde o código malicioso é guardado em um banco de dados. Apenas o correto desenho de aplicações web no servidor pode prevenir inteiramente ataques XSS.

Vulnerabilidades XSS também podem ocorrer por causa de erros de implementação por parte de programadores de navegadores.

Outra vulnerabilidade inter-site é a falsificação de requisição inter-site ou CSRF. No CSRF, o código no site de um atacante faz com que o navegador da vítima tome ações não desejadas pelo usuário em um site alvo (como transferência de dinheiro em um banco). Ela funciona porque, se o site alvo conta apenas com cookies para autenticar requisições, então requisições iniciadas pelo código no site do atacante levarão as mesmas credenciais legítimas de login que as requisições iniciadas pelo usuário. Em geral a solução para CSRF é requerer um valor de autenticação em um campo webform escondido, e não somente nos cookies, para autenticar qualquer requisição que possa ter efeitos duradouros. Verificar o cabeçalho do HTTP Referrer também pode ajudar.

"Sequestro JavaScript" é um tipo de ataque CSRF no qual uma tag <script> no site do atacante explora uma página no lado da vítima que retorna informação privada tal como JSON ou JavaScript. Soluções possíveis incluem requerer um token de autenticação nos parâmetros POST e GET para qualquer resposta que retorne um JSON privado (mesmo que não tenha efeitos colaterais); utilizar POST e nunca GET para requisições que retornem um JSON privado; e modificar a resposta de forma que não possa ser usada via uma tag <script> (através, por exemplo, de um wrapping de um JSON em um comentário JavaScript).

Desenvolvedores de aplicativos cliente-servidor devem reconhecer que clientes não confiáveis ​​podem estar sob o controle de invasores. O autor do aplicativo não pode presumir que seu código JavaScript será executado como pretendido (ou de todo) porque qualquer segredo incorporado no código pode ser extraído por um determinado adversário. Algumas implicações são:

• Os desenvolvedores de sites não podem ocultar perfeitamente como o JavaScript do site funciona porque o código-fonte bruto deve ser enviado ao cliente. O código pode ser ofuscado, mas a ofuscação pode ser projetada por engenharia reversa.
• A validação de formulário JavaScript fornece apenas conveniência para usuários, não segurança. Se um site verificar que o usuário concordou com seus termos de serviço ou filtra caracteres inválidos em campos que devem conter apenas números, ele deve fazê-lo no servidor, não apenas no cliente.
• Os scripts podem ser desativados seletivamente, portanto, não se pode confiar em JavaScript para impedir operações, como clicar com o botão direito do mouse em uma imagem para salvá-la.
• É uma prática extremamente ruim incorporar informações confidenciais, como senhas, em JavaScript, porque elas podem ser extraídas por um invasor.

Sistemas de gerenciamento de pacotes, como npm e Bower, são populares entre os desenvolvedores de JavaScript. Tais sistemas permitem que um desenvolvedor gerencie facilmente as dependências de seus programas sobre as bibliotecas de programas de outros desenvolvedores. Os desenvolvedores confiam que os mantenedores das bibliotecas os manterão seguros e atualizados, mas nem sempre é esse o caso. Uma vulnerabilidade surgiu por causa dessa confiança cega. Bibliotecas confiáveis ​​podem ter novas versões que causam bugs ou vulnerabilidades em todos os programas que dependem das bibliotecas. Inversamente, uma biblioteca pode ficar sem correção com vulnerabilidades conhecidas na natureza. Em um estudo feito olhando uma amostra de 133 sites, os pesquisadores descobriram que 37% dos sites incluíam uma biblioteca com pelo menos uma vulnerabilidade conhecida. O atraso mediano entre a versão da biblioteca mais antiga usada em cada site e a mais nova versão disponível dessa biblioteca é de 1.177 dias na ALEXA, e o desenvolvimento de algumas bibliotecas ainda em uso ativo cessou anos atrás. Outra possibilidade é que o mantenedor de uma biblioteca pode remover a biblioteca completamente. Isso ocorreu em março de 2016, quando o Azer Koçulu removeu seu repositório do npm. Isso fez com que todas as dezenas de milhares de programas e sites, dependendo de suas bibliotecas, quebrassem.

O JavaScript fornece uma interface para uma ampla gama de recursos do navegador, alguns dos quais podem ter falhas, como estouro de buffer. Essas falhas podem permitir que invasores escrevam scripts que executariam qualquer código que desejassem no sistema do usuário. Este código não é de forma alguma limitado a outro aplicativo JavaScript. Por exemplo, uma exploração de buffer overrun pode permitir que um invasor obtenha acesso à API do sistema operacional com privilégios de superusuário.

Essas falhas afetaram os principais navegadores, incluindo Firefox,^[31] Internet Explorer^[32] e Safari.^[33]

Plugins, como players de vídeo, Adobe Flash e a ampla gama de controles ActiveX habilitados por padrão no Microsoft Internet Explorer, também podem ter falhas exploráveis ​​via JavaScript (tais falhas foram exploradas no passado).^[34][35]

No Windows Vista, a Microsoft tentou conter os riscos de erros, como estouro de buffer, executando o processo do Internet Explorer com privilégios limitados.^[36] O Google Chrome confina seus renderizadores de página à sua própria "sandbox".

Os navegadores da Web são capazes de executar o JavaScript fora do sandbox, com os privilégios necessários para, por exemplo, criar ou excluir arquivos. Naturalmente, esses privilégios não devem ser concedidos ao código da Web.

A concessão incorreta de privilégios ao JavaScript da Web desempenhou um papel importante nas vulnerabilidades do Internet Explorer^[37] e do Firefox.^[38] No Windows XP Service Pack 2, a Microsoft rebaixou os privilégios do JScript no Internet Explorer.^[39]

O Microsoft Windows permite que os arquivos de origem JavaScript no disco rígido de um computador sejam lançados como programas de uso geral e sem área de segurança. Isso torna o JavaScript (como o VBScript) um vetor teoricamente viável para um cavalo de Tróia, embora cavalos de Tróia em JavaScript sejam incomuns na prática.^[40]

Em 2015, uma implementação de prova de conceito baseada em JavaScript de um ataque de desajustes foi descrita em um artigo por pesquisadores de segurança.^[41][42][43]

Em 2017, foi demonstrado um ataque baseado em JavaScript via navegador que poderia ignorar o ASLR. É chamado de "ASLR⊕Cache" ou AnC.^[44][45]

// Mostra um alerta de Confirmar e Cancelar.
if ( confirm( 'Escolha "Ok" ou "Cancelar" para ver a mensagem correspondente.' ) ) {
 alert( 'Você apertou o botão "OK"' ); // mostra um alerta para resposta "OK"
} else {
 alert( 'Você apertou o botão "Cancelar"' ); // mostra um alerta para resposta "Cancelar"
}

JavaScript permite utilizar comentários de duas formas:

• Comentários de única linha;
• Comentários de múltiplas linhas.

Exemplos de comentários:

// Este comentário ocupa uma única linha

/* Já este comentário
é mais longo e utiliza
várias linhas */

Criando uma função simples:

function nomeDaFuncao( /*parâmetros*/ ) {
 /* código que será executado */

 return/*Valor retornado*/;
}

//Construtor
//Construtor
function Exemplo() {
    this.propriedade = 'Isso é uma propriedade.',
        this.metodo = function() {
            return 'Isso é um método';
        }
}

var objeto = new Exemplo(); //Instância do construtor "Exemplo"

//Alerta os respectivos textos na tela
alert(objeto.propriedade),
    alert(objeto.metodo());

function perfectNumbers(max) {
    var i, j, k,
        perfects = [];

    for (i = 0; i++ < max;) {
        for (j = k = 0; ++j < i;) {
            if (i % j === 0) {
                k += j;
            }
        }

        if (k === i) {
            perfects.push(k);
        }
    }

    return perfects.join(', ');
}

alert('Números perfeitos de 1 a 5000:' + perfectNumbers(5000));

Dentro do JavaScript, o acesso a um depurador se torna inestimável ao desenvolver programas grandes e não triviais. Pode haver diferenças de implementação entre os vários navegadores (especialmente dentro do DOM), portanto, é útil ter acesso a um depurador para cada um dos navegadores que um aplicativo Web tem como destino.^[46]

Os depuradores de scripts são integrados em muitos navegadores comuns, como o Internet Explorer, o Firefox, o Safari, o Google Chrome e o Opera.

Além das Ferramentas nativas para desenvolvedores do Internet Explorer, três outros depuradores estão disponíveis para o Internet Explorer: O Microsoft Visual Studio possui o maior número de recursos dos três, seguido de perto pelo Microsoft Script Editor (um componente do Microsoft Office), e finalmente depurador de scripts da Microsoft gratuito. O Microsoft Visual Web Developer Express gratuito fornece uma versão limitada da funcionalidade de depuração do JavaScript no Microsoft Visual Studio.

Em comparação com o Internet Explorer, o Firefox tem um conjunto mais abrangente de ferramentas para desenvolvedores, que inclui também um depurador. Versões antigas do Firefox sem essas ferramentas usavam um addon do Firefox chamado Firebug, ou o antigo depurador do Venkman. O Web Inspector WebKit inclui um depurador JavaScript,^[47] que é usado no Safari. Uma versão modificada chamada Blink DevTools é usada no Google Chrome. O Node.js possui o Node Inspector, um depurador interativo que se integra ao Blink DevTools. O Opera inclui um conjunto de ferramentas chamado Dragonfly.

Além do software de computador nativo, há o ambiente de desenvolvimento integrado (IDEs) JavaScript on-line, que possui recursos de depuração que são gravados em JavaScript e criados para serem executados na Web. Um exemplo é o programa JSLint, desenvolvido por Douglas Crockford, que escreveu extensivamente sobre o idioma. O JSLint verifica o código JavaScript para conformidade com um conjunto de padrões e diretrizes. Muitas bibliotecas para JavaScript, como o three.js, fornecem links para o código de demonstração que pode ser editado pelos usuários. Os códigos de demonstração também são usados ​​como uma ferramenta pedagógica por instituições como a Khan Academy para permitir que os alunos experimentem escrever código em um ambiente onde possam ver a saída de seus programas, sem precisar de configuração além do navegador da web.

JavaScript foi inicialmente desenvolvido em 1996 para uso no navegador da Web Netscape Navigator. No mesmo ano, a Microsoft lançou uma implementação para o Internet Explorer. Essa implementação foi chamada de JScript devido a problemas de marca registrada. Em 1997, a primeira versão padronizada da linguagem foi lançada sob o nome ECMAScript na primeira edição da norma ECMA-262.

A versão explícita e o opt-in dos recursos de linguagem eram específicos do Mozilla e foram removidos em versões posteriores do Firefox (pelo menos no Firefox 59). O Firefox 4 foi a última versão que se referiu a uma versão explícita de JavaScript (1.8.5). Com as novas edições do padrão ECMA-262, os recursos de linguagem JavaScript são agora mencionados com sua definição inicial nas edições do ECMA-262.

A tabela a seguir de versões JavaScript com versão explícita é baseada em informações de várias fontes confiáveis.^[48][49][50]

• ECMAScript
• JScript
• NoScript
• TypeScript