L’article aborde l’importance de l’auto-revue du code front-end pour accélérer le développement tout en améliorant la qualité. L’auteur, initialement novice, a découvert que les corrections suggérées lors des revues de code, bien que perçues comme mineures au début, visaient en réalité à rendre le code plus maintenable et compréhensible pour d’autres développeurs ou pour une réutilisation future. Cette prise de conscience l’a conduit à intégrer une auto-revue minimale dans son processus de développement, consistant à vérifier rapidement les éléments souvent négligés lors d’un développement rapide.
L’auto-revue ne se limite pas à la vérification du bon fonctionnement du code, mais inclut aussi l’examen des situations anormales ou des cas limites. Par exemple, il est crucial de gérer les erreurs d’API, les états vides ou les valeurs indéfinies, plutôt que de se contenter du chemin heureux (happy path). Cette approche permet d’anticiper les problèmes en production et de réduire les risques liés à une maintenance future.
Enfin, l’article souligne l’importance de supprimer le code inutile, comme les variables ou imports inutilisés, ainsi que de repérer les duplications de code. Bien que des outils comme ESLint puissent automatiser une partie de cette vérification, l’auteur insiste sur la nécessité de se poser des questions sur la pertinence et la maintenabilité du code, plutôt que de se contenter de sa fonctionnalité immédiate.
L’article explore l’application des principes du Domain-Driven Design (DDD) pour structurer une architecture front-end plus claire et alignée sur les besoins métiers. L’auteur, Othniel Visky, partage son expérience sur un projet de refonte d’une application de calcul de charge explosive, où le DDD a permis de créer une base de code plus compréhensible et évolutive. Le DDD résout notamment le problème de l’organisation chaotique des composants front-end, souvent classés de manière arbitraire (comme dans Atomic Design), en les regroupant par domaine métier, reflétant ainsi leur fonction réelle.
Le cœur du DDD repose sur deux concepts clés : le modèle (représentation des règles métiers) et le langage ubiquitaire (vocabulaire commun entre développeurs et experts métiers). Ce dernier évite les malentendus en standardisant la terminologie, facilitant la collaboration. Par exemple, dans le projet cité, le DDD a permis de structurer le code autour des concepts spécifiques au calcul de charge explosive, rendant les discussions avec les experts métiers plus fluides et les implémentations plus précises.
Enfin, l’auteur souligne que le DDD ne se limite pas à l’architecture technique : il transforme la façon dont les équipes conçoivent et maintiennent un produit. En adoptant cette approche, les développeurs front-end gagnent en clarté sur les attentes métiers, tandis que les experts non techniques voient leurs besoins mieux traduits en solutions logicielles. Une méthode particulièrement utile pour les applications complexes où la compréhension du domaine est cruciale.
L’article de Josh W. Comeau compare les performances des animations en CSS et en JavaScript, un sujet souvent abordé avec des idées reçues. L’auteur explique que, contrairement aux apparences, les animations JavaScript ne sont pas nécessairement plus lentes, mais leur exécution sur le fil principal (main thread) les rend vulnérables aux blocages causés par d’autres tâches JavaScript. À l’inverse, les animations CSS s’exécutent sur un fil dédié, ce qui les rend plus fluides dans des applications complexes.
L’analyse se concentre sur deux méthodes : les keyframes CSS et une boucle JavaScript utilisant requestAnimationFrame. Bien que le JavaScript moderne soit optimisé pour des calculs rapides, son exécution sur le fil principal le rend sensible aux interruptions, contrairement au CSS qui bénéficie d’un traitement séparé. L’auteur illustre ce point avec une démonstration où des blocages du fil principal perturbent davantage l’animation JavaScript que l’animation CSS.
Enfin, l’article souligne que le choix entre CSS et JavaScript dépend du contexte : le CSS est idéal pour des animations simples et performantes, tandis que le JavaScript offre plus de flexibilité pour des interactions dynamiques ou complexes, malgré les risques de latence liés au fil principal.
Les LiveComponents de Symfony offrent une solution efficace pour créer des interfaces dynamiques sans recourir à des bibliothèques front-end lourdes, en s'appuyant sur des attributs Twig et une stack simple. Leur simplicité d'utilisation, comme l'ajout d'attributs pour des fonctionnalités comme l'édition inline ou le live reload, les rend attractifs pour les développeurs back-end peu enclins au développement front-end. Cependant, leur utilisation intensive révèle des limites, notamment en matière de sérialisation des objets Doctrine complexes, comme les collections ou les relations entre entités.
L'auteur illustre ces limites avec un exemple concret où la sérialisation d'une collection d'entités Loan échoue, obligeant à recourir à des solutions comme l'activation du sérialiseur ou la définition de types concrets. Cette problématique, bien que simplifiée par rapport à une architecture front-end classique, montre que la promesse d'une solution "tout-en-un" s'effrite face à des cas d'usage avancés, comme la gestion de fichiers ou de collections complexes. Les LiveComponents, bien que puissants pour des démonstrations, révèlent des contraintes techniques qui peuvent compliquer leur adoption à grande échelle.
Les menus déroulants (dropdowns) fonctionnent bien jusqu’à ce qu’ils soient placés dans un conteneur scrollable, où ils peuvent être tronqués ou disparaître derrière d’autres éléments. Godstime Aburu explique pourquoi ce problème survient (lié à l’overflow, aux stacking contexts et aux containing blocks) et propose des solutions concrètes pour le résoudre, notamment en évitant les z-index arbitraires. Un article technique essentiel pour les développeurs front-end confrontés à ce bug récurrent.
Tyler Coderre partage sa méthodologie de design structurée en 25 règles clés, fruit de son expérience en UI/UX, design systems et front-end. Il insiste sur l’importance de clarifier l’idée centrale avant toute exécution, d’intégrer les contraintes organisationnelles et de privilégier le prototypage rapide pour tester les comportements plutôt que l’esthétique. Son approche alterne entre livraisons immédiates et fondations durables, tout en soulignant l’équilibre entre processus et intuition. Une lecture pragmatique pour designers et équipes cherchant à optimiser leur workflow.
Cet article présente des astuces pour améliorer l'expérience utilisateur des interfaces. Il aborde des détails comme l'équilibrage du texte avec text-wrap: balance, l'harmonisation des bordures avec des rayons concentriques, l'animation contextuelle des icônes, l'affinage du rendu textuel sur macOS avec antialiased, l'utilisation de chiffres tabulaires pour une largeur uniforme, et l'importance des animations interruptibles pour une interaction fluide. Ces techniques, bien que subtiles, contribuent grandement à la qualité perçue d'une interface.
Tout est dans le titre
Présentation des deux styles possibles de développement Front End d'applications avec Symfony : SPA vs Radical Simplicity
Une grosse liste d'outils
L'auteur montre comment utiliser Testing Library ( https://testing-library.com/ - un ensemble d'utilitaires pour faire des tests unitaires Front End ) avec Twig - dans un article précédent ( https://www.julienpradet.fr/tutoriels/testing-library-comment-rediger-des-tests-en-react/ ) il montrait l'utilisation avec React
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Une introduction aux pipelines d'intégration continue pour le dev front
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre