Frameworks front-end: solutions ou gros problèmes?

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

Le développement Web d'aujourd'hui a beaucoup évolué depuis les années 90; nous pouvons 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ù être un développeur Web frontal consistait à ouvrir le Bloc-notes, à écrire quelques lignes de code, à le vérifier dans le navigateur et à le télécharger dans un dossier FTP.

Développement web front-end du passé

Je dois commencer par dire une évidence: le monde n'est pas comme il était il y a 10 ans. (Choquant, je sais). La seule chose qui reste constante est le changement. Dans le passé, nous avions très peu de navigateurs, mais il y avait de nombreux problèmes de compatibilité. Ces jours-ci, vous ne voyez pas beaucoup de choses comme «mieux vues dans Chrome 43.4.1», mais à l'époque, c'était assez courant. Nous avons plus de navigateurs maintenant, mais moins de problèmes de compatibilité. Parce que? Du à jQuery . jQuery a satisfait le besoin d'une bibliothèque commune et standard qui vous permettrait d'écrire du code JavaScript qui manipule le DOM sans avoir à vous soucier de la façon dont il fonctionnerait dans chaque navigateur et dans chaque version de chaque navigateur, un véritable cauchemar dans les années 2000

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

Pourquoi les gens portent des montures

Dans le développement Web comme dans la vie, avoir une solution rapide est toujours utile. Avez-vous déjà créé un routeur en JavaScript? Pourquoi passer par le processus d'apprentissage douloureux lorsque 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 qui utilise déjà un certain framework. Regardons les choses en face - les cadres existent pour une raison. S'il n'y avait aucun avantage pour eux, personne ne les utiliserait.

Alors, quels sont certains des avantages et des propriétés uniques de l'utilisation d'un cadre 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 cadre que vous utilisez - en fait, il ne sait probablement même pas ce que vous utilisez - il se soucie simplement d'obtenir des résultats, et le plus vite sera le mieux. Les frameworks établis vous permettent de créer un sentiment instantané de progrès dès le début, auquel le client aspire 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 prendre plus de projets.

Tout est dans la communauté. Lors du choix d'un cadre, c'est un point très important: qui vous aidera lorsque vous serez coincé dans un problème? Vous et moi savons que cela va arriver à un moment donné. Cela arrivera à un point où vous devrez faire quelque chose que le cadre n'était pas destiné à faire, ou que le cadre n'a jamais été conçu pour vous donner accès, il est donc essentiel d'avoir une communauté derrière vous. Le développement - surtout indépendant - peut être difficile, puisque vous êtes plongé dans un monde virtuel, et si vous êtes le seul développeur web front-end en équipe, cela signifie que vous êtes le seul à avoir l'expérience et l'expertise pour trouver une solution. Mais si le framework frontal que vous utilisez a une forte compatibilité, il y aura quelqu'un à l'autre bout du monde qui aura fait face au même problème et pourra vous aider.

Les standards sont magnifiques. Avez-vous déjà réalisé que lorsque vous regardez un ancien extrait de votre propre code, vous pouvez facilement le parcourir? Ou du moins, plus facilement que du 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 lever à une certaine heure et à mettre nos clés au même endroit tous les jours. Et en fait, si nous changeons nos routines tous les jours, la vie serait beaucoup plus difficile juste à cause de l'idée de comment faire les choses. Avez-vous déjà perdu vos clés parce que vous les avez mises dans un endroit différent de la normale? Les normes facilitent la vie. Lorsque vous travaillez 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 réfléchir et coder d'une manière spécifique. Vous n'avez pas besoin de perdre de temps à créer une norme avec votre équipe; vous pouvez simplement suivre comment les choses se font dans le cadre. Cela facilite la collaboration. Il est plus facile de rechercher une fonction lorsque vous savez que la fonction doit être dans un certain fichier car elle est construite pour ajouter une route dans un SPA, et dans son cadre toutes les routes sont placées dans un fichier avec ce nom. Des personnes de différents niveaux de compétence peuvent travailler ensemble si vous avez ce niveau de standardisation, car si les codeurs avancés savent pourquoi les choses sont faites de cette façon, même les plus jeunes développeurs peuvent suivre la norme elle-même.

Lorsque les cadres échouent

