Frameworks frontaux : solutions ou problèmes gonflés ?

Les frameworks frontaux modernes vous obligent à télécharger un environnement de développement, avec des dépendances, et à compiler votre code avant même d'essayer de le visualiser sur votre navigateur. Est-ce une bonne chose ? Le problème est-il que nous construisons des sites plus complexes, ou est-ce que les frameworks sont complexes en eux-mêmes, introduisant un niveau de complexité inutile ?

Le développement Web d'aujourd'hui a beaucoup évolué depuis les années 90 ; nous sommes capables de créer des expériences complètes qui sont très proches de ce que n'importe quelle application native peut faire, et le processus de développement a également changé. Il est révolu le temps où, pour être un développeur Web frontal, il suffisait d'ouvrir le Bloc-notes, de taper quelques lignes de code, de le vérifier sur le navigateur et de le télécharger dans un dossier FTP.

Le développement Web frontal du passé

Je dois commencer par dire l'évidence : le monde n'est plus comme il y a 10 ans. (Choquant, je sais.) La seule chose qui reste constante est le changement. À l'époque, nous avions très peu de navigateurs, mais il y avait beaucoup de problèmes de compatibilité. Aujourd'hui, vous ne voyez pas beaucoup de choses comme "mieux vu sur Chrome 43.4.1", mais à l'époque, c'était assez courant. Nous avons plus de navigateurs maintenant, mais moins de problèmes de compatibilité. Pourquoi? A cause de jQuery . jQuery répondait au besoin d'avoir une bibliothèque standard et commune qui vous permettait d'écrire du code JavaScript qui manipule le DOM sans avoir à vous soucier de la façon dont il allait s'exécuter sur chaque navigateur et sur chaque version de chaque navigateur - un véritable cauchemar dans les années 2000 .

Les navigateurs modernes peuvent manipuler le DOM en tant que norme, de sorte que le besoin d'une telle bibliothèque a considérablement diminué ces dernières années. jQuery n'est plus nécessaire , mais nous pouvons toujours trouver un certain nombre de plugins extrêmement utiles qui en dépendent. En d'autres termes, les frameworks Web ne sont peut-être pas nécessaires, mais ils sont toujours suffisamment utiles pour être populaires et largement utilisés. Il s'agit d'un trait commun à la plupart des frameworks Web populaires, de React, Angular, Vue et Ember aux modèles de style et de formatage comme Bootstrap.

Pourquoi les gens utilisent les frameworks

Dans le développement web comme dans la vie, avoir une solution rapide est toujours pratique. Avez-vous déjà créé un routeur en JavaScript ? Pourquoi passer par le douloureux processus d'apprentissage alors que vous pouvez installer npm un framework frontal pour surmonter le problème ? Le temps est un luxe lorsque le client veut que les choses soient faites hier ou que vous héritez du code d'un autre développeur conçu pour un framework particulier, ou si vous vous intégrez à une équipe utilisant déjà un framework donné. Avouons-le, les cadres existent pour une raison. S'il n'y avait aucun avantage pour eux, personne ne les utiliserait.

Quels sont donc certains des avantages et des propriétés uniques de l'utilisation d'un framework de développement Web ?

Le temps, c'est de l'argent. Lorsque vous développez un projet et que le client ne se soucie pas du framework que vous utilisez - en fait, il n'est probablement même pas conscient de ce que vous utilisez - il ne se soucie que d'obtenir des résultats, et le plus vite sera le mieux. Les frameworks établis vous permettent de créer un sentiment de progrès instantané dès le début, dont le client a besoin dès le premier jour. De plus, plus vous développez rapidement, plus vous gagnez d'argent, car le temps libéré par le framework peut être redirigé vers plus projets.

Tout tourne autour de la communauté. Lors du choix d'un cadre, c'est un point très important : qui va vous aider lorsque vous êtes bloqué sur un problème ? Toi et moi savons tous les deux que ça va arriver à un moment donné. Vous arriverez à un endroit où vous devrez faire quelque chose que le framework n'était pas destiné à faire, ou auquel le framework n'a jamais été conçu pour vous donner accès, il est donc essentiel d'avoir une communauté qui vous soutient. Le développement, en particulier en freelance, peut être difficile, car vous êtes immergé dans un monde virtuel, et si vous êtes le seul développeur Web front-end dans une équipe, cela signifie que vous êtes le seul à avoir l'expérience et l'expertise nécessaires pour trouver un Solution. Mais si le framework frontal que vous utilisez dispose d'un support solide, il y aura quelqu'un à l'autre bout du monde qui a rencontré le même problème et qui pourra peut-être vous aider.

