# Retour d’expérience : React Native

par Mathieu Sanchez

Une fois n’est pas coutume, nous vous invitons à lire cet article sur notre blog. Nous détaillons notre expérience de développement mobile avec React Native. Nos collègues apportent également leurs regards sur cette bibliothèque : avantages et inconvénients, tant d’un point de vue technique que du point de vue de la gestion de projets.

# Mars rime avec JDK (si si !)

par Thomas Broyer

Qui dit mars dit nouvelle version du JDK. Au menu de cette version 18 :

  • le « default charset » vaut UTF-8 par défaut, au lieu d’être dépendant du système (fini donc les -Dfile.encoding=UTF-8, c’est désormais le comportement par défaut)
  • jwebserver, parce qu’on n’avait pas encore assez d’alternatives entre python -m http.server, npx http-server ou npx serve, php -S 127.0.0.1:8000, ruby -run -ehttpd ., j’en passe…
  • modifications à la marge de la preview « pattern matching for switch »
  • SPI (comprendre: pluggabilité) pour la résolution DNS
  • la finalisation des objets est dépréciée « for removal » (comprendre: ça fonctionne toujours comme avant, mais une prochaine version du JDK pourra la supprimer complètement, donc merci de ne plus l’utiliser)

Très très peu de changement du côté des APIs, les principales étant liées aux modifications du “default charset”.

# React 18 RC

par Mathieu Petit

Après 1 an et demi de covid d’attente depuis la version 17, la version 18 de React arrive en release candidate, avec des nouveautés pour les designers avec startTransition et useTransition pour différer des actions moins urgentes, et quelques changements d’API notamment sur la fonction render() pour mieux gérer la création de la base de l’application. Le plus intéressant sur cette mise à jour est peut-être l’auto batching quand on met à jour plusieurs hooks à la suite.

Et pour finir, le meilleur pour la fin, l’abandon du support d’Internet Explorer. 

# Web Framework : ou pas !

par Thomas Broyer

Jérôme Beau, un développeur français (cocorico ! 🇫🇷🐓), explique dans cet article les problèmes qu’apportent les frameworks (adhérence, spécialisation des compétences, contraintes, entre autres) et comment s’en passer. Si l’article est ici centré sur le développement frontend, il n’est pas sans rappeler la présentation “Web Framework : ou pas !” que j’avais donnée il y a bientôt 6 ans 👴 à Bourgogne Numérique (désormais BFC Numérique) sur notre approche côté backend, privilégiant l’application de patterns d’architecture à des frameworks (la vidéo n’est malheureusement plus en ligne).