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
Tout est dans le titre