Les normes sont belles. Avez-vous déjà remarqué que, lorsque vous examinez un ancien morceau de votre propre code, vous pouvez le parcourir assez facilement ? Ou du moins, plus facilement qu'un bout de code écrit par quelqu'un d'autre ? Vous pensez d'une certaine manière, et vous avez votre propre façon de nommer les choses et d'organiser le code. C'est une norme. Nous les suivons tous, même s'ils ne sont que pour nous-mêmes. Nous avons tendance à manger des choses similaires au petit-déjeuner, à nous réveiller à une certaine heure et à placer nos clés au même endroit tous les jours. Et en effet, si nous changions nos routines tous les jours, la vie serait beaucoup plus difficile juste à cause de la surcharge de savoir comment faire les choses. Avez-vous déjà perdu vos clés parce que vous les avez placées dans un endroit différent de la normale ? Les normes facilitent la vie. Lorsque l'on travaille au sein d'une équipe ou d'une communauté de développeurs, ils deviennent absolument indispensables.

Les frameworks fournissent une norme à partir du moment où vous les installez, vous guidant pour penser et coder d'une manière spécifique. Vous n'avez pas besoin de passer du temps à créer une norme avec votre équipe ; vous pouvez simplement suivre comment les choses sont faites dans le cadre. Cela facilite le travail en commun. Il est plus facile de rechercher une fonction lorsque vous savez que la fonction doit se trouver dans un certain fichier car elle est conçue pour ajouter une route dans un SPA, et dans votre framework, toutes les routes sont placées dans un fichier portant ce nom. Des personnes ayant des niveaux de compétence différents peuvent travailler ensemble si vous avez ce niveau de standardisation, car même si les codeurs avancés savent pourquoi les choses sont faites de cette façon, même les développeurs juniors peuvent suivre la norme elle-même.

Quand les frameworks échouent

Il y a quelques années, dire quelque chose comme "Je n'utilise pas de frameworks, je n'y vois aucun avantage réel" amènerait des gens avec des torches et des fourches à votre porte. Mais aujourd'hui, de plus en plus de gens se demandent : « Pourquoi devrais-je utiliser un framework ? En ai-je vraiment besoin ? Est-ce si difficile de coder sans eux ? »

Je suis certainement l'un d'eux - je n'ai jamais été fan d'un framework spécifique et j'ai codé sans eux pendant toute ma carrière. Si j'ai le choix en la matière, mon choix est toujours "Non, merci". Je développe en JavaScript depuis des années et en ActionScript avant cela. Je codais en Flash alors que la plupart des gens le considéraient déjà comme mort. (Je sais, je sais… mais je faisais beaucoup d'animations, et l'animation en HTML simple est difficile.) Donc, si vous êtes l'un de ceux qui ne pensent jamais à coder sans frameworks, laissez-moi vous montrer quelques raisons pour lesquelles vous pourriez être en difficulté.

"Taille unique" est un mensonge. Pourriez-vous imaginer écrire un seul logiciel capable de faire tout ce que vous avez accompli dans votre carrière ? C'est l'un des principaux problèmes des frameworks de développement Web. Votre projet a des besoins très spécifiques, que nous avons tendance à résoudre en ajoutant des bibliothèques, des plugins ou des add-ons pour étendre la portée du framework. Aucun framework n'offre 100% de ce dont vous avez besoin, et aucun framework n'est composé à 100% de choses que vous allez trouver utiles.

Avoir trop de code que vous n'utilisez pas peut entraîner un décalage de temps de chargement pour votre site, ce qui devient plus important avec chaque utilisateur supplémentaire. Un autre problème est que l'état d'esprit «taille unique» se traduit par un code inefficace. Prenez, par exemple, $('sku-product').html('SKU 909090'); , qui est du code jQuery qui, à la fin, nous savons tous qu'il sera traduit en quelque chose comme document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

Ce genre de différence sur une seule ligne peut sembler sans importance, mais changer le contenu d'un élément spécifique de la page est précisément la vertu de React. Maintenant, React passe par le processus de création d'une représentation du DOM et d'analyse des différences dans ce que vous essayez de rendre. Ne serait-il pas plus simple de cibler uniquement le contenu que vous souhaitez modifier dès le départ ?

