Je vais ajouter une mise à jour car je pense que l'émergence de JS sur le Web côté client a été mal comprise sur quelques points clés au fil des ans.
Ce n'était pas Ajax
Je ne dis pas que Ajax n'était pas important pour l'évolution de la compréhension de JS en tant que langage, mais la lutte pour la domination du navigateur côté client était terminée bien avant que le terme Ajax ne soit inventé.
Ce n'était pas parce que c'était le seul jeu en ville
Il y avait des applets Java, Flash et VBScript. J'ai entendu dire qu'il y avait même d'autres options de script dans les années 90 (mais des plug-ins IIRC requis). Java est extrêmement populaire, mais les applets ont été un échec lamentable. Ils étaient laids et souvent des fromages de sécurité suisses, mais plus important encore, je ne pense pas que Java était un bon choix pour des raisons que j'irai plus tard. Flash était très populaire et avait une forte emprise pendant un certain nombre d'années, mais même lorsque Flash avait finalement des options de référencement, elles n'étaient généralement pas utilisées, ce qui rend les sites exclusivement Flash très difficiles à découvrir. Même maintenant, la plupart d'entre nous mettons régulièrement à jour Flash pour que nous puissions voir des films, mais c'est le vrai talon d'Achille. La technologie propriétaire des navigateurs est agaçante. Et bien sûr VB, qui ne fonctionnerait qu'avec IE, donc non.
Le bon endroit au bon moment est pertinent mais pas la réponse complète
Oui, sans la vague Web pour naviguer, nous n'aurions peut-être jamais vu JavaScript ou un langage populaire comme celui-ci dès que nous l'avons vu. Ou peut-être que nous aurions ...
Il s'est avéré être l'outil parfait pour le domaine problématique
Je dirais que vers 2000, nous avons eu les problèmes suivants:
- IE et Netscape venaient tout juste d'accepter de commencer à jouer en se conformant aux mêmes normes DOM API et CSS et nous avons dû faire face à une tonne de problèmes hérités de cross-browser JS depuis, qui commencent à peine à devenir gérables sans l'aide des outils de normalisation JS DOM comme jQuery post IE8
- Il y avait une toute nouvelle génération de développeurs / concepteurs Web qui n'étaient pas nécessairement tous des poids lourds en tant que programmeurs cherchant à améliorer leur jeu après l'éclatement de la bulle après avoir cessé de vous donner un salaire décent pour se présenter à la porte sans rien de plus. que l'alphabétisation HTML de base et certaines compétences Photoshop.
- Il y avait ce nouveau gamin CSS en ville qui offrait des possibilités intrigantes pour ce qui serait finalement appelé DHTML, (plus adéquatement) DOM Scripting, (maintenant de manière inappropriée) HTML5 (zomghtml5!).
Nous avions donc besoin d'un langage à la fois profond, offrant la possibilité de structurer et d'architecturer une application plus avancée avec des composants portables / réutilisables côté client, mais également accessible aux personnes qui ne connaissaient pas grand-chose et qui avaient juste besoin de choses. pour apparaître / réapparaître lorsque vous avez cliqué sur un bouton.
De plus, MS étant la bête maladroite / incompétente et / ou dominante par le biais de pratiques anti-concurrentielles qu'ils schématisent parfois, n'a pas vraiment touché à leur implémentation DOM DOM non conforme pendant une bonne décennie, bien qu'ils aient réussi à ajoutez la chose occasionnelle comme l'objet XHR d'origine et querySelectors dans IE8.
La chose importante à noter est que vers 2005, nous avions réussi à enterrer si complètement la complexité impliquée dans la gestion des problèmes inter-navigateurs que ce n'était plus vraiment un problème sérieux sur le front de JavaScript. L'incapacité à prendre correctement en charge CSS2 aussi longtemps que cela a causé beaucoup plus de douleur. Pour avoir une idée du volume et de la profondeur des problèmes, je recommande de consulter quirksmode.org . Je ne pense pas que ce soit un exploit qui aurait pu être réalisé aussi facilement et dans autant de bibliothèques en Java, certainement pas en VB et certainement pas avec une stratégie de plug-in dont le but est de contourner tout le problème en devenant un tout nouveau sorte de nuisance.
Autres fonctionnalités linguistiques qui font beaucoup de sens pour l'interface utilisateur:
Fonctions de première classe: D'après mon expérience, rien ne se prête mieux au traitement asynchrone et aux paradigmes événementiels qu'un langage qui rend ses fonctions de première classe. Ces deux préoccupations sont régulièrement abordées dans les travaux sur l'assurance-chômage.
Types dynamiques: la conversion et la vérification de type sont un besoin très rare en JavaScript, ce qui a aidé à garder le code concis et léger. Les problèmes d'interface utilisateur peuvent devenir complexes et désordonnés très rapidement. Garder le code serré et être absolument clair sur le flux de données est essentiel pour le comprendre et le modifier / le maintenir.
Ce n'est pas protectionniste: pendant de nombreuses années, quelqu'un a prêché que vous devez vous protéger de vos propres erreurs et des choses stupides que l'autre gars pourrait faire avec votre code en rendant les constructions de code très rigides et inflexibles et impossibles à se mêler de l'intention initiale qu'il était. écrit avec et beaucoup de gens ont écouté. Je ne dirai pas qu'ils ont toujours tort (pourrait le penser), mais je dirai que c'est la mauvaise approche de l'interface utilisateur Web et je crois que c'est quelque chose d'un phénomène que nous avons lancé, maintenu et modifié par le client- les interfaces graphiques secondaires à un rythme beaucoup plus rapide et avec une plus grande facilité que ce travail était généralement accompli dans des langages plus restrictifs dans le passé. Pouvoir changer les choses rapidement et facilement rend beaucoup plus facile d'avoir des schémas d'architecture dynamiques / fluides qui ne nécessitent pas de quantités monumentales d'indirection et d'abstraction, ce qui rend finalement plus facile de voir ce qui se passe dans votre code et anticiper ou gérer les exceptions beaucoup plus proprement. Il est plus facile à maintenir simplement grâce à la simple possibilité d'être plus direct dans tout ce que vous faites et avec beaucoup moins de code qu'il n'en faudrait compte tenu de l'autre philosophie.
Comment JS est-il devenu populaire? Il s'est avéré être un excellent outil pour le travail à maintes reprises. Ce n'est pas la langue avec laquelle nous sommes «coincés». C'est la langue qui a peut-être inspiré beaucoup d'évolution dans les langues populaires en général. Et pour cela, vous pouvez remercier Brendan Eich et tous les contemporains qui ont aidé à mettre l'idée dans sa tête, pour avoir aimé Scheme comme une inspiration de conception adaptée au problème actuel plus qu'il n'aimait Java.