Il y a quelques années, dire quelque chose comme «Je n'utilise pas de cadres, je n'en vois aucun avantage réel», amènerait des gens avec des torches et des épingles à cheveux à leur porte. Mais de nos jours, de plus en plus de gens se demandent: «Pourquoi utiliser un cadre? Ai-je vraiment besoin d'eux? Est-ce difficile de coder sans eux? '

comment compiler en c++

Certainement, je suis l'un d'entre 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». J'ai développé en JavaScript pendant des années et en ActionScript avant cela. Il codait 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 des nombreux à ne jamais penser au codage sans pour autant Marcos, permettez-moi de vous montrer quelques raisons pour lesquelles vous avez peut-être des difficultés.

'Une taille unique' est un mensonge. Pouvez-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 plugins 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 trouverez utiles.

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

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

Cet enchevêtrement de mauvaises herbes que vous traversez devient de plus en plus épineux. Avez-vous déjà été dans une situation où vous utilisez votre infrastructure et essayez d'y ajouter une bibliothèque, pour constater 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 ensemble que pour écrire le code vous-même. Et comme les frameworks et bibliothèques que vous utilisez sont souvent basés sur 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ù ils sont impossibles à gérer si je veux que le projet continue de croître

Rester au courant des Jones est une chose. Avez-vous déjà travaillé sur un projet dans AngularJS pour découvrir que vous aviez besoin de quelque chose qui n'apparaissait pas avant la sortie d'Angular 4? Saviez-vous qu'Angular 5 est sorti? C'est un autre gros problème; même si vous vous en tenez à un seul framework frontal, lorsqu'un remake majeur se produit, les choses peuvent tellement changer que le code sur lequel 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.

Se tenir au courant des dernières versions d'un framework est un défi, mais sur la même note, 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 sont sortis 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 semble long. Si vous créez des sites Web, ils ont probablement complètement changé d'esthétique et de fonction. Si vous créez une application, parier sur le mauvais cadre peut 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 de code que vous utiliserez à l'avenir, même si elle n'est liée que de manière périphérique. Disons que vous allez créer une plate-forme comme YouTube et que vous souhaitez utiliser le cadre X. Il se peut qu'il y ait un moment où, même si cela semble ridicule de nos jours, vous décidez d'utiliser Flash pour les vidéos, car c'est ce qui est livré avec le 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 que le code est utilisé de cette façon partout. Y a-t-il une alternative? Oui, mais qui l'utilise? Ce n'est pas toujours mauvais, mais si vous avez besoin de faire des animations complexes, vous n'aurez peut-être besoin que d'une seule image pour animer et non de l'ensemble 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 réalisé dans vanilla JS avec document.getElementById ('id_of_node'). AppendChild (node);.

comment effectuer des tests unitaires

Le mal est le mal, 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 cadres. Lorsque vous voyez comment la plupart du code fonctionne lorsque vous essayez d'ajouter quelque chose au DOM, vous trouverez beaucoup de HTML injecté par la propriété .innerHTML. Nous semblons tous convenir que eval c'est mauvais pour exécuter du code javascript, mais je veux mettre .innerHTML à l'honneur ici. Lorsque le code HTML est injecté sous forme de chaîne simple, toutes les références que vous avez pu avoir à l'un des nœuds que vous avez créés sont perdues. Il est vrai que vous pouvez les récupérer en utilisant getElementsByClassName ou en leur attribuant un id, mais ce n'est pas pratique. En essayant de changer la valeur de l'un des nœuds, vous vous retrouverez à renvoyer tout le HTML.

C'est bien lorsque vous commencez à coder. Vous pouvez faire beaucoup de choses simples facilement sans beaucoup d'expérience. Le problème vient de la complexité des sites Web modernes, qui ont tendance à ressembler davantage à des applications; Cela signifie que nous devons constamment changer les valeurs de nos nœuds, ce qui est une opération coûteuse si vous le faites en reconnectant toute la structure via .innerHTML. React résout ce problème efficacement via un DOM ombré, et Angular le résout en liant 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 créés et en enregistrant ceux qui seront réutilisés ou mis à jour dans les variables.

Il y a aussi autres raisons rester à l'écart de .innerHTML en général.

Les plus grands mythes sur le codage sans cadre

Le temps, c'est de l'argent. Oui, je ramène ce concept d'avant. Beaucoup de gens pensent que s'ils arrêtent d'utiliser un framework Web populaire, nous passerons instantanément à l'Internet des années 90, quand c'était la balise préférée de tout le monde, les GIF pivotés sur un site Geocities étaient modernes et énervés, Alta Vista était le choix pour Les recherches sur le Web et les compteurs de résultats étaient omniprésents.

