# Les floats et leurs problèmes
par Xavier Calland
Qui n’a jamais eu un problème avec des calculs sur des données de type float ? Le net regorge d’exemples de cas tordus ou du moins pour lesquels le résultat obtenu n’est pas celui auquel on s’attend (un exemple bien connu « 0.1 + 0.2 » ne donne pas « 0.3 » mais « 0.30000000000000004 »)
L’excellente Julia Evans nous propose un article pour mieux comprendre le fonctionnement des nombres à virgule flottant, qui, s’ils ne donnent pas toujours le résultat attendu, suivent un fonctionnement bien défini, la norme IEEE 754. L’article présente également un certain nombre de problèmes inhérents à ce format de données.
Cela m’a rappelé la conférence « Entiers, virgules flottantes ou représentations exotiques » donnée par Olivier Poncet et Fabien Trégan Entiers lors du Devoxx 2022.
# Détecter les cas de N+1 requêtes avec jOOQ
par Xavier Calland
Les cas d’exécution de N+1 requêtes SQL pour récupérer N données depuis une base de données sont des problèmes que l’on retrouve assez régulièrement dans les applications.
Il s’agit simplement de cas où on va exécuter :
- 1 requête récupérant une liste de N enregistrements parents (par exemple les commandes d’un client)
- N requêtes pour charger les données enfants des N parents (par exemple les produits de chacune des commandes)
là où une seule requête peut être exécutée pour charger l’ensemble des données souhaitées.
Cela se traduit souvent par des problèmes de performance visibles tardivement car nécessitant des volumes de données importants (comme un environnement de production).
Lukas Eder nous explique comment jOOQ peut nous aider à identifier ces problèmes de conception en phase de développement via l’utilisation du « repeated statements diagnostic » qui s’occupe d’identifier les requêtes exécutées de manière répétée.
À noter que jOOQ propose d’autres diagnostiques pour nous aider à mieux gérer l’accès aux données.
# Drama sur les réseaux [#architecture #web #react]
par Thomas Broyer
Guillermo Rauch, créateur de Next.js et fondateur de Vercel, a mis le feu aux poudres en janvier en tweetant que “les SPAs étaient un phénomène à taux d’intérêt nul”, Next.js ne sachant aujourd’hui toujours faire que des SPAs (Single Page Applications) même pour un site statique, les React Server Components annoncés il y a deux ans et censés changer la donne n’étant toujours pas prêts (d’ailleurs, Shopify qui avait beaucoup misé dessus pour son framework Hydrogen a finalement racheté l’entreprise Remix et son framework éponyme qui utilise une toute autre approche).
La guéguerre a fait rage pendant quelques semaines entre les défenseurs inconditionnels des SPAs (essentiellement ceux qui ont tout misé dessus, à commencer par les entreprises maintenant des frameworks tels que Next.js ou Remix), et ceux qui dénoncent leurs problèmes et leur utilisation abusive depuis près d’une dizaine d’années, certains se rappelant que le même Guillermo Rauch disait en 2013 que “les Single-Page, Javascript-driven apps sont le futur”.
La polémique s’est étendue plus largement à tout l’écosystème React et plus particulièrement l’équipe projet React à Facebook, rendue responsable de la prolifération des SPA et de React (et d’autres pratiques problématiques en terme de performance telles que CSS-in-JS) par sa communication biaisée (voire mensongère selon certains) portée par la force de frappe de Facebook, et des comportements pour le moins problématiques (harcèlement, pressions via la hiérarchie, etc.) allant pour certaines victimes jusqu’à des formes de burnout et le besoin de quitter le développement web, au moins pour quelques temps.
Un long commentaire de Dan Abramov (de l’équipe React à Facebook) n’a fait que jeter de l’eau sur le feu : il y dit que Create-React-App, l’outil développé et promu par React/Facebook pour “bien commencer” avec React, ne met finalement pas en avant les bonnes pratiques (mais sans jamais réellement admettre une erreur de leur part) notamment pour des “sites de contenu” (y compris les sites de e-commerce ; par opposition à des “applications”), pour lesquels l’équipe React aurait toujours encouragé l’utilisation de frameworks React supportant le rendu côté serveur, alors même qu’aucune solution n’a jamais réellement existé sans refaire ce même rendu, en doublon, côté client (c’est vrai pour Gatsby, Next.js, Remix, etc. on se rappellera que Cdiscount s’est battu avec ce problème qui plombait leurs performances). On notera aussi que jamais le principe des SPA (qui n’implique pas un rendu côté client) n’est remis en question par Dan Abramov (qu’il voit comme “la première optimisation intéressante”), bien au contraire.
Il y aurait bien trop de liens à ajouter ici, dont de nombreux articles de blogs, mais pour terminer sur une note moins négative, je ressortirai deux articles plus anciens bien plus mesurés sur les SPAs : “SPAs: theory versus practice” par Nolan Lawson en juin dernier, et “Application Holotypes: A Guide to Architecture Decisions” par Jason Miller (à qui on doit Preact et le terme “island architecture”) il y a 4 ans. D’autres développeurs en ont profité également pour rappeler leur penchant pour le développement JS sans outil de build, et les tests sans framework tiers.
Le choix d’une architecture SPA ou MPA dépend des besoins et des contraintes des utilisateurs avant tout, en fonction du site ou de l’application qu’on développe (et de la durée des sessions utilisateurs). Le boom récent des frameworks “HTML-first” ajoute une nouvelle corde à notre arc et pourrait durablement changer nos pratiques.
# Safari 16.4 beta 1
par Thomas Broyer
Apple a annoncé la première version beta de Safari 16.4, qui sera probablement la plus importante release de Safari depuis l’avènement de l’iPhone il y a 15 ans ! La liste des nouveautés et correctifs est longue comme le bras et contient notamment :
- le support des notifications push sur iOS et iPadOS qu’on n’osait plus espérer (même si Safari sur macOS l’avait vu arriver en septembre dernier), près de 8 ans après que Google et Firefox ont supporté la fonctionnalité (Apple l’ajoute uniquement pour les sites ajoutés sur l’écran d’accueil cependant, et sur macOS on se rappellera qu’il faut obligatoirement la version Ventura)
- la possibilité pour d’autres navigateurs sur iOS et iPadOS (qui, on le rappelle, sont obligés de n’être que des wrappers autour d’une version de Safari au rabais) d’ajouter des sites sur l’écran d’accueil
- le support de la Badging API pour ajouter un indicateur sur l’icône d’un site ajouté sur l’écran d’accueil (présence d’une notification, ou nombre de message nons lus par exemple)
- le support des import maps qui permettent notamment le développement sans système de build (les import maps permettant au navigateur de transformer les imports de modules NPM en imports d’URLs, vers ces mêmes fichiers préalablement installés dans node_modules ou chargés depuis un CDN comme unpkg.com ou esm.sh) et/ou des optimisations en production en tirant partie du cache HTTP lors de mises à jour
- de nombreuses améliorations concernant les web components, dont le Declarative Shadow DOM (sur lequel Apple devient leader, après des années à avoir freiné les comités de standardisation) et les Form-Associated Custom Elements
- de nombreuses améliorations CSS dont le CSS Nesting (à nouveau, Apple devance ses concurrents sur ce point), et le CSS Typed Object Model pour son intégration avec JavaScript
- le support de l’entête HTTP Clear-Site-Data
- l’extension du support AVIF à macOS Monterey et macOS Big Sur (auparavant limité à macOS Ventura)
Même si le monde du développement web se réjouit à l’unanimité, on ne pourra s’empêcher de noter que ces premiers points sont très probablement une première réponse aux différentes enquêtes en cours et lois dans diverses juridictions concernant l’abus de position dominante d’Apple sur iOS, notamment poussées par l’Open Web Advocacy, et dont on avait parlé en novembre dernier concernant le Digital Markets Act de l’Union Européenne (à ce sujet, Google et Mozilla se préparent d’ores et déjà à la fin du monopole de Safari sur iOS et iPadOS). Une première réponse donc, certes, mais également une forme d’aveu qu’Apple a peur de la concurrence, et qu’il reste encore du chemin à parcourir.
Laisser un commentaire