Aggiungerò un aggiornamento a questo perché penso che l'emergere di JS sul web lato client sia stato frainteso su alcuni punti chiave nel corso degli anni.
Non era Ajax
Non sto dicendo che l'Ajax non fosse importante per l'evoluzione della comprensione di JS come lingua, ma la lotta per il dominio del browser sul lato client era finita molto prima che il termine Ajax fosse coniato.
Non è stato perché era l'unico gioco in città
C'erano applet Java, Flash e VBScript. Ho sentito che c'erano anche altre opzioni di scripting negli anni '90 (ma richiedevano plug-in IIRC). Java è estremamente popolare ma le applet sono state un triste fallimento. Erano brutti e spesso formaggio svizzero di sicurezza, ma soprattutto non credo che Java fosse adatto per i motivi che affronterò più avanti. Flash era molto popolare e aveva un forte punto d'appoggio per diversi anni, ma anche quando finalmente Flash aveva opzioni SEO, in genere non venivano utilizzate, rendendo molto difficile scoprire esclusivamente siti Flash. Anche ora, la maggior parte di noi aggiorna regolarmente Flash in modo da poter vedere i film, ma questo è il vero tallone d'Achille. La tecnologia proprietaria nei browser è fastidiosa. E ovviamente VB, che avrebbe funzionato solo con IE, quindi no.
Il posto giusto al momento giusto è rilevante ma non è la risposta completa
Sì, senza l'onda web che cavalca potremmo non aver mai visto JavaScript o una lingua di uso popolare come non appena l'abbiamo fatto. O forse avremmo ...
Finì per essere lo strumento perfetto per il dominio del problema
Direi che intorno al 2000 abbiamo avuto i seguenti problemi:
- IE e Netscape avevano appena accettato di iniziare a giocare bene, seguendo gli stessi standard DOM API e CSS e da allora abbiamo dovuto fare i conti con una serie di problemi di cross-browser JS legacy che hanno appena iniziato a diventare gestibili senza l'aiuto di strumenti di normalizzazione DOM JS come jQuery post IE8
- C'era un'intera nuova generazione di sviluppatori / designer web che non erano necessariamente dei pesi massimi in quanto programmatori che cercavano di migliorare il loro gioco dopo lo scoppio della bolla quando hanno smesso di consegnarti un salario decente per presentarsi alla porta con niente di più dell'alfabetizzazione HTML di base e alcune abilità di Photoshop.
- C'era questo nuovo ragazzo CSS in città che offriva possibilità intriganti per quello che alla fine si sarebbe chiamato DHTML, (più appropriatamente) DOM Scripting (ora in modo inappropriato) HTML5 (zomghtml5!).
Quindi avevamo bisogno di un linguaggio che fosse allo stesso tempo profondo, offrendo la possibilità di strutturare e progettare effettivamente un'app più avanzata con componenti portatili / riutilizzabili sul lato client ma accessibile anche a persone che non conoscevano molto e che avevano solo bisogno di cose per apparire / riapparire quando si fa clic su un pulsante.
Inoltre, essendo MS la bestia sgraziata / incompetente e / o dominante attraverso pratiche anti-intrighi-pratica che a volte sono, non sono riusciti a toccare la loro implementazione API DOM non conforme per un buon decennio, anche se sono riusciti a aggiungi oggetti occasionali come l'oggetto XHR originale e querySelectors in IE8.
La cosa importante da notare è che intorno al 2005 siamo riusciti a seppellire così completamente la complessità della gestione dei problemi tra browser che non era più un problema serio sul fronte JavaScript. L'incapacità di supportare correttamente CSS2 per tutto il tempo in cui ha causato molto più dolore. Per un'idea del volume e della profondità dei problemi, ti consiglio di dare un'occhiata a quirksmode.org . Non penso che questa sia un'impresa che avrebbe potuto essere realizzata in modo uniforme e in altrettante librerie in Java, certamente non in VB e sicuramente non con alcuna strategia di plug-in il cui obiettivo è quello di eludere l'intero problema diventando completamente nuovo tipo di fastidio.
Altre funzionalità linguistiche che hanno molto senso per l'interfaccia utente:
Funzioni di prima classe: nella mia esperienza, nulla si presta meglio all'elaborazione asincrona e ai paradigmi guidati dagli eventi di un linguaggio che rende le sue funzioni di prima classe. Entrambe le preoccupazioni vengono regolarmente affrontate nel lavoro dell'interfaccia utente.
Tipi dinamici: il cast e il controllo del tipo sono un'esigenza molto rara in JavaScript che ha contribuito a mantenere il codice conciso e snello. Le preoccupazioni relative all'interfaccia utente possono diventare complesse e disordinate molto rapidamente. Mantenere il codice rigoroso ed essere assolutamente chiari sul flusso di dati è fondamentale per comprenderlo e modificarlo / mantenerlo.
Non è protezionista: per molti anni qualcuno ha predicato che è necessario proteggersi dai propri errori e dalle cose stupide che l'altro potrebbe fare con il proprio codice rendendo costrutti di codice altamente rigidi e inflessibili e impossibili da immischiarsi con l'intento originale che era creato con e molte persone hanno ascoltato. Non dirò che sono sempre sbagliati (potrei pensarlo) ma dirò che è l'approccio sbagliato all'interfaccia utente Web e credo che sia qualcosa di un fenomeno che abbiamo avviato, mantenuto e modificato client- le GUI secondarie a un ritmo molto più rapido e con maggiore facilità rispetto a tale lavoro sono state in genere realizzate in lingue più restrittive in passato. Essere in grado di cambiare le cose al volo rapidamente e facilmente rende molto più facile avere schemi di architettura dinamica / fluida che non richiedono quantità monumentali di spese indirette e di astrazione che alla fine rende più facile vedere cosa diavolo sta succedendo nel tuo codice e prevenire o gestire le eccezioni in modo molto più pulito. È più facile da mantenere semplicemente attraverso la pura virtù di rendere possibile essere più diretto in tutto ciò che fai e con molto meno codice di quello che ci vorrebbe data l'altra filosofia.
In che modo JS è diventato popolare? Si è dimostrato uno strumento eccellente per il lavoro più volte. Non è la lingua con cui siamo "bloccati" È la lingua che potrebbe aver ispirato una grande evoluzione nelle lingue popolari in generale. E per questo, puoi ringraziare Brendan Eich e tutti i contemporanei che hanno contribuito a mettere l'idea nella sua testa, per aver gradito Scheme come ispirazione progettuale adatta al problema in questione più di quanto gli piacesse Java.