Javascript est le pire des langages. Je l'adore.

Hervé Rincent

Hervé Rincent

30 mars 2021

Lorsque je code, c'est souvent en Javascript.

Ce langage de programmation a une histoire fascinante.

En 1994, la startup Netscape commercialise son navigateur Internet “Netscape navigator”.

Le succès est rapide et suscite l'appétit des concurrents (dont Microsoft) qui prennent conscience de l’énorme potentiel commercial du web.

Le navigateur Netscape pouvait afficher le contenu d'une page, mais il lui manquait un point essentiel : l'interaction avec l'utilisateur. Elle était en effet très réduite : on pouvait seulement cliquer sur un lien pour aller consulter une autre page.

Sous la pression concurrentielle, il fallait trouver rapidement un moyen d'embarquer du code dans les pages web statiques pour les rendre dynamiques : comme cliquer sur un bouton pour déclencher l'affichage d'une fenêtre modale par exemple.

Alors en Mai 1995, Netscape décide de recruter Brendan Eich.

Brendan n'est pas un débutant. Titulaire d'un Master's degree en informatique, il a 10 ans d'expérience au moment de son recrutement chez Netscape.

Sa mission : créer un nouveau langage pour animer les pages web.

Le délai : 10 jours.

Oui.

Le langage de programmation le plus utilisé au monde en 2020 a été conçu en 10 jours.

C'est une jolie leçon d'entrepreunariat je trouve. C'est le besoin hurlant d'animer les pages web qui a fait le succès de Javascript. Et non pas ses qualités intrinsèques.

Parce qu'il faut bien se le dire, ce langage semble tout pourri lorsqu'on le découvre.

Un mariage improbable

Derrière cette légende des "10 jours" se dissimule une réalité un peu différente.

Brendan Eich n'est pas reparti de zéro.

Il s'est inspiré de 2 langages déjà existants :

Voila des parents bien improbables, et qui n'ont pas grand chose en commun !

Une Maman mathématicienne, qui code des fonctions pures, bien loin de la séquence d'instructions consécutives exécutables par un micro-processeur.

Un Papa ingénieur, qui code des objets pour modéliser des vraies entreprises et de solides industries.

Ces 10 jours sont le résultat de cette union atypique qui a donné naissance à Javascript.

Un langage fonctionnel, simplifié, sans typage fort. Un langage ultra flexible, qui permet de coder des objets, et n'importe quoi d'autre (même le pire).

Un langage bourré de défauts. Tellement simplifié qu'il ouvre la porte à d'innombrables bugs.

Mais dont la singularité est fascinante.

Tout est fonction

En Javascript, on code des fonctions.

Une fonction c'est un bout de code qui transforme des données d'entrées en données de sorties.

Mais les données peuvent aussi être des fonctions. On peut affecter des fonctions à des variables.

En Javascript, on peut utiliser une fonction AVANT de l'avoir décrite.

Dans une fonction, on peut utiliser la variable d'une fonction parente AVANT de l'avoir déclarée.

Javascript se moque souvent de l'ordre dans lequel vous avez écrit votre code.

Le temps ne s'écoule pas uniformément. C'est le langage parfait pour la 4e dimension, la science fiction, retour vers le futur.

Javascript, c'est la liberté. C'est coder sans entrave.

On peut passer plus d'arguments que ce qu'attend une fonction (ou moins). On peut additionner un nombre et une chaîne de caractères. On peut remplacer un tableau passé en paramètre par un objet.

On peut coder des opérations absurdes, sans provoquer la moindre erreur d'exécution.

On peut tout faire. Y compris n’importe quoi.

La standardisation

Peu après son lancement par Netscape en Décembre 1995, Microsoft contre-attaque en implémentant en 1996 sa propre version de Javascript dans le navigateur Internet Explorer 3, en lui donnant le nom de JScript.

