Pourquoi les développeurs Java ont tout intérêt à développer une compétence Javascript

Cet article a une visée simple : pousser les développeurs back-end java à prendre conscience de l’intérêt des technologies front-end, javascript en tête.

A cette fin, il essaye de situer ces technologies dans un contexte plus large que celui fréquemment utilisé et qui consiste à embarquer des scripts dans une page HTML (ce qui n’est pas nécessairement une approche stimulante). Nous espérons ainsi contribuer à démystifier ces technologies.

L’age d’or du JavaScript

L’usage du JavaScript s’étend considérablement depuis quelques années, notamment grâce à diverses librairies, JQuery en premier lieu, qui fournissent des fonctions de haut niveau et masquent les différences de support du langage d’un navigateur à l’autre.

Plus récemment (tout est relatif) et avec l’arrivée de HTML 5/CSS 3, Adobe s’est désengagé de Flex et Microsoft de SilverLight ; ces deux technologies, considérées pendant un temps comme une alternative sérieuse au vieux trio HTML/CSS/Javascript, sont donc officiellement hors course (même si Flex poursuit sa vie en open source sous l’égide de la fondation Apache et que le plugin Flash est toujours soutenu par Adobe).

On assiste depuis à une « seconde vague » de pénétration de la technologie liée à l’essor des applications RIA[1] et à la perte de vitesse des solutions alternatives basées sur des plugins embarqués par les navigateurs.

Du coup, on a une éclosion de frameworks Js, AngularJs[2] en tête, qui permettent de développer des IHM directement supportées par les navigateurs. Ces frameworks supportent les problématiques usuelles liées au développement d’IHM : widgets, databinding, support MVC…

Pour ceux à qui la distinction entre librairie et framework ne sauterait pas aux yeux, nous recommandons la lecture de cet article[3] de Martin Fowler dont un court extrait est reproduit ci-après.

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework’s code then calls your code at these points.” (Fowler, Martin. Inversion of Control. 2005.)

Dans ces architectures on abandonne le mode page à page qui était la référence depuis l’origine du web : exit la génération de pages HTML côté serveur, les serveurs se cantonnent désormais pour l’essentiel à exposer les services métiers qui sont consommés par les IHM par différents mécanismes de RPC[4], REST[5] en tête comme il se doit. Les informaticiens étant friands d’acronymes, nous cédons à la tentation et citons les deux principaux :

  • SPA : Single Page Application,
  • WOA : Web Oriented Architecture.

L’approche SPA est la plus radicale : on a plus qu’une page HTML de bootstrap qui permet de télécharger un programme Javascript qui va entièrement piloter la gestion de l’IHM. A l’autre extrémité du scope on a des pages générées côté serveur mais embarquant beaucoup de comportements en Javascript. L’approche intermédiaire mixe un peu de génération côté serveur pour des pages de bootstrap embarquant des portions d’applications Javascript (cette approche permet notamment de libérer de la mémoire côté client au chargement d’une nouvelle page, ce qui peut s’avérer utile puisque la programmation Javascript n’étant pas exempte de fuites mémoire).

Au passage, nous insistons sur l’intérêt de REST comme mécanisme RPC à l’heure où le support des devices mobiles est de plus en plus souvent requis ; simplet et compact, il est bien adapté à des contextes mobiles.

On dispose également désormais de librairies de CSS avancées comme Twitter Bootstrap[6], et de divers outils permettant d’améliorer le langage CSS (Sass[7] et consorts).

On ne peut que faire le parallèle avec le vieux et tant décrié modèle client/serveur qui amorce son retour en force :

  • les libraires CSS et frameworks Js évolués facilitent le développement productif d’IHM,
  • tous les navigateurs modernes, IE inclus, sont désormais aptes à exécuter du code Js de façon fiable et performante,
  • le support des websocket[8] va se généraliser,
  • les améliorations à venir de la norme ECMASCRIPT 262.

Tout ceci n’a cependant rien de surprenant ; il y a belle lurette qu’on n’invente plus rien en informatique et qu’on ne fait que déplacer les problèmes. D’ailleurs, ce modèle qui se profile n’est en rien une nouveauté ; il a existé par le passé avec Corba  par exemple mais il s’appuie désormais sur les bases techniques popularisées par le web.

