O nascimento e a morte do JavaScript (2014)

• Acompanha a história do JavaScript e da programação de 1995 a 2035 em um formato de ficção científica, comédia e palestra séria
• O escopo se expande além do JavaScript para abranger a história da programação como um todo
• Adota uma perspectiva neutra, sem tomar partido a favor ou contra o JavaScript
• Trata com franqueza os defeitos da linguagem, mas avalia de forma muito positiva seu impacto final na indústria
• A mensagem central é que, apesar de seus defeitos, o JavaScript deixou um grande impacto positivo na indústria da programação

---

Visão geral da palestra

• Acompanha a história do JavaScript e da programação em geral de 1995 a 2035
• A palestra mistura elementos de ficção científica, comédia e uma apresentação totalmente séria
• Não é uma palestra nem a favor nem contra o JavaScript, e não se resume a um único lado
• Os defeitos do JavaScript são tratados com franqueza, mas seu impacto final na indústria é avaliado de forma muito positiva

[GN⁺]

Comentários do Hacker News

• Ele até previu com precisão que haveria um desastre global entre 2020 e 2025, só errou o tipo de desastre(?)
  Bem a cara do JavaScript

  • Dá para dizer que foi uma precisão de quase NaN%

• Surpreende que ninguém ainda tenha mencionado que foi essa pessoa que nos deixou esta obra-prima
  Se você ainda não viu, recomendo parar o que estiver fazendo e assistir. São garantidamente os melhores 5 minutos do seu dia
  https://www.destroyallsoftware.com/talks/wat

  • As palestras dele são todas excelentes
    Boundaries foi o vídeo mais esclarecedor sobre arquitetura de software que já vi, e até hoje lembro das lições dele quando projeto aplicações complexas
    Também é um ótimo material introdutório para ensinar pessoas acostumadas com lógica imperativa espalhada por todo lado a pensar como programadores funcionais
    https://www.destroyallsoftware.com/talks/boundaries
  • Essa apresentação tem alguns erros, e vou citar só dois que eu percebi
    Depois de chamar Array(16), ele diz que há 16 separadores, mas na verdade são só 15, então a piada do Batman perde um pouco a graça
    E depois usa {}+[] e explica como se estivesse somando um objeto com uma lista, zombando do fato de o resultado ser diferente de []+{}, que dá [object Object], mas na prática, se você escrever ({}+[]), também vai obter [object Object]
    Por que {}+[] é diferente fica como quebra-cabeça. Dica: Gurer vf ab bowrpg gurer.

• O JavaScript realmente acabou virando um alvo de compilação; no vídeo da época era asm.js, mas hoje existe WebAssembly
  Vendo isso ser implementado de verdade e rodar perto do desempenho nativo, dá para dizer que a previsão foi bastante certeira
  Eu uso principalmente TypeScript, e graças ao Electron as tecnologias web foram empacotadas como apps de desktop, fazendo a sintaxe web entrar também em programas comuns
  Muita gente diz que Electron é pesado e ruim, mas ele também é a forma mais rápida de oferecer suporte a Mac, Windows e Linux de uma vez
  A “morte” mencionada aqui seria um estado em que não se escreve JavaScript diretamente, mas ele vira uma camada de base presente em todo lugar, e eu diria que foi exatamente isso que aconteceu

  • Também existe Flutter, e ele dá suporte não só a sistemas operacionais de desktop, mas também a iOS e Android
    Eu diria que a velocidade de desenvolvimento também é bem boa
    Só não sei bem como o desempenho se compara ao Electron ou a apps nativos
    Para equipes pequenas, costuma ser muito melhor focar em de fato lançar do que em otimização de velocidade
  • JavaScript é, por assim dizer, a nova camada de assembly
    Por definição, compiladores traduzem código legível por humanos para código de máquina
    A vantagem do JavaScript é que o Google o levou ao limite com o V8 e, depois que o NodeJS criou um ambiente atraente no backend, ele passou a estar em todo lugar como um PDF, e você pode escrever uma vez e usar em qualquer lugar
    O motivo de ele ter levado vantagem sobre WebAssembly até agora também é essa versatilidade; WebAssembly não está disseminado tanto quanto JavaScript
    Hoje em dia JavaScript virou praticamente sinônimo de TypeScript, e isso foi um salto enorme. Na minha opinião, o herói oculto aqui foi o Angular 2
    O Angular escolheu TypeScript desde o início e também ofereceu uma versão em JavaScript nativo, mas, para ser sincero, essa versão era quase inutilizável e foi muito criticada na época
    Curiosamente, o último refúgio que não apresenta TypeScript como opção padrão é o React, mas como grandes projetos como o NextJS já dependem de TypeScript por padrão, o ReactJS também vai acabar cedendo
    Não é a primeira vez que a inovação aparece primeiro em outros projetos e o ReactJS vai atrás; também aqui eu diria que o Angular está à frente
    Se você escolher JavaScript e Python, raramente vai errar feio
  • Se essa “morte” quer dizer que JavaScript virou uma camada de base que não é mais escrita diretamente, então isso parece uma linha do tempo diferente daquela em que eu vivo
    As pessoas ainda escrevem quantidades enormes de JS diretamente, e WebAssembly ainda não dominou o ambiente comum de execução de aplicações web
    Dá para encontrar empresas construindo coisas em cima de WebAssembly, mas isso não deve ser confundido com o tipo de grande virada de que Gary estava falando
  • Na história contada no vídeo, os JITs ficaram bons o bastante para eliminar memória virtual e proteção de memória
    Isso simplesmente não aconteceu
  • Se um site já basta, por que fazer um app?
    Não há necessidade de executar vários navegadores para isso

