Des conseils pour offrir la meilleure expérience possible lorsqu'on utilise des polices de caractères personnalisées.
- Utilisez des petites polices (20-40Kb)
- Servez les vous même (pitié pas Google Font..)
- Ne proposez pas de polices intermédiaires (
font-display: block;) - Indiquez au browser de pré-charger les polices (
<link rel="preload" ...>)
Le but est de charger les polices au plus vite car aucun texte ne s'affiche avant et c'est volontaire pour éviter le layour shift (des éléments qui changent de place quand la police est chargée si elle ne fait pas exactement la même taille que la temporaire)
Un excellent article qui explique le fonctionnement de la Composition API de Vue 3 et les raisons de ce changement de paradigme.
On passe d'une déclaration de composants avec des classes à un paradigme fonctionnel.
Cela permet entre autre:
- un meilleur partage de la logique
- des types plus précis
- une meilleure structure de code
Un guide alternative pour comprendre comment fonctionne les flexbox en CSS.
Un article d'investigation puis de correction de problèmes de performances sur un grosse application React utilisant les Hooks.
Une librairie pour dessiner des graphiques qui reste assez méconnue malgré ses features et ses performances.
Contrairement à beaucoup de lib (ApexChart, Chart.js), Vizzu utilise des canvas pour dessiner les graphs.
Il y a aussi de très belles animations natives :-)
De super conseils pour écrire de bons messages d'erreurs à destination des utilisateurs finaux.
Un bon message d'erreur doit:
- expliquer ce qu'il s'est passé (
Unable to connect your account) - rassurer l'utilisateur (
Your changes were saved) - aider à réparer le problème (
Please try connecting again) - fournir une aide externe (
If the issue keep happening, contact support)
L'auteur d'une lib de CSS in JS pour React explique les désavantages de ce fonctionnement.
Les deux principaux désavantages sont le poids supplémentaire des libs nécessaires et l'impact non négligeable sur les performances de rendu.
Après la lib offre quand même une DX très confortable donc à chacun de faire ses compromis.
(Merci Ludo pour le partage)
Un article de fond sur l'évolution du développement frontend.
L'article commence par un historique du frontend:
- Pages dynamique CGI : PHP
- AJAX : JQuery, Flash
- Split frontend/backend : Backbone
- Two way binding : Angular
- JAMStack: Gatbsy, Next
- Components: React, Vue
Le frontend s'est tellement complexifié qu'on atteint des limites en terme de coût de manipulation du DOM (résolu par le Virtual DOM) mais également en terme de traffic réseau et du rendering des éléments d'une mage qui peuvent se bloquer entre eux (charger du CSS par exemple)
L'auteur revient sur les différentes innovations mises en place chez Facebook avec React:
- Optimizing runtime costs: Virtual DOM, CSS avec Stylex
- Optimizing the network: Relay, GraphQL
- Optimizing Javascript bundles: Tree shaking (Facebook utilisent carrément une IA !)
Les différents framework du marché sont passé en revue: React, Svelte, Vue, Solid, Astro, Marko, Fresh, Next, Remix et Qwik
Pour moi le plus important est cette phrase de l'auteur
It’s a good reminder that if you’re on the bleeding edge, you are usually the one bleeding. Defaulting to “boring” technologies, ones you are familiar with, and being a late adopter is often a great choice.
La morale c'est qu'il faut choisir son framework en fonction de ses besoins actuels et faire très attention aux choix techniques pour des projets long termes.
Un nouveau (LOL encore) framework Javascript frontend.
Ils se focalisent sur la vitesse lors du premier affichage de l'application en supprimant la phase d'hydratation.
Lorsque l'on télécharge une page web en React par exemple, le navigateur doit interpréter le HTML et le JS, puis:
- re-créer tous les listeners sur les noeuds du DOM
- re-créer l'arbre de composant représentant l'application
- restorer l'état (state) de l'application
Qwik permet de sauter ces étapes avec plusieurs astuces, par exemple pour les listeners, ils sont directement dans le HTML:
<button on:click="./chunk.js#handler_symbol">click me</button>Sinon la syntax est très similaire à celle de React avec du JSX.
L'article parle des inconvénients de React. (c'est l'auteur de React Admin)
Pour l'auteur, les formulaires sont compliqués à écrire correctement à cause d'un trop haut niveau d'abstraction.
De son point de vue, les hooks ont amené un niveau supplémentaire de complexité sur des parties métiers qui était déjà gérées correctement par Redux.
Il continue sur d'autres points en donnant toujours des exemples voir des comparaisons avec d'autres framework.
Je savais pas qu'il existe des fonts dont on peut faire varier les couleurs en CSS!
Un REX du gouvernement Britannique qui a enlevé JQuery de ses pages (32Kb compressé).
Ils ont observé une amélioration de 17% des performances en moyenne!
Par contre, ils n'ont pas utilisé d'autre lib JS à la place non plus :-)
Un article présentant un framework pour micro-frontend avec tout le tooling pour se simplifier la vie.
Attention car même avec Piral, gérer un ensemble de micro-frontend est beaucoup plus compliqué.
Une telle décision d'architecture doit se reposer uniquement sur un besoin d'organisation d'une grande équipe en plus petites équipes focalisée sur un domaine de l'application.
Plus d'info sur les micro-frontend https://links.aschen.tech/shaare/AuKMeA
Une bonne introduction aux micro-frontends.
Finalement ça répond au même besoin que les micro-services, pouvoir scale son produit en plusieurs équipes qui peuvent travailler de manière indépendante sur des parties du produit.
Les micro-frontends sont au frontend ce que les micro-services sont au backend.
A utiliser avec parcimonie donc
C'est vrai que Redux n'est pas forcément nécessaire pour démarrer une app React, tout comme Vuex ne l'est pas pour une app Vue.
Comme pour chaque outil, il faut se demander si l'on en a vraiment besoin et surtout si ça répond à un problème.
Chaque outil rajoute une couche de complexité cognitive supplémentaire qui ralentit et complique le développement.
Une autre lib qui propose de faire du frontend avec un virtual DOM.
Ils annoncent des performances bien plus élevées que React tout en supportant une partie de l'API comme useState, useEffect etc
Je suis toujours sceptique lorsque je vois les couches d'abstractions s'empilées côté frontend.
Une super présentation sur le fonctionnement et l'utilisation de Rust + WebAssembly pour faire une application frontend avec le framework Yew.
L'auteur utilise le framework frontend Yew en Rust.
Comme il le dit à la fin, pour l'instant c'est encore très expérimental et les performances ne sont pas au rendez-vous.
D'ailleurs c'est assez peu probable de pouvoir battre les performances du JS natif en terme de manipulation de DOM.
Aussi, ce genre d'application hybride (2 langages) aura quasiment toujours des performances inférieurs à cause de l'overhead du boxing / unboxing
Une alternative aux appli Web classiques qui sont entièrement en Javascript et reçoivent du JSON.
Ici le concept c'est plutôt d'envoyer du html pour remplacer à la volée certaines parties de la page.
Du coup le rendu se fait côté serveur et le frontend est beaucoup moins complexe.
C'est Basecamp qui pousse ça (la boîte à l'origine de Ruby on Rails)
Un autre article qui analyse les faiblesses des Hooks de React.
Une source de bug très courante est l'oubli d'une propriété dans le tableau de dépendances avec useEffect.
Le respect de la Règle des Hooks qui force le nombre de Hooks d'un composant à toujours être le même impose des architectures de composants contre nature.
L'auteur continue son raisonnement en avançant notamment que depuis les Hooks, React peut être utilisé comme un framework alors que ce n'était pas vraiment prévu, ce qui cause pleins de problèmes d'architectures.
Un article qui va dans le sens inverse de la tendance actuelle autour de l'utilisation des Hooks dans React.
L'auteur disserte sur le non respect des principes SOLID par les Hooks et sur les problèmes de dettes technique que cela créé.
Les Hooks sont vraiment quelque chose d'étrange, ils ne respectent pas la programmation fonctionnelle, ni la programmation objet.
Ce sont juste des helpers pour écrire et lire de la donnée dans une sorte de gros objet global, l'avantage avec le système de props étant qu'on n'a pas besoin de les passer entre chaque composant.