Javascript et jeeïstes

Historiquement les développeurs JEE ne sont pas, dans leur majorité, très friands de JavaScript. Bien entendu, on trouve des développeurs affutés aussi à l’aise côté front-end que back-end, mais si cette double compétence se développe, les plus anciens ont bien souvent des réticences.

Ceci peut probablement s’expliquer par différents facteurs. Il fût un temps où le niveau technique requis pour appréhender correctement la POO et la complexité affolante de la plateforme JEE les poussaient en ce sens ; ayant travaillé d’arrache pied pour maîtriser toutes ces usines à gaz, ils constituaient une espèce « d’élite » qui ne pouvait décemment pas s’abaisser à faire du scripting, avec un langage plein de spécificités particulièrement choquantes pour un ingénieur formé aux langages fortement typés. Il pouvait même y avoir un certain dédain pour le développement front-end considéré comme de la bidouille et du hack permanent vis à vis de technologies immatures.

« JEE a changé radicalement
et devient largement accessible »

Mais ce temps est bel et bien terminé, avec un effet de ciseau redoutable.
Côté back-end, la pression mise par le mouvement open source, Spring[10] en tête, a conduit JEE à changer radicalement et à devenir très largement accessible. Par ailleurs les alternatives open sources à JEE pullulent et de façon globale, les frameworks actuels masquent si bien la complexité sous-jacente qu’il n’est nul besoin d’être un dieu en informatique pour les mettre en œuvre. Il suffit d’ailleurs de se pencher sur le bagage technique d’une partie croissante des développeurs pour s’en persuader (mais après tout, c’est tout à fait logique : qui sait comment fonctionne son frigo ou sa tv ?). Clairement, les technologies côté serveur ont atteint l’âge de la maturité, les clients en recherche d’efficacité ne se jettent plus sur les derniers gadgets à la mode, la période où une petite connaissance de JEE permettait de se vendre à prix d’or comme architecte JEE est terminée.

Côté front-end et en parallèle, le web 2.0 est passé par là et des développeurs talentueux ont plus que démontré le potentiel des technologies web (HTML/CSS/Js) en produisant des sites d’une qualité quasi mystique pour qui était resté sur les débuts du JavaScript. Les capacités de la technologie étaient démontrées, les possibilités d’industrialisation et les qualités de maintenabilité, restées un temps en deçà, progressent désormais à grands pas, en particulier grâce à l’apparition de libraires, frameworks et outils s’inspirant largement des bonnes pratiques vulgarisées côté back-end.

« Le développement côté client :
the place to be ! »

Aujourd’hui les développeurs JEE ne peuvent plus se cacher derrière une expertise rare et coûteuse pour se spécialiser uniquement sur les aspects serveur des architectures modernes et doivent désormais considérer le coté client, donc le JavaScript.

Bien sûr, toutes les compétences acquises restent nécessaires et il n’est pas envisageable de voir les spécialistes Java se transformer en web designers maîtrisant toutes les subtilités (pour être poli) du rendu HTML de tel ou tel navigateur. Il subsistera toujours un besoin d’expertise côté serveur, mais le plus intéressant se passe désormais ailleurs et tout développeur soucieux de son employabilité doit désormais s’intéresser au développement client : that’s the place to be !

Dans cette optique, nous souhaitons apporter notre petite pierre à l’édifice et poser quelques bases dans l’espoir de faciliter ce mouvement.

Quelques bases techniques

La norme EcmaScript

Plutôt que de JavaScript, on devrait parler d’EcmaScript.

En effet JavaScript n’est qu’une implémentation de la norme ECMA- 262 (aka EcmaScript).  Cette norme a été initialement inspirée de JavaScript, une première version de ce langage inventé par Netscape pour dynamiser les pages à l’aube de l’Internet. Mais par la suite, la logique s’est inversée (un peu comme Hibernate a inspiré JPA, norme qui suit désormais sa propre route, et dont Hibernate n’est désormais qu’une implémentation parmi d’autres).

VersionDate
1st EditionJuin 1997
2nd EditionJuin 1998
3rd EditionDécembre 1999
4th EditionAbandonnée
5th EditionDécembre 2009
5.1Juin 2011
6 (Harmony)En cours de spécification

A l’heure actuelle, la dernière version de la spécification EcmaScript 262 est la v5.1.

Les autres normes

EcmaScript ne définit que le cœur du langage (core). Par exemple, une implémentation de ECMA-262 ne permet pas de parser du XML, ni de manipuler un DOM[11].

Ceci peut sembler étrange pour celui qui prend JavaScript par le petit coin de la lorgnette, à savoir un « petit » langage pour dynamiser une page HTML. Mais dans les faits c’est un vrai langage avec un noyau et des extensions avec diverses APIs.

NormeObjetOrganisme de normalisation
ECMA-357 (E4X)ECMAScript for XML
Support XML
ECMA
DOMReprésentation et interaction avec les documents HTML et XMLW3C

Selon l’implémentation et/ou le contexte d’utilisation d’une implémentation EcmaScript, on ne disposera donc pas nécessairement des mêmes APIs ; le core sera toujours disponible, pas nécessairement le reste.

Nous ne citons ici que deux exemples (le support E4X étant par ailleurs abandonné par les navigateurs modernes) mais il y a nombreuses autres extensions très intéressantes. Nous vous invitons par exemple à vous intéresser à la spécification Web Component du W3C.

Les implémentations de la norme EcmaScript

Il existe différents langages implémentant la norme : ActionScript (Flex), JavaScript (Netscape à l’origine), JScript (Microsoft).

JavaScript est donc un produit logiciel différent et distinct de la norme EcmaScript. Chaque implémenteur de JavaScript suit son propre plan de numérotation qui est distinct de celui de la norme.

Parler de JavaScript 1.x est un abus de langage. Cette même version 1.x pourra correspondre à un niveau de support différent de la norme selon l’éditeur de l’implémentation en question. Il faut dire, version X.Y de telle implémentation pour être précis, où se référer à la version EcmaScript 262 supportée.

D’un point de vue pratique, l’implémentation est portée par un moteur JavaScript. C’est donc le moteur JavaScript qu’on utilise qui va déterminer indirectement la version de la norme qui est supportée (et déterminer d’éventuels écarts avec la norme). De la même façon, qu’une version de JDK détermine les APIS disponibles en standard.

Les moteurs « JavaScripts »

Il en existe un grand nombre. Nous nous contentons ici de citer les plus récents et les plus courants.

MoteurEditeurRemarques
V8GoogleOpen Source
Implémenté en C++
Embarqué dans Chrome depuis toujours
Embarqué dans Node.js[12] (server side)
ChakraMicrosoftEmbarqué dans IE à partir de la v9 (Trident auparavant)
SpiderMonkeyMozillaOpen Source
Implémenté en C
Embarqué dans FireFox
RhinoMozillaOpen Source
Implémenté en Java. Embarqué dans la JDK 1.6
NashornOracleOpen Source
Remplace Rhino à partir de Java 8

Ces moteurs sont composés pour l’essentiel d’un interpréteur (EcmaScript étant un langage interprété) et de compilateurs JIT (compilateur à la volée).

L’introduction et l’amélioration de compilateurs JIT est pour beaucoup dans les gains de performances des dernières versions des moteurs Js. C’est cette même technique qui a permis, voici une quinzaine d’année, de rendre le langage Java beaucoup plus performant et de lui permettre de se développer.

Chaque moteur JavaScript a connu, comme tout logiciel, différentes versions.

D’un point de vue pratique, le moteur Js est embarqué par un « container » : un navigateur pour le cas le plus courant, mais aussi tout un tas d’autres logiciels (serveur d’application, logiciel de messagerie, framework de développement …).

Il est tout à fait possible de downloader un moteur Js et après « quelques » efforts de disposer d’une console permettant d’exécuter du code. Cependant l’opération n’est pas des plus simples et on préférera généralement utiliser une console intégrée dans les outils Js embarqués par un navigateur moderne (Chrome, IE version récente, Firefox…), ou installer un EDI spécialisé. Il existe également des consoles en mode web (voir les consoles web proposées).

Le JDK lui même embarque un moteur JavaScript Rhino depuis la version 1.6 (fait bien peu connu) ce qui peut avoir pas mal d’applications pratiques.

Consulter le Java Scripting Programmer’s Guide.

Depuis Java 8, Rhino est remplacé par Nashorn, dont vous pouvez lire une introduction intéressante ici.

Les navigateurs

Un navigateur est un logiciel qui a de nombreuses casquettes. Avec l’extension des capacités du HTML dans la version 5, il doit notamment disposer de capacités natives en termes de gestion de flux audio et vidéo.

Mais il y a deux aspects essentiels et primordiaux qui nous intéressent : le moteur de rendu et bien sûr le moteur JavaScript.

Passons brièvement sur le moteur de rendu :

  • il implémente les normes HTML et CSS,
  • il est chargé de parser le code HTML et d’en fabriquer une représentation en mémoire conforme à la spécification DOM,
  • il est chargé d’afficher ce contenu,
  • il est chargé de gérer l’interaction utilisateur (basiquement émettre une requête HTTP en cas de clic sur un lien hypertexte, et plus largement de gérer toutes sortes d’événements).

De même qu’il existe de nombreux moteurs Js, il existe de nombreux moteurs de rendu avec chacun leur niveau de support des normes W3C. La problématique est donc similaire à celle exposée pour les moteurs Js mais ce n’est pas là notre sujet essentiel. Nous citerons tout de même les principaux moteurs.

MoteurEditeurNavigateur
WebkitGoogleChrome
TridentMicrosoftIE
GeckoMozillaFirefox

De la même façon que nous nous intéressons au moteur Js embarqué par les navigateurs afin de déterminer leur support des diverses normes, il serait intéressant d’examiner le support des normes W3C (HTML, CSS,…) par ces différents moteurs de rendu. C’est au-delà de notre propos, mais les développeurs web spécialisés sont parfaitement au fait de ces subtilités et on trouve sans grande difficulté des ressources sur le sujet.

Le moteur JavaScript interagit avec le moteur de rendu : en effet il manipule le DOM pour mettre à jour dynamiquement une page, et il binde des listeners sur les événements utilisateurs détectés par le navigateur. C’est d’ailleurs le navigateur qui lui expose les objets du DOM.

MoteurNavigateurEdition EcmaScript supportée
V8 (Chrome)ChromeECMAScript 5.1
Chakra (Microsoft)Internet Explorer 9+ECMAScript 5.1
SpiderMonkey (Mozilla)FirefoxECMAScript 5.1

Comme on peut le voir, tous les navigateurs modernes implémentent la dernière version de la norme (depuis au moins 2012).

Un test de conformité est disponible ici. Aucun navigateur n’obtient 100 % mais le niveau de défaut est à priori négligeable.

Apprentissage du JavaScript

« Ouverture d’esprit et curiosité : les qualités intrinsèques aux développeurs »

Un point essentiel, nous semble-il, est de faire preuve d’ouverture d’esprit et de curiosité ;  mais n’est ce pas là des qualités intrinsèques aux bons développeurs ?

JavaScript n’est pas Java, c’est un fait. Il ne supporte par la notion de Classe et l’approche de la POO en JavaScript est fort déconcertante au premier abord. Et après ?  Il ouvre par ailleurs bien des perspectives, tant en termes de concepts de programmation fonctionnelle, que de design patterns.

JavaScript comme tout langage a des qualités et des défauts, mais on ne peut nier qu’il est aujourd’hui une brique indispensable pour la réalisation d’applications modernes. Alors certes, il existe des pistes pour contourner la difficulté (taglibs JSP, frameworks JSF[13], GWT[14] et consorts) mais ces solutions ont leurs limites et inconvénients propres.

« Savoir reconnaître les sources dignes de confiance est indispensable
pour tout apprentissage sérieux du JavaScript »

