L’image ci-dessous résume les débuts du web :

Au début, donc, il y avait les dinosaures. Et ils n’avaient pas le web. En ce qui concerne l’informatique, les dinosaures ont vécu jusqu’en 1989, année à laquelle le World Wide Web (www) et le HyperText Markup Language (HTML) sont nés. Ce sont des chercheurs du CERN, le centre européen pour la recherche nucléaire, qui les ont créés afin de pouvoir échanger plus facilement des informations scientifiques. En effet, à cette époque, l’échange se faisait encore principalement par courrier papier ou, éventuellement, par email, mais ce n’était pas très pratique. Du fait de cet objectif, HTML était initialement prévu pour avoir du contenu uniquement textuel.

Au début, ce nouveau langage ne rencontre pas beaucoup de succès, personne ne souhaite développer de navigateur. Sans doute le tout premier est Lynx, qui apparaît en 1992. C’est un navigateur textuel (normal puisque HTML l’est également) et il affiche les pages dans une console. Donc, pas de menu déroulant, tout se fait au clavier… En 1993 arrive le premier navigateur tel qu’on les connaît maintenant, c’est-à-dire une application avec une interface graphique. Il s’agit de NCSA Mosaic développé par le National Center for Supercomputing Applications (NCSA) à Urbana-Champaign dans l’Illinois. C’était donc un logiciel académique. Ici, on a fait un bond dans l’ergonomie : on a enfin des menus, une mise en page avec plusieurs tailles de polices de caractères (les Cascading Style Sheets (CSS) existaient déjà), bref c’est royal… à ceci près que lorsque vous chargez une page, vous avez le temps d’aller prendre un café. C’est, à mon sens, en 1994 que la première amélioration significative apparaît. En effet, une équipe de NCSA Mosaic migre vers la société Netscape Communications et développe un nouveau navigateur, netscape. Là, on a une application avec interface graphique très efficace pour l’époque, qui affiche les pages web beaucoup plus rapidement que NCSA Mosaic. Le web est enfin accessible et utilisable.

Jusqu’en 1994, un seul langage permet de créer des pages web : HTML (deux si on considère également CSS). Mais celui-ci n’offre qu’une interaction limitée avec l’utilisateur. En effet, les pages web sont « statiques » en ce sens qu’elles sont créées une bonne fois pour toutes et ne peuvent pas adapter leur contenu à l’utilisateur. Par exemple, il n’est pas possible en HTML pur de faire une page qui affiche une sélection de smartphones android pour certains utilisateurs et des smartphones iOS pour d’autres. En 1994, précisément, Rasmus Lerdorf dépose son CV sur internet et souhaite conserver une trace des visiteurs qui l’ont consulté. Problème : HTML ne permet pas cela. Il crée donc un nouveau langage qu’il nomme Personal Home Page (PHP). C’est la première rupture technologique du web. Une page n’est plus créée statiquement, c’est un programme qui la génère et qui peut donc en adapter le contenu à l’utilisateur.

L’interaction avec PHP reste toutefois limitée. En effet, PHP est exécuté sur le serveur web, pas sur le navigateur de l’utilisateur. Par conséquent, chaque interaction passe par le chargement d’une nouvelle page depuis le serveur. C’est moyennement pratique à l’époque, notamment parce que les débits sur internet sont limités. En France, par exemple, la plupart des gens n’ont pas accès à internet, ils ont juste accès au minitel. Pour avoir accès à internet de chez soi, il faut se connecter à une université ou un grand groupe industriel par modem. Les plus chanceux ont un modem 56K, c’est-à-dire à 56 kilobits par seconde, soit 8 kilo-octets par seconde, les autres ont un modem 33.6K. Donc, pour le commun des mortels, recharger totalement une page est coûteux. Imaginons qu’on remplisse un formulaire pour le transmettre à un serveur web. C’est le serveur qui doit vérifier via PHP que le formulaire est bien rempli. Donc il faut transmettre ce dernier au serveur. Si on a oublié de saisir un champ, le serveur doit retransmettre à l’utilisateur le formulaire en lui demandant de saisir le champ oublié. C’est lourd. C’est très lourd. C’est très très lourd. En 1995, les développeurs de Netscape développent une alternative à PHP, un nouveau langage appelé LiveScript, qui est une version simplifiée de Java et qui a vocation à être exécuté côté serveur web, comme PHP. Java est en effet le nouveau langage à la mode. Il est développé par Sun Microsystems. Aussi, les concepteurs de LiveScript se rapprochent de Sun Microsystems pour essayer de travailler ensemble afin de populariser ce nouveau langage. Pour mettre toutes les chances de leur côté pour capter l’intérêt de Sun Microsystems, ils renomment LiveScript afin de bien mettre en valeur le côté Java du langage. Ils l’appellent donc JavaScript. En concertation avec Sun, ils ont en plus l’idée qui va tout changer : faire en sorte que JavaScript soit exécuté sur le navigateur plutôt que le serveur. C’est la deuxième rupture technologique du web. Maintenant, on peut contrôler les formulaires (et faire bien plus que cela) directement sur le navigateur. Les interactions avec l’utilisateur ont fait un bond en avant.

Résumons : avec PHP, on génère côté serveur des pages web adaptatives. Avec JavaScript, on interagit avec l’utilisateur côté navigateur en ce qui concerne le contenu de la page web qui a été chargée. Dans ce processus, le souci c’est qu’il est impossible charger une « grosse » page web par petits morceaux afin d’accélérer les temps de chargement. Par exemple, imaginons qu’on affiche une page contenant la liste de tous les étudiants de Polytech, avec toutes leurs notes. Cela prend du temps à charger parce qu’il y a beaucoup d’informations. À la place, ce serait mieux de ne placer dans la page que la liste des étudiants, sans information, et, lorsque l’utilisateur clique sur un étudiant, de charger et d’afficher les informations de cet étudiant uniquement. Un tel procédé ne devient possible qu’en 1998. À cette époque, Microsoft développe un composant ActiveX appelé XMLHttpRequest (XHR en abrégé) pour son application web nommée Outlook Web Access. De ce composant dérive une nouvelle technologie Ajax (asynchronous JavaScript and XML). C’est la troisième rupture technologique du web. En effet, elle permet de charger dynamiquement les morceaux de pages mentionnés plus haut. Les frameworks web modernes tels que React, Angular, Vue, Ionic, etc., s’appuient sur Javascript + XHR.

On a vu ce que je considère comme les trois ruptures technologiques majeures du web. Par la suite, les évolutions sont moins majeures. Beaucoup sont fondées sur l’utilisation ou l’adaptation de langages à la mode pour générer les pages web côté serveur web. Ainsi, en 2000, Microsoft lance un nouveau framework, ASP.NET, compatible avec ses autres technologies .NET, C#, etc. En 2005, Python est très à la mode, on voit donc apparaître le langage Django, qui s’appuie beaucoup, comme Python, sur de la réutilisation de code. Ruby est également un langage populaire et son adaptation web créée en 2005 s’appelle Ruby on rails. On peut également citer Golang, développé par Google en 2007. C’est un langage avec une syntaxe proche de C, qui est prévu pour permettre le développement efficace et sécurisé d’applications web.

Des débuts du web, on peut constater que la majorité des langages ont vocation à être utilisés sur des serveurs. Seul Javascript s’exécute côté client. En le combinant avec Ajax, ou tout du moins XHR, on a un mécanisme ultra puissant pour charger les pages web. Cela rend JavaScript peut-être plus attractif que les autres langages et c’est ce qui explique sa prépondérance dans la deuxième partie de notre historique.

En 2009, Ryan Dahl doit réaliser une barre de progression de chargement de fichier sous Flickr (un site web de partage de photographies et de vidéos gratuit). Côté navigateur, pas de problème, on peut utiliser Ajax pour récupérer les données et JavaScript pour mettre à jour les affichages. Mais, finalement, c’est dommage que l’on ne puisse pas exécuter également du code JavaScript côté serveur web. Il crée donc NodeJS (node). L’idée est double : utiliser le moteur JavaScript V8 de Google pour exécuter du javascript sur un desktop et créer une boucle d’événements qui permet à node de fonctionner en mode asynchrone et, ainsi, de gérer plein de clients (navigateurs) en même temps tout en supprimant autant que possible les temps de latence inutiles. Mais on reverra cela plus précisément lors des séances consacrées à node.

En 2010, Google a l’idée géniale de changer le paradigme de génération des pages web. Jusqu’ici, c’est le serveur qui génère les pages et le navigateur les charge. Ensuite seulement apparaît l’interaction avec l’utilisateur. Google propose un framework dans lequel c’est le navigateur lui-même qui génère la page. Il s’appuie donc sur JavaScript et Google le nomme AngularJS. L’idée consiste à ce que l’utilisateur charge des fichiers JavaScript et ce sont eux qui vont construire la page web et réaliser les interactions avec l’utilisateur, notamment en exploitant à fond XHR. Même si toute la technologie sur laquelle s’appuie AngularJS existait déjà, ce changement de paradigme en fait, de mon point de vue, la quatrième rupture technologique majeure du web. En 2014, Google fait une refonte totale d’AngularJS, ce qui donne un nouveau framework appelé Angular. Celui-ci s’appuie sur TypeScript, une extension typée de JavaScript développée en 2012 par Microsoft pour améliorer la sécurité de ses codes Javascript. Depuis, Angular est mise à jour régulièrement par Google.

En 2013, surfant sur l’idée de Google, Facebook lance React, un framework fondé également sur JavaScript. L’idée est similaire mais l’implémentation est différente. Comme vous le verrez, Angular va vous imposer une structuration particulière de votre application. De ce point de vue, React est plus « open bar ». Angular s’appuie sur de la programmation objet contrairement à React qui ne le requiert pas. Bref, choisir entre l’un et l’autre est plus une question de goût, de style de programmation. En 2014, Evan You, qui travaillait précédemment dans l’équipe d’AngularJS, décide de proposer un framework équivalent mais indépendant des GAFAM, c’est Vue.

On voit donc que les années 2012-2014 sont très prolifiques en ce qui concerne les frameworks fondés sur JavaScript pour développer des frontends (le côté navigateur). Les rendus des navigateurs sont de plus en plus beaux et on peut se demander si l’on ne pourrait pas utiliser les techniques JavaScript du web pour créer des applications s’exécutant sur un desktop. Grâce à Node, on sait que Javascript peut s’exécuter sur le desktop. Il manque juste une couche pour créer des interfaces graphiques. Ce problème est pallié en 2013 par l’arrivée d”Atom Shell, qui deviendra Electron en 2015. L’idée consiste à avoir un backend en Node pour gérer les données de l’application et un frontend s’appyuant sur Chrome. On peut ainsi programmer une application graphique en ne se fondant que sur des techniques du web (des balises HTML, etc.). À noter que Visual Studio Code est programmé en Electron.

Évidemment, les technologies passées s’exécutant sur serveur ont également continué à évoluer. Par exemple, en Python, le micro framework Flask a été introduit en 2010. Un de ses avantages est qu’il est beaucoup plus rapide à prendre en main que Django. De même, en 2016, Microsoft a opéré une réécriture complète de ASP.NET, qui s’appelle ASP.NET core. Mais, pour l’instant, JavaScript reste le langage le plus utilisé pour réaliser des weberies.

Peut-être la dernière rupture en date est arrivée en 2015. Il s’agit de Web Assembly (wasm). L’idée clef est que, dans le cadre d’une programmation classique, on a plein de langages à disposition (C, C++, Java, OCaml, LISP, etc.), chacun ayant ses avantages et ses inconvénients. Pour un problème donné, il y a toujours un langage plus adapté que les autres et c’est à l’ingénieur que vous allez bientôt devenir qu’il revient de le choisir et l’exploiter. Dans les weberies côté navigateur, on n’a que JavaScript. Ce serait bien de pouvoir également exploiter ces autres langages. L’idée de wasm c’est que le développeur écrive le code dans le langage qu’il souhaite (il y en a beaucoup de supportés) et les navigateurs vont alors le compiler en bytecode puis l’exécuter via un interpréteur de bytecode (c’est le principe de Java).

L’historique ci-dessus n’est pas exhaustif. Il existe encore une foultitude de technologies que je n’ai pas mentionnées. Mais il ressort de ce qui précède que les technologies issues de JavaScript sont prédominantes actuellement. C’est pourquoi vous allez utiliser JavaScript, TypeScript, Angular et Node dans ce module. À la question « pourquoi Angular plutôt que React ou Vue », je répondrais que, même si la courbe d’apprentissage d’Angular est plus élevée que celle de React, je pense que c’est plus formateur d’utiliser Angular parce que :

1. Angular va vous obliger à bien structurer votre application, notamment à séparer la gestion des données (business logic) des affichages;

2. Angular est orienté objet et cela cadre bien avec ce que vous avez vu au premier semestre.

3. Étant donné qu’il est notoirement plus difficile d’apprendre Angular que React, peut-être vaut-il mieux l’apprendre dans un cadre académique dans lequel on peut vous assister puis apprendre React par vous-même plutôt que l’inverse.

Même si JavaScript est prédominant actuellement, il existe de nombreux sites qu’il faut maintenir et qui ont été écrits en PHP. En fait, 80% des sites dans le monde s’appuient sur des frameworks comme WordPress, Drupal, Joomla, qui sont du PHP. Il est donc utile de connaître PHP. C’est pourquoi la dernière technologie web que vous utiliserez dans ce module est PHP.