• A cada poucos anos inventam um JavaScript melhor e depois o transpilam para JavaScript

  • A adoção em larga escala sempre vence o bom design
  • No fim das contas, é tudo código assembly
    Não há nada de inerentemente errado em compilar para JavaScript, e linguagens de alto nível podem implementar muitas garantias que o JavaScript puro não oferece diretamente
    Quase todas as garantias de linguagem que usamos até hoje podem ser quebradas em assembly bruto

• O problema é que a evolução do Wasm não está sendo tão rápida quanto o previsto aqui
  Como não há manipulação de DOM, ainda é preciso usar JS como código de cola, ou então abandonar HTML e CSS por completo e renderizar tudo em canvas, como o Flutter ou algumas GUIs em Rust
  Mas seria uma pena perder o conjunto de funcionalidades da web

  • Quem escolhe Flutter provavelmente considera que a consistência proporcionada pelo canvas em todos os navegadores vale mais do que obter um conjunto de recursos web implementado de forma inconsistente
  • DOM e JS são inseparáveis
    A API do DOM foi projetada assumindo acesso via JS, e o design do JS e algumas de suas características “peculiares” também surgiram em parte do fato de ele ter sido feito para uso junto com o DOM
  • JS é muito mais acessível do que WASM
    Dá para depurar na hora, jogar em um LLM, e como não há wrappers, é muito mais fácil mexer, experimentar e trabalhar com ele

• Em 2014, vi Gary Bernhardt apresentar isso ao vivo na Canadian Undergraduate Software Engineering Conference (CUSEC)
  O PNaCl tinha saído no ano anterior, e o Google o usava dentro do Chrome e do ChromeOS para compilar cruzado, executar e colocar em sandbox clientes OpenSSH e RDP, enquanto o pessoal da Mozilla/Firefox propôs o asm.js como resposta
  Na época, achei só engraçado, mas agora é surpreendente ver quantas partes daquela ideia sobreviveram

• A lightning talk Wat do Gary Bernhardt era uma das minhas apresentações favoritas
  Ela aconteceu apenas 2 anos antes da apresentação citada no título deste post
  [1]: https://www.destroyallsoftware.com/talks/wat

• Quase tudo aconteceu conforme o roteiro
  Agora é só esperar por outro sistema operacional totalmente baseado em tecnologia de navegador, ou por um WASM OS
  webOS e Firefox OS estavam pelo menos 20 anos à frente do seu tempo

  • Nem de longe
    O WASM não confirma essa tese, ele a refuta
    A tese é que código-fonte compatível com JavaScript se tornaria a base do futuro, e que engines de JavaScript altamente otimizadas para interpretar com eficiência subconjuntos compatíveis fariam do JavaScript, apesar de sua base ruim, a futura plataforma de propósito geral
    O WASM rejeita isso de forma fundamental ao criar uma nova base, incompatível com JavaScript, projetada para ser um alvo de baixo nível
    Dizer que o WASM confirma essa tese é tão estranho quanto dizer que um futuro em que todos tenham um interpretador de Rust dentro do navegador confirmaria essa tese
    Se você argumenta isso, no fim está apenas dizendo que navegadores vão executar algum tipo de código, de alguma forma, em qualquer linguagem, e isso eles já fazem
    O vídeo trata claramente de possibilidades “surpreendentes”, então não faz sentido dizer que ele é literalmente compatível com qualquer futuro possível, inclusive os mais banais
  • Existe algum motivo técnico para não mencionar o ChromeOS?
    Pergunto por pura curiosidade
    E as capturas de tela de webOS que vi me fizeram desejar o seu retorno, não só em smart TVs, mas em outros lugares também

• Já passamos da metade do cronograma que Bernhardt projetou para 2035
  O JavaScript ainda não morreu, mas certamente parece estar escrevendo seu próprio elogio fúnebre dentro do WebAssembly

  • É bem provável que o último comando JS ainda esteja rodando depois que várias gerações da sua família já tiverem morrido
    A menos que haja uma guerra nuclear global, eu apostaria que o JS vai sobreviver à maioria dos humanos
  • Todo mês eu reviso sites de vários clientes, e todos usam JavaScript de alguma forma
    Assim como o PHP, ele nunca vai morrer

• JavaScript é a melhor linguagem de programação de todos os tempos