Retour sur ngEurope

La petite sœur de ngConf a enfin eu lieu en Europe ! Cette conférence s’est déroulée les 22 et 23 octobre derniers à Paris. Pour l’occasion, toute l’Angular core team avait fait le déplacement afin de nous présenter les dernières nouvelles ainsi que les dernières améliorations concernant l’écosystème Angular.
Cette conférence était parfaitement rythmée et proposait différents formats de conférences : des lightning talks présentant diverses librairies, des conférences de 20 minutes et certaines de 40 – 45 minutes visant à présenter des sujets de manière plus détaillée.
L’objet de cet article n’est pas de faire un retour sur tous les talks de ngEurope mais plutôt de revenir sur les principales annonces et sur les talks les plus marquants.

Angular 2.0

C’était sans conteste le sujet que tout le monde attendait ! En effet, après la publication récente de la version 1.3.0 finale, la mystique version 2.0 d’Angular devait se révéler afin de montrer aux différents passionnés présents de quel bois serait faite la mouture d’Angular.
Cette nouvelle version a d’ailleurs fait l’objet d’une énorme activité sur Twitter dont vous avez probablement pu être les témoins. Cette activité s’explique par la franche rupture existante entre la version 1.0 et la version 2.0. Voici quelques éléments en teasing :

• La suppression des contrôleurs
• La supprression des directives
• La suppression des scopes

Mais avant de parler de ces points de manière plus détaillée, Brad Green et Igor Minar ont annoncé dans la Keynote que suite à la livraison de la version 1.3 une majorité de l’Angular core team allait désormais travailler sur la version 2.0.
Cette version 2.0 sera une version toute neuve fraîchement réécrite afin de pouvoir continuer de travailler sur les sujets comme : optimisation de la manipulation du DOM, diminuer la charge du Garbage Collector et fournir des outils d’analyse de performance. Les changements qui vont être amorcés pour la version 2.0 ne sont cependant pas des essais. En effet, la plupart des modifications majeures ont déjà été implémentées et testées dans la version 1.0 d’AngularDart afin de valider leurs comportements.

Alors quel langage ?

Un changement majeur sur lequel il faut insister, selon moi, est que la nouvelle version d’Angular ne sera pas écrite en EcmaScript 5 (JavaScript actuel), mais ne sera pas écrite non plus en EcmaScript 6 (nom de code harmony)… Mais alors quel langage va être utilisé ? Et bien, le langage choisi est dénommé AtScript (*.ats) et a été présenté durant la seconde Keynote par Misko Hevery. Ce langage est une extension du langage TypeScript qui est lui-même une extension d‘EcmaScript 6.
Afin de simplifier le langage AtScript correspond à EcmaScript 5 qui serait étendu avec les éléments suivants :

• Classes (ES6)
• Modules (ES6)
• Types (TypeScript)
• Annotations (AtScript)
• Introspection (AtScript)

Pourquoi utiliser un tel langage? Afin de n’avoir à maintenir qu’une seule et unique version du Framework en AtScript qui pourrait par le biais de compilateur être traduite :

• en ES5 / ES6
• en dart

En effet, l’objectif annoncé est de n’avoir plus qu’une seule base de code à maintenir afin de n’avoir à corriger les problèmes qu’une seule fois et que la correction soit effective aussi bien pour la version JS que pour la version Dart.

Retours sur quelques suppressions

Comme annoncé précédemment, la version 2 d’Angular va supprimer un certain nombre d’éléments fondateurs d’Angular, éléments qui ont déjà été enlevés dans la version 1.0 d’AngularDart, revenons un peu plus en détail sur ces points :

• La suppression des contrôleurs correspond à une volonté de se rapprocher du standard des web-components. Dans ce rapprochement, la notion de contrôleur n’a plus de réelle utilité car celle-ci ferait double emploi avec le contexte du composant. En effet, chaque nouveau composant crée son propre contexte au sein duquel est évaluée les expressions. Ce contexte peut donc exposer un certain nombre de méthodes définissant le comportement du composant d’où la disparition du contrôleur.
• La suppression des scopes se rapproche du point précédant car l’évaluation d’une expression se fait dans le contexte du composant englobant et donc le scope correspondra aux variables disponibles dans ce contexte.
• La suppression des directives n’est pas en réalité une suppression mais plus une scission. Il est aisé de constater que mes deux derniers points ne parlent que deux composants et il y a une raison pour cela, les directives vont désormais être scindées en trois sous-groupes :
  • ComponentDirective correspondant à la notion de web-component et visant à la création de nos propres tags personnalisés. Les ComponentDirectives créent un nouveau contexte dans lequel seront évaluées les expressions, si l’utilisateur veut alors accéder à des variables du contexte parent, il devra nécessairement déclarer explicitement le passage des variables dans ses composants.
  • TemplateDirective dont l’objectif est de fournir des inclusions de template HTML ala ng-include
  • DecoratorDirective dont l’objectif est d’augmenter les possibilités des éléments existants en ajoutant des comportements. Cela correspondrait en version 1.X à une directive présentant un restrict: ‘A’. Ce type de directive ne crée pas de contexte et sera donc évalué dans le contexte du composant englobant.
• La suppression d’angular.module() : cette suppression concorde avec l’ajout dans EcmaScript 6 des modules proposant nativement un chargement asynchrone ainsi qu’une gestion des dépendances cycliques.

Angular 1.3

Durant une présentation dédiée, Brian Ford et Jeff Cross ont eu l’opportunité de présenter la version 1.3 d’Angular. Cette nouvelle version intègre des nouveautés, des optimisations… Un petit tour d’horizon :