Oui, car Microsoft avait déjà prouvé qu’il pouvait lui aussi faire n’importe quoi.

Netscape a alors vite compris l'intérêt de normaliser son langage, au risque de ruiner le caractère "universel" du web. Il fallait de toute urgence se mettre d'accord sur une spécifications commune de Javascript, pour que chaque navigateur puisse exécuter le code, et pas seulement celui de Microsoft.

C'est l'ECMA (European association for standardizing information and communication systems) qui publie les spécifications standardisées, sous le nom d'ECMA Script (ES). La version 1 (ES1) est approuvée en 1997.

Malgré cet effort de normalisation, les disparités entre les navigateurs Internet ont continué à poser problème car les niveaux d'implémentation étaient différents.

Il faut attendre l'arrivée de la bibliothèque JQuery en 2006 pour disposer enfin d’un moyen efficace de gommer ces différences. Elle déclenche l'invasion de Javascript dans le web.

D'innombrables outils satellites ont vu le jour afin de compenser les lacunes de Javascript.

Désormais, Javascript est omniprésent sur Internet pour gérer ses comptes bancaires, réserver un billet, acheter un produit en ligne, ...

La concurrence a été balayée, comme en témoignent les défunts plug-ins Flash, qui voulaient animer le web différemment.

Javascript n'est pas resté coincé dans les navigateurs.

Avec l'arrivée de NodeJS en 2009, Javascript investi le back-end.

La promesse est enthousiasmante : avoir un langage unique de programmation pour le client (le navigateur Internet) et le serveur.

Compte-tenu de la permissivité du langage, de son désintérêt complet à exécuter les instructions dans l'ordre ("l'enfer des callbacks"), le succès de NodeJS n'apparaît pas comme une bonne nouvelle pour tout le monde.

Javascript investit aussi le monde des application mobiles (react Native, Ionic) et des applications desktop (Electron).

Il acquiert ce statut de langage de programmation universel pour l'ensemble d'un projet, dès lors qu'il faut interagir avec un utilisateur au travers d'une interface graphique.

Est-ce un bon choix pour mon projet web ?

La question n'est plus de savoir si votre projet web va utiliser ou non Javascript.

La question est plutôt : jusqu'à quel point l'utiliser ? Faut-il le cantonner au navigateur ? Quel est le gain à mixer plusieurs langages pour le développement de votre projet ?

Le choix dépend de critères tels que :

Cette richesse est aussi un piège.

C'est l'effet “buffet à volonté”. A force d'empiler les dépendances, on risque d'arriver à des applications exagérément lourdes et complexes à maintenir.

Pourtant j'aime ce langage. Pour sa frugalité. Pour ses racines fonctionnelles et sa polyvalence qui laissent beaucoup de liberté au développeur sans imposer la “bonne méthode à suivre”.

Avec le recul, je constate que sa complexité est régulièrement sous-estimée par les développeurs.

Ça n'est plus le bout de code à confier au stagiaire pour faire clignoter un truc dans une page web. Ça n'est plus la petite fonction à ajouter pour récupérer les données d'une API.

C'est ce qui fait tourner l'immense majorité des SaaS et qui conditionne la première impression des utilisateurs (celle qu'on n'oublie jamais).


Continuer la lecture

Dessine-moi un mouton sur la lune

6 avr. 2021

4 min read

Dessine-moi un mouton sur la lune

Lire l'article
Faire travailler le client ou le serveur ?

23 mars 2021

4 min read

Faire travailler le client ou le serveur ?

Lire l'article
Inscription à la newsletter

Recevez chaque semaine un article pour réfléchir à votre prochain projet tech/data

gratuit, sans spam, désinscription en 1 clic

Merci ! Regardez dans botre boite mail. Un lien de confirmation n'attend plus que votre clic.
Arghh il semble compliqué de vous ajouter à la liste de diffusion. Et si vous m'envoyiez un mail directement à contact@camilab.co ?