Cet enchevêtrement de mauvaises herbes dans lequel vous marchez fait pousser des épines. Avez-vous déjà été dans la situation où vous utilisez votre framework et essayez d'y ajouter une bibliothèque, juste pour vous rendre compte que la version de la bibliothèque dont vous avez besoin ne fonctionne pas bien avec la version du framework que vous utilisez ? Parfois, il faut plus d'efforts pour faire fonctionner deux morceaux de code que pour écrire le code vous-même. Et puisque les frameworks et les bibliothèques que vous utilisez sont souvent construits sur d'autres frameworks et bibliothèques qui peuvent avoir des incompatibilités cachées que vous ne pouvez même pas anticiper, le problème peut devenir exponentiellement plus complexe, atteignant un point où il est impossible de les gérer si vous veulent que le projet continue de grandir.

Suivre les Jones est une chose. Avez-vous déjà travaillé sur un projet dans AngularJS pour découvrir que vous avez besoin de quelque chose qui n'est pas apparu avant la sortie d'Angular 4 ? Saviez-vous même que Angular 5 est sorti ? C'est un autre énorme problème; même si vous vous en tenez à un seul framework frontal, lorsqu'une nouvelle version majeure arrive, les choses peuvent tellement changer que le code que vous avez travaillé si dur ne fonctionnera même pas sur la nouvelle version. Cela peut entraîner n'importe quoi, des petites modifications ennuyeuses qui doivent être apportées à de nombreux fichiers à une réécriture complète de votre code.

Suivre les dernières versions d'un framework est difficile, mais dans le même ordre d'idées, d'autres frameworks souffrent lorsque les mises à jour s'arrêtent complètement et ne peuvent pas suivre le reste de la technologie. En 2010, AngularJS et Backbone ont été publiés pour la première fois. Aujourd'hui, Angular en est à sa cinquième version majeure, et Backbone est complètement hors des projecteurs. Sept ans me paraissent longs. Si vous construisez des sites Web, ils ont probablement complètement changé d'esthétique et de fonction. Si vous construisez une application, parier sur le mauvais cadre pourrait mettre l'entreprise dans une situation difficile et coûteuse plus tard, lorsque les choses doivent être réécrites.

Quand tout ce que vous avez est un marteau, tout ressemble à un clou. Si vous avez fréquemment utilisé des frameworks de développement Web, cela vous est probablement arrivé, où une seule base de code définit la forme du code que vous utiliserez à l'avenir, même s'il n'est lié que de manière périphérique. Disons que vous allez créer une plate-forme comme YouTube et que vous souhaitez utiliser Framework X. Il peut y avoir un moment où, même si cela semble ridicule de nos jours, vous décidez d'utiliser Flash pour les vidéos parce que c'est ce qui vient intégré au cadre.

Les cadres ont des opinions, et ils sont forts ; React, par exemple, vous oblige à utiliser JSX d'une manière spécifique. Vous pouvez voir du code utilisé de cette manière partout. Existe-t-il une alternative ? Oui. Mais qui l'utilise ? Ce n'est pas toujours une mauvaise chose, mais si vous avez besoin d'effectuer des animations complexes, vous n'aurez peut-être besoin que d'un cadre pour l'animation et non de l'intégralité de React. J'ai vu des gens faire des choses folles comme ajouter jQuery à une page juste pour ajouter un nœud à un élément, quelque chose qui pourrait être accompli dans vanilla JS avec document.getElementById('id_of_node').appendChild(node); .

Eval est mauvais, mais .innerHTML est machiavélique

Je veux prendre le temps d'explorer ce point séparément car je pense que c'est l'une des raisons pour lesquelles plus de gens ne codent pas sans frameworks. Lorsque vous voyez comment la plupart des codes fonctionnent lorsque vous essayez d'ajouter quelque chose au DOM, vous trouverez un tas de HTML injecté par la propriété .innerHTML . Nous semblons tous d'accord sur le fait que eval est mauvais pour l'exécution de code JavaScript, mais je veux mettre .innerHTML à l'honneur ici. Lorsque vous injectez du code HTML sous forme de chaîne simple, vous perdez toute référence que vous auriez pu avoir à l'un des nœuds que vous avez créés. Il est vrai que vous pourriez les récupérer en utilisant getElementsByClassName ou en leur attribuant un id , mais c'est loin d'être pratique. Lorsque vous essayez de modifier la valeur de l'un des nœuds, vous vous retrouvez à restituer l'intégralité du code HTML.

