Flash Player et sa technologie sous‐jacente, tous deux développés par la société Adobe, n’en finissent plus d’agoniser. Sommes‐nous en train d’assister aux derniers soubresauts ?

• Les principaux navigateurs Web réduisent la voilure de l’extension Flash Player, principalement pour des problèmes récurrents de sécurité, de performance et de consommation excessive de batterie. L’introduction d’un blob propriétaire dans les navigateurs est peut‐être aussi une raison pour certains projets, bien que ce point soit rarement mis en avant officiellement.
• Certaines plates‐formes grand public ne permettent plus l’installation de Flash, parfois depuis des années (Apple iPhone, Microsoft Edge…).
• L’absence de Flash sur un ordinateur personnel est de moins en moins un problème pour un usage, même intensif, du Web et force est de constater que l’on peut désormais surfer des mois sans Flash sans même s’en rendre compte.
• Les plates‐formes publicitaires (Google en tête) vont commencer à refuser les publicités Flash.
• Les clones de Flashplayer et les convertisseurs de Flash vers HTML5 sont abandonnés.

Dans la première partie de cette dépêche, nous présenterons Flash et reviendrons plus en détail sur son histoire, son apogée, ses concurrents, puis sa chute vers l’oubli.
La seconde partie nous permettra de détailler les technologies du moment, afin de donner quelques pointeurs aux développeurs et designers Web souhaitant se mettre au goût du jour.

Divulgation prématurée : ladite relève se constitue essentiellement de standards, promus par l’ensemble des acteurs du Web !

Dans cette dépêche, nous allons faire un tour d’horizon de différentes manières de communiquer avec un serveur depuis une application Web, avec un petit peu d’histoire, avant de rentrer plus profondément dans le fonctionnement des WebSockets, que nous allons démystifier. Nous digresserons ensuite à propos de la gestion (problématique) des requêtes longues et de HTTP 2 avec Apache, et nous discuterons d’une manière de limiter la casse. La dépêche contient quelques morceaux raisonnables mais l’absurdité est latente.

Supposons que nous ayons une application Web qui a besoin de recevoir des évènements du serveur pour voir si quelque chose s’est passé. À tout hasard, un jeu de société en ligne. Ce jeu a besoin d’envoyer les coups des joueurs et joueuses, et de recevoir les coups des autres.

Le serveur ne peut pas contacter le navigateur. Celui-ci est peut-être derrière un pare-feu, et de toute façon il n’y a pas de méthode pour cela. Le modèle du web, c’est une requête HTTP de la part du navigateur, et le serveur sert cette requête. Et puis, à la base, une requête = un chargement de page.

Mais des techniques sont apparues pour abuser de ce modèle, puis les standards se sont mis à intégrer des méthodes pour mener ces abus en toute sérénité.

HTTP est devenu au cours des dernières années le protocole à tout faire. Au départ prévu pour servir de l'information structurée par lien hypertexte, il est aujourd'hui utilisé pour tout et n'importe quoi. Cette évolution ne va pas sans poser de problèmes. C'est pourquoi sous l'égide de l'IETF un groupe de travail httpbis s'est mis en place.

Une nouvelle mouture du protocole tarte à la crèmeHTTP est donc en route. Faisons un petit tour de son histoire et des projets en cours, avant d'écouter ce qu'à a nous en dire Willy Tarreau qui s'est particulièrement investi dans le groupe de travail httpbis.

NdM : Merci à Nÿco, Florent Zara, patrick_g, Raoul Volfoni, baud123, warwick, Nils Ratusznik, NeoX, zebra3 et Benoît pour leur contributions à cette dépêche.

Un internaute peut penser que sa navigation sur le Web est noyée dans la masse, et que personne ne s’intéresse à la pister, puisqu’elle n’a pas d’importance particulière. C’est le genre de réponse que l’on peut entendre autour de soi quand on tente de sensibiliser au pistage. Ces assertions ne sont malheureusement pas valables. Bien au contraire, le comportement des internautes intéresse beaucoup les grandes sociétés : beaucoup fondent leur modèle économique^W de fonctionnement dessus, pour refourguer de la publicité au passage qui est leur vrai client payant (vu que c’est gratuit en utilisateur, tu es le produit :/).