• Benchpress : Angular propose désormais un outil permettant de benchmarker ses applications de manière macro afin de pouvoir déterminer la vitesse réelle d’exécution des applications. Le code est bien sûr open source et disponible sur le github
• Améliorations de performance importante : la version 1.3 est 4.4 fois plus rapide sur la manipulation du DOM que la version 1.2 et 3.5 fois plus rapide sur les étapes de $digest.
• introduction d’un mode de production permettant de désactiver des contrôles et améliorant le temps d’exécution de l’application: $compileProvider.debugInfoEnabled(…);
• possibilité de regrouper les $digest dans les cas où les applications manipuleraient de nombreuses requêtes ($http) et recevraient donc de nombreuses requêtes en parallèle : $httpProvider.useApplyAsync(true);
• ajout de la possibilité d’utiliser le one-time binding de manière native. Le concept est simple : le binding reste actif tant que la valeur change entre deux loops de $digest, puis une fois que la valeur est stabilisée le binding est retiré. Cela permet de limiter le nombre de watchers et donc d’améliorer les performances des applications. L’utilisation se fait en préfixant la variable du scope devant être bindée par ::
• Ajout d’un nouveau décorateur ngModelOptions permettant de spécifier le comportement du ngModel. Ce décorateur prend en paramètre un objet JS et permet de configurer des paramètres tels que :
  • debounce – pour indiquer que la variable du scope ne doit être mise à jour qu’après une certaine latence, utile par exemple pour les champs de recherche afin de ne lancer la recherche qu’une fois que l’utilisateur a fini sa saisie
  • updateOn – permet de se hooker sur les évènements afin d’indiquer à Angular de mettre à jour la variable du scope seulement sur certains évènements; par exemple: {updateOn: blur}
  • quelques autres pouvant être retrouvés sur la documentation
• ngMessages une nouvelle directive permettant d’afficher / de cacher des messages suivant l’état d’un objet JS (key/value). Cette directive a été ajoutée afin de permettre de gérer d’une façon plus
  simple et plus ordonnée l’affichage des messages d’erreurs lors de la validation de formulaire. Grâce à cette directive, il est aisé d’indiquer que si un champ est requis alors seul le message associé au validateur required ne sera affiché et non pas le message d’erreur du validateur number par exemple. Il est donc désormais possible d’afficher les messages de validation un à un pour offrir une meilleure expérience utilisateur.
• ngStrictDi est une nouvelle directive pouvant être placée dans le DOM conjointement à ngApp (sur le même élément) et qui va placer l’application en mode strict-di. Par conséquent, au chargement de l’application, si l’une des injections de dépendances ne respecte pas une forme supportant la minification, l’application ne se chargera pas et un message d’erreur sera affiché dans la console. L’intérêt est donc de garantir que lors de la livraison de l’application, cette dernière ne sera pas impactée par l’étape de minification.
• ngAria est un module visant à fournir et améliorer le support pour les Accessible Rich Internet Applications en rajoutant de nouveaux tags permettant une meilleure interprétation de l’application par des outils d’accessibilités (tel que talkback sous Android).

Ionic framework

Durant cette présentation de 20 minutes, Andrew Joslin a absolument bluffé les 700 personnes de l’audience et cela à bien des égards : maîtrise de Vim, rapidité de code, capacité à live-coder une application complète sans effet démo … Cependant, ce que je retiendrais c’est qu’Ionic permet aujourd’hui au développeur web de développer, avec Cordova, des applications packagées comme des applications natives et proposant des UI d’applications natives le tout en un temps record.
En effet, sur les 20 minutes de sa présentation Andy avait récupéré les données d’un serveur, affiché des listes customisées avec des images et du texte, géré une navigation entre les deux écrans développés lors du live-coding, ajouté la possibilité de supprimer un élément avec la demande d’une confirmation utilisateur. Tout cela, sans avoir à manipuler n fichiers de configuration XML mais seulement du HTML et du JavaScript. Ionic est selon moi sur le point de réussir son objectif de permettre de coder en web des applications de qualité quasi-native.

Can we learn from Architect ?

Ce talk était dans une certaine mesure un talk technique mais durant cette prestation, Vojta Jina nous a proposé un talk que l’on pourrait retrouver à l’affiche d’une conférence TED dans la catégorie “inspirational” que je recommande à tout le monde de regarder sur la chaîne Youtube de ngEurope.
Partant du constat que les étapes de build échouent assez régulièrement dans le développement logiciel, il se demande si nous ne devrions pas nous inspirer des architectes ayant construit les pyramides il y a quarante siècles. En constatant que les matériaux utilisés ne s’altèrent pas et permettent donc à des constructions millénaires d’être encore debout, il a présenté pourquoi selon lui, les développeurs JavaScript devrait favoriser les “Pure functions”, i.e. les fonctions ne présentant pas d’effets de bord, ainsi que les variables immuables car ces derniers garantissent que pour des inputs donnés les outputs seront les mêmes.

Angular from Scratch : une proposition risquée ?

Matthieu Lux, consultant formateur à Zenika Lyon, a eu l’audace de proposer un sujet visant à démystifier AngularJS en live-codant une version simplifiée et tout cela en moins de 45 minutes. Audace aussi partagée par les organisateurs qui ont osé proposer un tel sujet devant le(s) fondateur(s) du framework.
Ce qui apparaissait donc comme un pari risqué s’est, en réalité, avéré être une superbe idée, entre autre saluée sur Twitter, dont la présentation et l’exécution, sans effet démo, ont permis de vulgariser le fonctionnement interne du framework : $digest / $apply / directives (ng-model & ng-bind).