L’apprentissage sérieux du JavaScript implique de disposer des bonnes ressources : les sites qui abordent Js par le petit bout de la lorgnette, avec des tonnes de scripts de qualité diverse (et souvent  mauvaise) foisonnent. Ces sites sont à fuir comme la peste, ils ne feront que renforcer l’impression négative bien ancrée chez de nombreux javaïstes.

Nous vous proposons donc ici deux ressources de référence qui vous permettront de réellement comprendre ce langage :

  • JavaScript : The good parts. Ce livre se trouve en téléchargement libre au format pdf sur Internet. Un petit extrait de l’introduction pour vous donner envie : « With JavaScript; The Good Parts, you’ll discover a beautiful, elegant, lightweight, and highly expressive language that lets vou create effective code ».
  • http://fr.eloquentjavascript.net/ est un site, en français, en lien avec le livre « Eloquent JavaScript, A modern introduction to programming ». Il est un peu plus touffu que le précédent mais son approche nous a semblé excellente. Le site propose également un scrapbook qui permet de saisir et tester en ligne les exemples de code Js.

Nous espérons que cette rapide plongée dans le mystérieux univers des technologies front-end va inspirer le technophile qui sommeille en chaque ingénieur et le pousser à s’intéresser aux technologies front-end, JavaScript en premier lieu.

[1] RIA (Rich Internet Application) une application web qui offre une ergonomie aussi évoluée que celles des applications dîtes « lourdes » c’est-à-dire appuyées sur des toolkits sophistiqués supportés par l’OS et devant être déployées sur le poste client.

[2] Framework Javascript de Google.

[3] http://martinfowler.com/bliki/InversionOfControl.html

[4] RPC : Remote Procedure Call, technique permettant d’invoquer une procédure qui s’exécute dans un espace mémoire distinct (et généralement sur une machine distincte, au travers du réseau). Les exemples sont nombreux : RMI, EJB qui s’appuie sur RMI, SOAP qui s’appuie sur HTTP/XML etc.

[5] En deux mots, un mécanisme de RPC basé sur le protocole HTTP et sur des conventions simples d’utilisation des verbes du protocole et de forme des URIs. Les réponses sont généralement encodées en JSON (JavaScript Notation) qui est un format de sérialisation de données directement exploitable en JavaScript côté client et très largement supporté côté serveur (standard de fait popularisé par le web 2.0).

[6] Bibliothèque de feuilles CSS très évoluées et directement utilisables. Support du Responsive Design inclus. Directement issu des technologies développées par le site Twitter.

[7] Pour faire simple, des outils permettant d’enrichir la syntaxe CSS par une syntaxe étendue et s’appuyant sur une phase de pré-processing qui va lire les fichiers Sass et les convertir en feuilles CSS standards.

[8] Protocole réseau qui permettra l’établissement d’une session permanente entre le client et le serveur (contrairement à HTTP qui est sans état), avec donc un canal de communication permanent et bi-directionnel (permettant donc au serveur de pousser de la donnée au client sans être sollicité).

[9] GIYF, voir http://fr.wikipedia.org/wiki/Corba

[10] Framework Java qui a popularisé l’usage de l’injection de dépendance et grandement simplifié les modèles de programmations d’applications web en java par rapport à JEE (qui a depuis comblé son retard).

[11] Document Object Model, pour faire simple une représentation mémoire, de type graphe, d’une page HTML ou d’un document XML après son parsing.

[12] Framework Js orienté serveur. Il embarque notamment un listener HTTP, comme un Tomcat par exemple, et permet donc de développer des applications web en JavaScript côté serveur (alternative totale à JEE donc).

[13] Les taglibs JSP/JSF permettent la génération de code côté serveur qui embarque du JavaScript pour permettre des comportements sophistiqués côté client et la mise en œuvre d’AJAX sans pour autant devoir maîtriser le JavaScript.
[14] GWT offre un modèle de programmation proche de Swing ; il offre des widgets Java qui sont compilés en JavaScript. Cette plateforme permet donc de développer du RIA sans code de JavaScript.

Directeur Technique

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !