Apprendre JavaScript, HTML 5, CSS 3, devenir développeur web, tout le monde en parle. Mais savez-vous réellement pourquoi ? Je vous propose de parcourir ensemble le chemin qui nous mène jusqu’a cet article et d’imaginer les orientations possibles en terme d’opportunités techniques, d’emploi et pourquoi il ne faut pas apprendre JavaScript 😉

Apprendre JavaScript, vaste sujet. À en croire les sirènes, c’est la consécration ! Je vous ai déjà parlé d’un gros défaut que j’avais et que j’ai mis longtemps à me défaire ? Lorsque j’étais expert technique Microsoft, j’avais ce défaut bien connu de vouloir mettre ce que je maîtrise partout (ici du Microsoft) 🙂

Enthousiaste et motivé par l’ensemble des technologies proposées par l’éditeur, je pensais assurément faire les bons choix. À vrai dire, je me laissais parfois attirer par des motivations techniques et envies personnelles, plutôt que les meilleurs choix nécessaires pour réaliser le projet en cours.

Avec les années j’ai appris à me concentrer sur les solutions pour répondre aux problématiques, dans les temps et budgets alloués. Cela implique de regarder parfois au delà de la technologie, sur le côté, mais aussi à la source. Il n’est pas rare de pouvoir solutionner un problème technique en discutant avec le client pour adapter l’approche initiale, voir proposer des scénarios plus simples, ou des compromis d’utilisation acceptables qui vont permettre de ne pas construire des usines à gaz, à faire trembler les plus grands oligarques russes !

Avant d’apprendre javascript, un coup d’œil dans le rétroviseur

Pour comprendre où nous allons, il peut être utile de commencer par savoir d’où l’on vient… abordons ensemble quelques étapes clefs de l’informatique. Ne dit-on pas que l’histoire se répète ? …

Les évolutions importantes du numérique ont souvent été guidées par ces trois domaines :

1. La puissance de calcul
2. La mémoire
3. Le réseau

Les calculateurs, ancêtre de l’ordinateur

Nous pouvons noter en synthèse les caractéristiques suivantes :

• Pas de réseau
• Puissance de calcul centrale
• Mono-utilisateur
• 17 468 tubes à vide (ancêtre du transistor) 😉

Topologie :

Il faut bien commencer quelque part non ? 🙂 Ici pas de réseau, pas de tweet, pas d’intelligence artificielle. On dit parfois que le problème se situe entre la chaise et le clavier… ici pas de clavier, pourtant il y avait déjà des problèmes 😉

Mainframe, AS/400

• Réseau
• Puissance de calcul centrale
• Multi-utilisateurs
• Accès par des terminaux

Formidables environnements qui vont être supplantés par les applications de bureau lors de l’avènement du PC, encore utilisés aujourd’hui… saviez- vous que la facturation professionnelle et particulier d’un grand opérateur mobile est encore réalisée par des programmes écrits en Cobol ? 🙂

Ici les données de l’entreprise sont consommées via des écrans verts qui servent uniquement à l’affichage et la saisie d’information, via des terminaux. Est-ce un schéma que l’on va retrouver plus tard ? …

PC (personal computer), les débuts de javascript ?

• Pas de réseau
• Puissance de calcul centrale
• Mono-utilisateur

Tiens, cette topologie ne vous rappelle pas celle du calculateur plus haut ? Le PC fait son apparition dans les foyers, internet pour les particuliers arrive juste après…

Le PC en entreprise

• Réseau
• Puissance de calcul répartie (serveur et ordinateur)
• Multi-utilisateurs

La puissance de calcul des PC en entreprise permet d’envisager des scénarios différents en déchargeant le serveur d’application mais également les traitements réseaux qui se décentralisent (on peut se transférer des fichiers poste à poste sans passer par le serveur…).

Internet, les débuts…

• Réseau, bas débit
• Puissance de calcul répartie (serveur et ordinateur)
• Multi-utilisateurs

L’accès à internet permet de nouveaux scénarios, pour les particuliers mais également les entreprises. Ces dernières peuvent interconnecter les différents sites physiques en utilisant des réseaux privés virtuels s’appuyant sur le maillage d’internet. Les particuliers quant à eux peuvent librement s’échanger des volumes de fichiers important de façon décentralisée. De nouveaux scénarios mais finalement des topologies qui restent les mêmes…

Le cloud computing (public)

• Réseau
• Puissance de calcul centrale
• Multi-utilisateurs

Les données des entreprises sortent des locaux pour s’accrocher dans le nuage, il en est de même pour les données des utilisateurs, des actions qui vont poser des problèmes de souveraineté… mais ce n’est pas (encore ?) le sujet 😉

Tiens, vous n’avez pas déjà vu cette topologie quelque part ?

Changement d’échelle

On change toujours des ampoules, mais un peu plus haut…

Coder pour changer de vie

Mainframe VS Cloud

• Réseau
• Puissance de calcul centrale
• Multi-utilisateurs
• Accès par terminaux

• Réseau
• Puissance de calcul centrale
• Multi-utilisateurs
• Accès part terminaux (navigateur internet, application mobile, …)

L’avantage avec la nouveauté, c’est qu’elle ne reste jamais neuve. Il y a toujours une nouvelle nouveauté pour faire vieillir la précédente.

Frédéric Beigbeder / 99 francs

Les terminaux ont changé, mais finalement il y a une forme de répétition… Je vous laisse comparez les deux listes ci-dessus pour vous faire votre propre point de vue. C’est une vision simplifiée et macro, je vous l’accorde on pourrait faire de même avec les voitures. Une Ford du siècle dernier par rapport à une 5008 suivent le même schéma et changement d’échelle : la 5008 va plus vite, apporte un plus grand confort et plus de sécurité.

Ah non en fait. Le cloud apporte-t-il plus de sécurité pour les données ? Qui a dit qu’il peut y avoir une régression dans toute forme de progrès ? 😉

Peut-on prédire le schéma de demain, la prochaine topologie à venir ?

Comme tout modèle, le cloud a ses avantages et inconvénients, profitant des opportunités technologiques pour évoluer (souvenez vous : la puissance de calcul, la mémoire, le réseau). Ainsi certains prédissent une augmentation de l’utilisation des périphériques autour de l’utilisateur, pour décharger le cloud de certains calculs, et limiter l’usage de la bande passante.

Ok Nicolas, mais JavaScript dans tout cela ? Et bien c’est là que ça devient passionnant, on s’aperçoit qu’il n’y a pas que ce type de topologie qui se répète, il y a également les architectures applicatives. Est-ce que JavaScript et la place qu’il représente dans le vocabulaire technico-médiatique aujourd’hui n’est pas voué à suivre le même courant que certaines approches à présent oubliées ?

Et JavaScript dans tout ça ?

Petit état des lieux

Nous allons aborder rapidement, de façon simple les différents modèles applicatifs qui se sont succédé et les mettre en perspective avec ce que nous connaissons aujourd’hui, une approche qui nous donnera les éléments pour imaginer les évolutions possibles demain…

Le terminal

C’est souvent par ce type d’application que l’on apprend à coder, en lisant les entrées du clavier, effectuant un traitement sur les données saisies par l’utilisateur, affichant du texte sur l’écran pour interagir avec l’utilisateur. On connait les « écrans verts » souvent via l’AS/400 (qu’on pourrait nommer le géant vert 😉 ) mais beaucoup d’autres applications l’utilisent (matériel réseau sans écran, utilitaires pour des traitements distants, cloud, Raspberry Pi, …)

Les applications de bureau

Les applications de bureau se sont imposés avec les systèmes d’exploitation fenêtrés (Windows/Mac/Linux) et sont apparus les environnements de développement RAD pour Rapid Application Development.

D’un simple glisser / déposer il était possible de créer une interface utilisateur très rapidement. En entreprise, beaucoup d’application de gestion se sont développé sur ce modèle, en accédant aux données de l’entreprise via des bases de données centralisées. Le modèle de déploiement poste par poste puis en réseau peut paraître assez lourd aujourd’hui, des alternatives ont tenté d’y répondre

Rich Client Platform

Se basant sur le fonctionnement éprouvé des environnements de développement Java (Eclipse et Netbeans), l’idée suivante a germé : développer des applications d’entreprise sous forme de plugins, bénéficiant ainsi des avantageux mécanismes de mise à jour, simplifiant les déploiements.

Cette approche a permis également de limiter le code redondant nécessaire au design des applications de bureau, en s’inscrivant dans un cadre logiciel qui le gérait pour nous… vous pouvez notamment voir ce type d’application sur les postes des conseillers de grandes enseignes…

Une belle approche, qui a comme contrepartie de ne pas avoir totalement la main sur le design visuel, et donc une expérience utilisateur forcément limitée pour certains scénarios…

Smart Client

Comment obtenir le meilleur de tout les mondes, en garantissant l’évolution des applications avec les technologies en devenir ?

L’approche Smart Client permet de bénéficier d’une expérience utilisateur riche avec une application de bureau. La communication avec une couche orientée service plutôt qu’avec une base de données SQL, permet de déporter la logique métier côté serveur, tout en laissant la poste ouverte à d’autres technologies d’interface utilisateur qui l’époque étaient en devenir (HTML 5, CSS 3) mais pas encore disponible / mûre pour le monde de l’entreprise. Reste encore le poids des déploiements…

Rich Internet Application

L’idée ne semblait pas mauvaise et a eu un fort engouement. Toute la puissance d’une expérience utilisateur digne d’une application de bureau, au sein du navigateur internet. Facilité de déploiement (hormis l’application du plugin dans le navigateur), et pour Silverlight, la chaîne de développement .Net éprouvée à disposition, avec des équipes formées, prêtent à créer l’avenir d’internet… mais cela était sans compter sur l’établissement des standards HTM5 et CSS3…

Les applications web (le début) et javascript en mode pompier…

La promesse est d’importante : HTML5 et CSS3 doivent définir les standard pour la conception d’interface utilisateur, en apportant le niveau de fonctionnalités des applications de bureau …

Malheureusement les échanges entre le navigateur et le serveur donnent à l’utilisateur un sentiment de rechargement permanent, ce qui nuit à l’expérience utilisateur. Javascript tente de combler ce problème comme il le peut avec des appels asynchrone (Ajax) pour masquer cet inconvénient à l’utilisateur, créant parfois des usines à gaz, différentes suivant les développeurs avec un langage qui n’a pas la maturité qu’on lui connait aujourd’hui, bref, de beaux plats de spaghettis…

Single Page Application, la solution grâce à JavaScript ?

La nature a horreur du vide, là où JavaScript est venu combler un premier vide, les frameworks React, Angular et Vue.js tentent de combler le reste en offrant à l’utilisateur des applications web sans rechargement, et au développeur un cadre de développement plus solide et outillé, mais…

Progressive Web Application

C’est en 2015 qu’est apparu le terme de Progressive Web Application, une proposition de Frances Berriman Alex Russel, ingénieur chez Google. On peut le résumer ainsi : Une application web, qui s’exécute principalement sur les smartphones en se faisant passer pour une application native, le navigateur internet qui l’exécute n’est pas visible. Il est possible de faire apparaître une icône sur l’écran d’accueil pour lancer l’application, également d’exécuter des notifications utilisateurs. Un des gros avantages est de ne pas avoir à passer par les magasins d’applications d’Android et Google. L’autre avantage majeur, est que le contenu de l’application (web donc) est indexable par les moteurs de recherche sur internet…

Google est plutôt moteur, un peu moins Apple… allez comprendre 😉

(en relisant, je me dis que pour Google, c’est un comble d’être moteur… je sors…) 😉

Le modèle Single Page Application a 10 ans de retard…

Le SPA est la transformation des anciens plugins de RIA, en utilisant les normes HTML5, CSS et le langage JavaScript. Les éditeurs se sont effacés (Microsoft, Adobe) au profit des standards ouverts sur lesquels se sont installés d’autres éditeurs (Google, Facebook). Quand sera-t-il quand la normalisation va opérer pour imposer des standards au niveau des modules de code (on en parle plus loin …) ?

Savoir sortir du cadre

Il est tant maintenant de faire un focus sur JavaScript, savoir sortir du cadre est important, qu’en est-t-il ?

JavaScript s’exécute aujourd’hui dans différents cadres : navigateur internet, application de bureau, serveur alors qu’il n’était pas conçu pour cela au départ.

Pourquoi ? Plusieurs raisons à cela dont une des principales est la disponibilité sur le marché de beaucoup de développeurs formé à HTML 5, CSS et JavaScript… dans un monde ou les applications se développent de plus en plus, c’est un atout non négligeable…

JavaScript côté serveur

Côté serveur vient l’idée astucieuse d’apporter à JavaScript ce qui lui manque : l’accès aux ressources des systèmes d’exploitation en dehors du navigateur internet. C’est ce que décide de faire Ryan Dahl en 2009 en créant Node.js. Comme il existe des moteurs d’exécution JavaScript devenus très puissant au fil des années, pourquoi ne pas les utiliser en mode autonome, en dehors des navigateurs internet ?

C’est ce que fait le projet Node.js, en ajoutant une couche écrite en C++ pour donner l’accès au système de fichier, au réseau… Deno permet la même chose avec TypeScript comme langage (qui est finalement transpilé en JavaScript). Cette fois c’est le langage Rust qui est utilisé pour l’écriture de Deno et la couche d’abstraction avec le système, tout en souhaitant améliorer les points de faiblesse de Node.js

JavaScript côté application de bureau

Côté application de Bureau, Visual Studio Code est un bon exemple d’une implémentation réussi autour de HTML 5, CSS 3, et JavaScript en se basant sur le moteur électron (qui utilise Node.js)…

C’est parfait alors ? Pourquoi ne pas apprendre JavaScript alors ? JavaScript est le langage, et ce qui fait sa pertinence dans les choix d’implémentation, n’est pas tant le langage en lui-même, mais aussi et surtout les cadres logiciels qui permettent son exécution, avec l’avantage par exemple d’avoir des bases de code directement utilisable (via les modules Node.js), mais peut être lourd (nécessiter d’embarquer un moteur d’exécution web complet pour profiter des traitements HTML, CSS et l’exécution du code JavaScript). C’est parfois utiliser une enclume pour écraser un clou.

Node.js (et Deno) ont également leur limites de conceptions, qui réduisent également les scénarios d’utilisation en entreprise. Que faire quand les projets d’envergure évoluent et que l’on tape dans les limites des implémentations serveur, alors qu’on ne connaît que JavaScript… ?

JavaScript a plusieurs cadres d’exécution, que font les autres ?

Il peut être intéressant de jeter un œil sur le côté, prenons le cas de Flutter de Google

Google souhaite une continuité de l’expérience utilisateur sur tous les périphériques, et il s’en donne les moyens ! Flutter est basé sur un moteur de rendu 3D qui permet d’afficher les composants d’interface utilisateur sur tout système d’exploitation où le moteur a été porté.

Il est ainsi possible de développer des applications pour mobile, et bureau avec les performances d’une application native. Le web est également une destination possible.

Ici JavaScript n’est pas utilisé. Le langage utilisé est Dart. Il a été écrit en partant de zéro et ne souffre pas (encore) du poids de l’histoire concernant l’évolution d’un langage de programmation. Il est intuitif, moderne et puissant. Concernant le design des applications, le moteur de style est très proche du CSS, la transition des développeurs web est ainsi facilité.

Pour en savoir plus sur Flutter, vous pouvez découvrir le défi 30 jours : créer une application android et ios en partant de zéro.

Et les WebAssembly ? Les objectifs

• Être rapide, efficace et portable
• Être lisible et débuggable
• Conserver la sécurité
• Ne pas casser le web

Voici une approche fort intéressante, qui peut sans doute apporter autant de changements que l’ont fait HTML 5 et CSS 3. Une WebAssembly est le standard en devenir qui permet d’utiliser du code créé dans un langage, depuis un autre langage avec des performances natives.

Cela est déjà possible. Par exemple python peut appeler du code C++, mais on reste sur un nombre de liaisons limitées, souvent unidirectionnel. Toutes les interconnexions sont possibles, via un standard d’exécution…

Premier objectif côté navigateur internet : gagner en performance là où la transpilation en code JavaScript atteint ses limites (volume, rapidité d’exécution) et ajouter des fonctionnalités quasi équivalentes à l’expérience “Bureau” en termes de performance (traitements d’image, de vidéos, jeux vidéos, émulateur, cryptage, outils pour les développeurs, etc…).

Là où la chose est encore plus intéressantes, c’est qu’il est possible d’utiliser ces mécanismes en dehors du navigateur internet !

WebAssembly, quels scénarios possibles ?

Un gros avantage se dégage pour les entreprise, il va être possible d’utiliser du code métier interne et le rendre disponible sans avoir à le réécrire pour suivre les évolutions techniques et (parfois) les modes.

Également gagner en productivité en utilisant du code d’autres technologies / plateformes (modules NPM, framework.net, etc…) pour accélérer les développements, ou bien combler les manques sur la technologie utilisée du moment.

Les équipes vont pouvoir tirer profit de leurs connaissances en appelant du code WebAssembly depuis leurs langages de prédilection, plateforme. Un confort et un avantage supplémentaire pour les entreprises en termes de formations, permettant d’apporter des formations plus poussées plutôt qu’une fuite en avant vers les nouveautés.

WebAssembly, mais encore ?

Si un des défis du cloud à venir est de limiter les calculs centralisés et optimiser les échanges réseaux, tout cela en utilisant les périphériques proches de l’utilisateur via un réseau maillé, WebAssembly n’est-il pas une opportunité de le faire ?

D’autres y verront une opportunité de crypté du bitcoin avec un terrain de jeux plus vaste 🙂

L’avenir nous le dira ;).

WebAssembly, exemple d’impact : Microsoft

Si Microsoft (et Adobe) ont perdu le combat du RIA au profit des standards ouvert pour le design d’interface utilisateur, ce sont peut-être les standards ouverts en terme d’exécution de code (WebAssembly) qui vont lui permettre de revenir dans la course.

L’éditeur propose en effet une approche très intéressante, la capacité d’utiliser (à nouveau) la technologie .Net de bout en bout, ainsi que les outils associés, capitalisant sur les équipes déjà formées, diminuant ainsi les fragmentations technologiques au sein d’un même projet, sources de coûts directs et indirectes…

Bilan rapide. JavaScript ?

Nous l’avons vu différentes topologies se répètent, à différents niveaux. Le rythme de ces cycles est cadencé par les évolutions autour de la puissance de calcul, de la mémoire et des réseaux.

Faisons ensemble la liste des points abordé dans cet article (et la vidéo également) :

• La nature a horreur du vide
• JavaScript l’a comblé quand HTML5 et CSS sont devenus des standards pour l’UI, faisant émerger des frameworks (Angular, React, Vue.js)
• Des idées ont émergées pour profiter des compétences disponibles sur le marché (HTML5, CSS, JavaScript) et aller plus loin en sortant du cadre (Node, Deno, Electron).
• Les RIA ont disparus alors qu’ils comblaient un vide, qu’en sera-t-il pour angular, react, vue.js (& Co) ?
• Les WebAssembly offrent de nouveaux scénarios, sont moteur de croissance tout en capitalisant sur le code existant et les équipes en place… les frontières entre les catégories de développeurs vont évoluer.

Nous sommes tous développeur

Vous le comprenez, les différences entre les différents types de développeur sont assez minces… n’est-il pas ? 😉

C’est l’occasion d’appuyer un point qui me tient à cœur : Pour moi il n’y a pas de développeur Front, de développeur back, de développeur FullStack. Nous sommes tous Développeur avec des envies et préférences, qui nous animent.

Ces cases sont évidemment pratiques pour ranger des individus dans un projet, mais la potentialité d’une personne ne peut s’enfermer dans un cadre.

Bien sûr JavaScript n’est pas prêt de mourir, d’ailleurs où sont les détracteurs de Cobol, encore utilisé aujourd’hui ?

La solution adaptée, au bon endroit, au bon moment

De façon pragmatique, il est important d’avoir la solution adaptée, au bon endroit, au bon moment. JavaScript l’a été, mais pas tout seul. Il lui faut un moteur d’exécution. Le succès côté serveur s’appuie fortement sur un nombre de modules de code utilisable rapidement (gain de productivité) et une conception (Node.js) qui facilite le montée en charge tout en simplifiant la création de microservices. Nous sommes donc sur un succès, mais dans un cadre applicatif restreint.

Côté client c’est bien HTML 5 et CSS 3 les standards d’interface utilisateur, JavaScript n’est que le liant. Même avec l’évolution du langage, il reste un plat de spaghetti s’il n’est pas soutenu par les frameworks célèbres : React, Angular, Vue.js. À tel point que beaucoup lui préfèrent TypeScript, bien que ce soit du javascript executé en bout de chaîne. N’est-ce pas le poids de l’histoire, celle d’une fuite en avant ?

Il est important de ne pas s’arrêter au langage de programmation seul (cela vaut d’ailleurs pour tous les langages).

Les développeurs comprenant l’ensemble de la chaîne de valeur et les fondamentaux plutôt qu’un langage de programmation ont les portes grandes ouvertes…

Vite, une boule de cristal !

Les transformations sont en cours, JavaScript ne sera-t-il pas de plus en plus utilisé pour assembler des WebAssembly ? Il reste un langage permissif avec des avantages et inconvénients. L’avantage principal qui peut ressortir est qu’il peut s’apprendre rapidement en cas de besoin, c’est pourquoi il peut être intéressant de ne pas fixer l’apprentissage de JavaScript comme un objectif, encore moins comme une priorité absolue. En maîtrisant les concepts nécessaires à l’ancrage de bases solides, JavaScript ne sera qu’une formalité le moment venu, n’apprenez pas Javascript, construisez vos fondamentaux, ils vous permettront d’évoluer, avec les évolutions 😉

Partagez cet article ainsi que la vidéo, ? Inscrivez-vous à la newsletter ainsi qu’a ? la chaîne Youtube. Écrivez un commentaire en bas ce l’article, que vous soyez pour ou contre, argumentez avec passion, l’échange et le partage sont toujours un plaisir !

À très vite,

Nicolas.

Merci !

En complément, vous êtes libre de recevoir GRATUITEMENT mon livre "GUIDE D'UN AMI pour démarrer une carrière de DÉVELOPPEUR en 6 étapes".  Vous y découvrirez :

Les clefs pour comprendre le métier de développeur et vous permettre de changer de vie.

Des astuces pour monter facilement en compétence sur des nouvelles technologies.

Des conseils pour choisir et apprendre votre premier langage de programmation.

Une vue d'ensemble sur les formations et le marché de l'emploi pour vous aider à faire le premier pas dans votre apprentissage et votre changement de vie.

recevoir le guide

Je hais les spams : votre adresse email ne sera jamais cédée ni revendue. En vous inscrivant ici, vous recevrez des articles, vidéos, offres commerciales, podcasts et autres conseils pour vous aider à coder et changer de vie. Voir mentions légales complètes en bas de page. Vous pouvez vous désabonner à tout instant.