C'est bien quand vous commencez à coder. Vous pouvez faire beaucoup de choses simples facilement sans trop d'expérience. Le problème survient avec la complexité des sites Web modernes, qui ont tendance à ressembler davantage à des applications. Cela signifie que nous devons constamment modifier les valeurs de nos nœuds, ce qui est une opération coûteuse si vous le faites en rattachant toute la structure. via .innerHTML . React résout ce problème efficacement via un DOM fantôme, et Angular le résout en utilisant la liaison comme moyen simple de modifier une valeur affichée sur une page. Cependant, il peut également être résolu assez facilement en gardant une trace des nœuds que vous créez et en sauvegardant ceux qui seront réutilisés ou mis à jour dans des variables. Il existe également d'autres raisons de rester à l'écart de .innerHTML en général.

Les plus grands mythes sur le codage sans framework

Le temps, c'est de l'argent. Oui, je ramène ce concept d'avant. Beaucoup de gens pensent que s'ils cessent d'utiliser un framework Web populaire, nous passerons instantanément à l'Internet des années 90, quand <marquee> était le tag préféré de tout le monde, les GIF en rotation sur un site Geocities étaient branchés et audacieux, Alta Vista était le go- pour les recherches sur le Web, et les compteurs de visites étaient omniprésents.

Avec les frameworks Web, vos premières lignes de code semblent faire beaucoup de progrès en termes de gain de temps, mais à un moment donné, les gains se transforment en pertes. Vous passez votre temps à lire comment faire en sorte que le framework fasse des choses pour lesquelles il n'est pas conçu, comment intégrer des bibliothèques et les rendre agréables avec le framework, et découvrir que le code que vous avez construit en suivant les normes du framework ne va pas fonctionner du tout et maintenant vous devez le réécrire. Lorsque vous faites des choses sans cadre, vous démarrez plus lentement, mais vous progressez régulièrement. En fin de compte, tout dépend de l'endroit où vous voulez que la partie facile soit. Cela ne fera pas beaucoup de différence dans le temps total.

Mon code sera plus long que la Grande Muraille. Écrire sans cadre, c'est comme acheter un film au lieu de s'abonner à un service de streaming. Vous n'obtenez pas un accès instantané à des centaines de films que vous souhaitez regarder, mais vous n'avez pas non plus à dépenser de l'argent pour des milliers d'autres films que vous n'envisageriez même pas de télécharger depuis le magasin. Vous pouvez simplement écrire ce dont vous avez besoin.

L'intermédiaire est-il utile ? Sûr. Mais ce n'est généralement pas nécessaire . Chaque ligne de code que vous écrivez a plus de sens, car vous n'avez pas besoin de vous adapter aux exigences d'un framework. Vous pouvez avoir l'impression d'écrire plus de code avec du JavaScript pur, car la façon de créer les éléments DOM prend des lignes pour créer un élément, l'attacher au DOM et peut-être ajouter une classe pour le style, au lieu d'appeler une seule ligne de code dans JSX. Mais si vous comparez du code à l'aide d'une bibliothèque comme jQuery ou React, vanilla JS peut être assez similaire en longueur. Parfois c'est plus long, mais parfois c'est aussi plus court.

Il n'est pas nécessaire de réinventer la roue. Le mantra des professeurs d'informatique du monde entier. Et c'est vrai, cela ne signifie pas nécessairement les frameworks en particulier. L'envoi d'une requête Ajax pour charger ou enregistrer des données est une exigence dans presque toutes les applications Web, par exemple, mais ne pas avoir de framework ne signifie pas que vous devez réécrire le code à chaque fois. Vous pouvez créer votre propre bibliothèque ou base de code, ou vous pouvez extraire le code des autres. Plus il est petit, plus il est facile de le modifier ou de l'ajuster selon les besoins, il est donc pratique lorsque vous avez besoin de quelque chose de spécifique pour un projet. Il est plus facile de modifier 100 à 200 lignes de code que de parcourir la montagne de fichiers qu'une bibliothèque ou un framework tiers peut contenir.

Cela ne fonctionnera que pour les petits projets. C'est un mythe très courant, mais pas vrai du tout ; actuellement, je travaille sur un système complet pour gérer tous les aspects d'une entreprise en ligne en un seul endroit, y compris un module qui ressemble à Google Drive. Que ce soit avec des frameworks ou sans eux, je passe par des étapes très similaires et rencontre des problèmes très similaires. La différence est négligeable. Cependant, sans frameworks, tout mon code est plus petit et plus facilement gérable.

JE VEUX UNE PREUVE

D'accord. Arrêtons de parler de théorie et passons à un exemple concret. Il y a quelques jours, j'avais besoin de montrer une liste de marques avec des logos pour un magasin. Le code initial utilisait jQuery, mais il y avait un problème où, lors du chargement dans Mozilla, il affichait une icône d'image cassée pour les marques qui n'avaient pas encore de logos téléchargés. Nous ne pouvons pas laisser le magasin paraître inachevé simplement parce que la société X n'a ​​pas encore terminé ses travaux, mais la fonctionnalité devait être mise en ligne.

Le code suivant utilise l'équivalent jQuery de .innerHTML :

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

Sans aller trop loin dans les avantages et les inconvénients de jQuery, le problème ici est que nous n'avons aucune référence aux images que nous avons créées. Bien qu'il existe des solutions qui n'impliquent pas de modifier le code, profitons de cette occasion pour voir comment cela peut être fait sans aucune bibliothèque :

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

Le code jQuery d'origine comptait six lignes, tandis que la solution JS vanille en prenait douze. Pour résoudre le problème, cacher chaque image jusqu'à ce qu'elle soit chargée prend deux fois plus de temps à coder. Voyons donc l'alternative. Peut-il être résolu dans jQuery aussi? Vérifiez-le:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

Avec quelques lignes de code supplémentaires, il n'y a plus qu'une différence de trois lignes entre le jQuery et le vanilla, mais sur le jQuery, vous pouvez voir que la ligne img_out devient rapidement très complexe, au point où vous devez faire une pause et réfléchissez bien à ce que vous faites. Le codage direct du DOM en utilisant des fonctions de nœud pour ajouter des attributs, des fonctions, etc. peut être plus long, mais chaque ligne a une signification plus claire et plus précise, ce qui facilite la lecture et la maintenance à l'avenir.

Jetons un coup d'œil à React :

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

Cette version est clairement sous-optimale. Le code n'est pas plus court qu'il ne l'est dans vanilla, et nous n'avons même pas encore atteint le point de résoudre le problème et de masquer les liens jusqu'à ce que l'image qu'ils contiennent soit chargée.

Pour chaque exemple, les résultats seront différents. Parfois, jQuery sera plus court. Parfois, React gagnera. Il y a des moments où vanilla JS peut être plus court que les deux. Dans tous les cas, le but ici n'était pas de prouver que l'un était intrinsèquement supérieur à l'autre, mais de démontrer qu'il n'y a pas de différence significative entre l'utilisation de vanilla JS et l'utilisation d'un framework en ce qui concerne la longueur du code.

Conclusion

Comme pour presque tous les problèmes de la vie réelle, rien n'est noir ou blanc. Le codage sans frameworks de développement Web peut être la meilleure solution pour certains de vos projets et un cauchemar pour d'autres. Comme pour tout outil, la clé est d'apprendre non seulement comment l'utiliser, mais aussi quand et quels peuvent être les avantages et les inconvénients de son utilisation. Le codage en JavaScript pur est comme avec n'importe quel framework - le maîtriser prend du temps avant de se sentir à l'aise de l'utiliser.

Mais la principale différence, du moins pour moi, est que les frameworks vont et viennent, et même si un framework est populaire depuis longtemps, il peut changer radicalement d'une version à l'autre. Le JavaScript pur sera une option pendant beaucoup plus longtemps, jusqu'à ce qu'il cesse d'être totalement pertinent et qu'un autre langage émerge. Même dans ce cas, il y aura plus de concepts et de stratégies que vous pourrez migrer directement d'un langage à un autre que vous ne le pourrez avec un framework donné vers un autre. Le temps et les efforts étant à peu près équivalents lorsqu'il s'agit d'un seul projet, la réduction de la dépréciation des connaissances et les leçons que vous pouvez emporter avec vous pour le prochain défi sont des facteurs très importants à considérer.