Vou adicionar uma atualização a isso porque acho que o surgimento de JS na Web do lado do cliente foi mal interpretado em alguns pontos-chave ao longo dos anos.
Não era o Ajax
Não estou dizendo que o Ajax não era importante para a evolução do entendimento do JS como uma linguagem, mas a luta pelo domínio do navegador do cliente acabou muito antes do termo Ajax ser cunhado.
Não foi porque era o único jogo na cidade
Havia Java Applets, Flash e VBScript. Ouvi dizer que havia outras opções de script nos anos 90 (mas eram necessários os plug-ins IIRC). Java é muito popular, mas os applets foram uma falha sombria. Eles eram feios e, com frequência, queijo suíço de segurança, mas o mais importante é que não acho que o Java se encaixava bem por razões que abordarei mais adiante. O Flash era muito popular e tinha uma forte presença por vários anos, mas mesmo quando o Flash finalmente tinha opções de SEO, elas não eram normalmente usadas, tornando muito difícil descobrir exclusivamente sites em Flash. Mesmo agora, a maioria de nós atualiza regularmente o Flash para poder ver filmes, mas esse é o verdadeiro calcanhar de Aquiles. A tecnologia proprietária nos navegadores é irritante. E, claro, o VB, que só funcionaria com o IE, então não.
O lugar certo na hora certa é relevante, mas não é a resposta completa
Sim, sem a onda da web, talvez nunca tenhamos visto o JavaScript ou um idioma em uso popular assim como vimos. Ou talvez tivéssemos ...
Acabou sendo a ferramenta perfeita para o domínio do problema
Eu diria que, por volta de 2000, tivemos os seguintes problemas:
- O IE e a Netscape acabaram de concordar em começar a jogar bem, atendendo aos mesmos padrões de API e CSS DOM e tivemos que lidar com uma tonelada de problemas legados em vários navegadores JS desde então, que estão apenas começando a se tornar gerenciáveis sem o auxílio de ferramentas de normalização JS DOM, como jQuery post IE8
- Havia toda uma nova geração de desenvolvedores / designers da web que não eram todos necessariamente pesados como programadores que procuram melhorar seu jogo após a explosão de bolhas .com quando pararam de entregar a você um salário decente por aparecer na porta sem nada mais do que conhecimentos básicos de HTML e algumas habilidades em Photoshop.
- Havia um novo garoto de CSS na cidade que oferecia possibilidades intrigantes para o que seria chamado de DHTML, (mais apropriadamente) DOM Script, (agora inapropriadamente) HTML5 (zomghtml5!).
Então, precisávamos de uma linguagem que fosse profunda, oferecendo a capacidade de realmente estruturar e arquitetar um aplicativo mais avançado com componentes portáteis / reutilizáveis no lado do cliente, mas também acessível a pessoas que não sabiam muito e precisavam apenas de coisas para aparecer / reaparecer quando você clicou em um botão.
Além disso, o MS sendo a fera desagradável / incompetente e / ou dominadora por meio de práticas anti-competitivas que às vezes são, não conseguiu realmente tocar sua implementação de API DOM não compatível por uma boa década, embora eles conseguissem adicione algo ocasional como o objeto XHR original e querySelectors no IE8.
O importante a ser observado é que, por volta de 2005, tínhamos conseguido enterrar tão completamente a complexidade envolvida no tratamento de problemas entre navegadores que não era mais um problema sério na frente do JavaScript. A falha no suporte adequado ao CSS2 pelo tempo que causou causou consideravelmente mais dor. Para ter uma idéia do grande volume e profundidade dos problemas, recomendo consultar o site quirksmode.org . Eu não acho que esse seja um feito que poderia ter sido alcançado com a mesma facilidade e em tantas bibliotecas em Java, certamente não no VB e definitivamente não com nenhuma estratégia de plug-in cujo objetivo seja contornar o problema inteiro, tornando-se um novo. tipo de incômodo.
Outros recursos de idioma que fazem muito sentido para a interface do usuário:
Funções de primeira classe: Na minha experiência, nada se presta melhor ao processamento assíncrono e aos paradigmas orientados a eventos do que uma linguagem que torna suas funções de primeira classe. Ambas as preocupações são abordadas regularmente no trabalho da interface do usuário.
Tipos dinâmicos: a transmissão e a verificação de tipos são uma necessidade muito rara em JavaScript, o que ajudou a manter o código conciso e enxuto. As preocupações da interface do usuário podem se tornar complexas e complicadas muito rapidamente. Manter o código rígido e ser absolutamente claro sobre o fluxo de dados é fundamental para entender e modificar / manter.
Não é protecionista: há muitos anos que alguém está pregando que você precisa se proteger de seus próprios erros e das coisas idiotas que o outro cara pode fazer com seu código, tornando as construções de código altamente rígidas e inflexíveis e impossíveis de interferir com a intenção original. de autoria e muitas pessoas ouviram. Não direi que eles estão sempre errados (pode pensar), mas direi que é a abordagem incorreta da interface do usuário da web e acredito que é um fenômeno que estamos desenvolvendo, mantendo e modificando clientes- GUIs laterais em um ritmo muito mais rápido e com maior facilidade do que esse trabalho normalmente era realizado em idiomas mais restritivos no passado. Ser capaz de mudar as coisas rapidamente e facilmente torna muito mais fácil ter esquemas de arquitetura dinâmica / fluida que não exigem quantidades monumentais de sobrecarga indireta e abstração, o que acaba facilitando a visualização do que está acontecendo no seu código. e antecipar ou manipular exceções com muito mais clareza. É mais fácil manter isso simplesmente com a simples virtude de tornar possível ser mais direto em tudo que você faz e com muito menos código do que seria necessário para a outra filosofia.
Como o JS se tornou popular? Ele provou ser uma excelente ferramenta para o trabalho uma e outra vez. Não é a linguagem com a qual estamos "presos". É a linguagem que pode ter inspirado muita evolução nas línguas populares em geral. E por isso, você pode agradecer a Brendan Eich e a qualquer contemporâneo que ajudou a colocar a idéia em sua mente, por gostar de Scheme como uma inspiração de design adequada para o problema em questão mais do que ele gostava de Java.