Avec les frameworks Web, vos premières lignes de code semblent faire de grands progrès en gagnant du 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 construit, comment intégrer des bibliothèques et les faire jouer correctement avec le framework, et découvrir que le code que vous avez construit en suivant les normes du framework ne fonctionne pas. du tout et maintenant vous devez le saisir à nouveau. Lorsque vous faites des choses sans cadre, vous commencez 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'avez pas un accès instantané à des centaines de films que vous souhaitez regarder, mais vous n'avez pas non plus à dépenser d'argent pour des milliers d'autres films que vous n'envisageriez jamais de télécharger depuis le magasin. Vous pouvez écrire ce dont vous avez besoin.

L'intermédiaire est-il utile? Bien 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 à vous adapter aux exigences d'un framework. Il peut sembler que vous écrivez plus de code avec du JavaScript pur parce que la façon dont vous créez 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, plutôt que d'appeler une seule ligne de code dans JSX. Mais si vous comparez le code en utilisant une bibliothèque comme jQuery ou React, vanilla JS peut être assez similaire en longueur. Parfois, il est plus long, mais parfois aussi plus court.

Il n'est pas nécessaire de réinventer la roue. Le mantra des professeurs d'informatique partout. Et c'est vrai - cela ne veut pas dire spécifiquement des cadres. 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 du code d'autres. Plus il est petit, plus il est facile de le modifier ou de l'ajuster selon les besoins, c'est donc utile 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 naviguer dans 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 ce n'est pas du tout vrai; Je travaille actuellement 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. Avec ou sans cadres, je passe par des étapes très similaires et rencontre des problèmes très similaires. La différence est négligeable. Cependant, sans cadres, mon code complet est plus petit et plus facile à gérer.

JE VEUX DES TESTS

Bon. Arrêtons de parler de théorie et passons à un exemple du monde réel. Il y a quelques jours, j'avais besoin d'afficher une liste de marques avec des logos pour un magasin. Le code initial utilisait jQuery, mais avait un problème où, lors du chargement dans Mozilla, il afficherait une icône d'image cassée pour les marques qui n'avaient pas encore de logos chargés. Nous ne pouvons pas donner à la boutique un aspect inachevé simplement parce que la société X n'a ​​pas encore terminé son travail, mais la fonctionnalité devait être activée.

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

Sans entrer 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 créons. Bien qu'il existe des solutions qui n'impliquent pas de changer le code, profitons de cette opportunité 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

Le code jQuery original faisait six lignes, tandis que la solution JS de vanilla en prenait douze. Pour résoudre le problème, le fait de masquer chaque image jusqu'à ce qu'elle soit chargée prend deux fois plus de temps à encoder. Alors regardons l'alternative. Peut-il aussi être résolu dans jQuery? Jetez un coup d'oeil:

img_out += ' '; 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 jQuery et vanilla, mais dans jQuery, vous pouvez voir que la ligne img_out il se développe rapidement et est très complexe, au point où vous devez faire une pause et réfléchir attentivement à ce que vous faites. Coder le DOM directement en utilisant les fonctions de nœud pour ajouter des attributs, des fonctions, etc. pourrait être plus long, mais chaque ligne a une signification plus claire et plus précise, ce qui la rend plus facile à lire et à maintenir à l'avenir.

Jetons un coup d'œil à React:

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

Cette version est clairement sous-optimale. Le code n'est pas plus court qu'en vanilla, et nous ne sommes pas encore au point de résoudre le problème et de cacher 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ù la vanille JS peut être plus courte 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 pourrait être la meilleure solution pour certains de vos projets et un cauchemar pour d'autres. Comme pour tous les outils, la clé est d'apprendre non seulement comment l'utiliser, mais quand et quels sont les avantages et les inconvénients de son utilisation. Le codage en JavaScript pur est comme n'importe quel framework: il faut du temps pour le maîtriser avant de se sentir à l'aise pour 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 pour beaucoup plus longtemps, jusqu'à ce qu'il soit complètement hors de propos 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'une langue à une autre que vous ne le pouvez avec un cadre donné vers un autre. Le temps et les efforts sont à 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 qu'il peut prendre avec vous pour le prochain défi sont des facteurs très importants à considérer.