À partir des données recueillies, des techniques de manipulation sont appliquées aux internautes comme le datamining, le neuromarketing, le biais cognitif, etc. Ces techniques ont atteint une telle maturité et efficacité qu’il est impossible de ne pas en être victime. Il ne se passe pas une semaine sans que de nouveaux articles paraissent sur de nouvelles techniques. Même être conscient de l’existence de ces biais ne permet pas de s’en protéger directement. Tout cela est l’objet d’une marchandisation monstre dans lequel nous sommes tous plus ou moins victimes. Cet article vise à sensibiliser le lecteur et à proposer des solutions efficaces afin qu’il puisse préserver sa vie privée, son autonomie, son libre arbitre, sa liberté et son indépendance, ou simplement ne pas se faire polluer de pub clignotant à foison sur chaque page consultée.

Après plus d’un an d’attente, 12 versions bêta, et 2 versions candidates, Firefox 4 est enfin sorti ce 22 mars. Les principales nouveautés sont Gecko 2.0 (le moteur de rendu), un moteur JavaScript plus rapide comprenant JägerMonkey, un compilateur JIT (en plus de TraceMonkey, l’optimiseur de boucles présent dans Firefox 3.6), ainsi que l’accélération 3D matérielle et une interface utilisateur revue.

Cette sortie marque aussi une volonté de changement dans les cycles de sortie, en voulant les rendre plus courts. Il faudra voir si ce vœu est respecté. Le protocole Websocket est le grand absent de cette version ; il a été désactivé car, comme les sockets Flash et Java, les websockets peuvent simuler du HTTP et ainsi empoisonner le cache de certains serveurs mandataires (proxies) configurés pour intercepter les requêtes HTTP sans la collaboration des clients.

Pour rappel, Firefox est disponible sous les licences GPL 2, LGPL 2.1 et MPL 1.1.

Merci à esa, Chimrod, Obsidian, ymorin, gnumdk et barmic pour leur aide lors de la rédaction.

La version 7.0 de PHP a été annoncée ce jeudi 3 décembre 2015. Elle améliore très significativement les performances, ajoute de nouvelles fonctionnalités et fait un ménage conséquent. Le pari d'une modernisation complète de ce langage phare du développement web est-il réussi après deux années complètes de développement ? Début de réponse dans cette dépêche.

Les applications Web actuelles tendent à réaliser une grande part des traitements en frontal (front‐end), c’est‐à‐dire du côté client, et à réduire au maximum la partie côté serveur (back‐end). Un exemple classique est l’application mono‐page (Single‐Page Application), où la gestion de l’interface et des données est réalisée principalement côté client avec, quand c’est nécessaire, des requêtes serveurs (AJAX, WebSockets…). Pour implémenter ce genre d’applications, on utilise généralement un cadriciel frontal comme AngularJS, Vue.js, React/Redux… Ces cadriciels proposent une architecture de base (MVC, flux…) qui permet d’implémenter facilement une application classique de présentation et de manipulation de données.

L’objectif de cet article est de comparer quelques technologies pour réaliser une application un peu plus interactive : une application de dessin basique. Les technologies considérées ici sont JavaScript (sans bibliothèque), Haskell Miso (cadriciel frontal), C++ Wt (cadriciel fullstack basé widgets) et WebAssembly.

Servo, le moteur de rendu de page web moderne, parallèle et sûr développé en langage Rust, continue d’avancer à grands pas !

Rappel ou information, Servo, publié sous licence MPL 2.0, est développé sur OS X, GNU/Linux, Android, et Firefox OS.

IE6 est mort. Bon débarras. Malheureusement, il y a webkit pour lui succéder. Non pas que webkit soit mauvais, bien au contraire il est très bon, en plus il est libre...

Mais la pratique consistant à faire des tests de User Agent est encore, hélas, très répandue. Il faut cesser cela. Ajoutez à cela l'utilisation massive des sélecteurs CSS préfixés par -webkit-*, comme les préfixes -moz-*, -o-* et -ms-*. Cela n'est pas prêt de disparaître. C'est même sur le point de se généraliser. Ceux-ci sont pourtant bel et bien documentés comme à destination de tests. Cela est bien évidemment à proscrire.

Le problème se pose massivement sur les navigateurs mobiles, où webkit domine très largement, car il est le navigateur par défaut des appareils iOS et Android. Daniel Glazman, co-chairman du CSS Working Group, a donc lancé un appel, avec l'appui du CSS Working Group.

Développeurs web de tous pays, unissez-vous : ne reproduisez pas les erreurs du passé !

MyPhotoShare est un générateur de site Web statique de galerie de médias (licence GPLv3), à partir d’une arborescence de répertoires contenant des photos et des vidéos. Donc vous prenez ce gros répertoire où vous accumulez toutes ces photos ou vidéos depuis tant d’années, vous exécutez l’indexeur de MyPhotoShare en le pointant vers ce répertoire, et celui-ci vous construit un site Web statique avec lequel vous pouvez montrer vos photos au reste de l’univers…

Mais attention, site Web statique ne signifie pas fonctions limitées ! En effet, MyPhotoShare propose plusieurs fonctions de navigation ou de recherche de vos médias, par mot clé ou par date, par localisation géographique sur une carte. Les métadonnées associées aux médias, soit dans les images JPEG soit dans des fichiers album.ini externes, facilitent la classification ou l’affichage de descriptions. Enfin, des extensions basées sur des réseaux neuronaux permettent d’ajouter l’identification automatique des personnes ou des scènes.

De nouvelles fonctions sont ajoutées très fréquemment à MyPhotoShare qui en est rendu actuellement à la version 5.3.10. Bien que MyPhotoShare soit peu connu, le principal développeur est très dynamique et fait évoluer rapidement l’application ou corrige les bogues qui lui sont remontés. Nous allons vous présenter ce qui différencie MyPhotoShare des autres applications de galerie.

Il y a bien longtemps qu’une nouvelle version de PHP n’avait pas été commentée ici. En fait, depuis la sortie de la version 7.0 qui s’est faite dans la douleur après l’abandon de la version 6. Le langage sort désormais avec une nouvelle version chaque fin d’année. La rétrocompatibilité est un point qui n’est pas négligé d’une version à l’autre, d’où une évolution plutôt lente.
La majorité des logiciels peut migrer sans trop d’appréhension. Depuis plusieurs versions, l’amélioration des performances est un point essentiel du fait de la concurrence avec HHVM, développé par Facebook. Au final, cette version, qui est la dernière de la branche 7, apporte un système de type plus fort, plus de performance et fait en sorte de diminuer le code cérémonial, aka boilerplate.

Après un an et trois mois d’attente, voici enfin la nouvelle version de Movim. Avant de rentrer dans le vif du sujet, quelques rappels concernant le projet.

L’architecture de Movim est unique en son genre, c’est à la fois un client XMPP pouvant gérer plusieurs sessions simultanées mais également une application web déployable sur un serveur et accessible au sein des navigateurs et sur les mobiles.

Même s’il est défini en tant que réseau social, il faut plutôt le voir comme un nouvel outil, mêlant fonctionnalités sociales et de messagerie instantanée, le tout reposant sur le standard de messagerie XMPP.

À vrai dire Movim n’est pas vraiment un réseau en lui-même (par rapport à Facebook, Diaspora ou WhatsApp). L’un des buts du projet est, au contraire, de démontrer qu’il est parfaitement possible d’utiliser un protocole unique de communication créant par lui-même un réseau de communication, tout en laissant le choix aux utilisateurs et administrateurs d’utiliser les outils (clients ou serveurs) qu’ils souhaitent pour accéder à celui-ci.

Même si le numéro de version n’est pas majeur, la 0.9 du projet est un véritable bond en avant, tant sur les plans architecturaux, fonctionnels que visuels. Le cœur du projet a atteint sa maturité et permet désormais aux contributeurs de développer et compléter rapidement les fonctionnalités manquantes.