La discussion des résultats de l'année dans le frontend est soudainement devenue le sujet de discussion . J'ajouterai mon opinion et je serai heureux d'entendre l'opinion des autres.
Il me semble qu'il est logique de parler de ce qui se passe sur le web moderne, est perçu de l'extérieur et de l'intérieur est complètement différent. Oui, et "à l'intérieur" a plusieurs niveaux. Le point de vue «ils compliquent à nouveau la mise en page» est tout à fait correct d'une part et erroné et dépravé de l'autre, mais le point de vue «ne nous empêche pas de construire des abstractions» est également inefficace.
Lorsque quelqu'un se plaint que le Web moderne est devenu trop compliqué, chaque fois que je veux rappeler à cette personne que ce Web moderne fait confiance à son argent dans les banques en ligne et les formulaires d'achat, la correspondance personnelle dans les réseaux sociaux et les versions Web des messageries instantanées, et des fichiers personnels dans les nuages. Et très probablement, il veut vraiment que le processus de développement de ces systèmes soit complexe, difficile, mais fiable et ne tombe pas en panne.
source d'image
Sous le frontend moderne et ses amis, ils comprennent maintenant beaucoup plus que ce qu'il semble de l'extérieur. Il s'agit de sites Web classiques et de SPA, ainsi que d'applications sur l'électron et d'applications mobiles sur cordova, NativeScript, React Native et même sur Flutter. Il s'agit d'une infrastructure complexe avec des CDN, des services géo-décentralisés, des chatbots sur JS et même des outils de machine learning pour optimiser l'assemblage et même la génération de mises en page .
Et sur le Web lui-même, des solutions monstrueusement complexes apparaissent qui auparavant pouvaient fonctionner exclusivement en mode bureau. J'ai moi-même eu il y a quelques années pour aborder le développement d'un navigateur de génome à part entière dans le navigateur - j'étais engagé à fournir des performances et 60FPS, ce qui était un problème assez important mais résolu. Il y a même 5 ans, personne ne pouvait penser que le navigateur du génome ne pouvait pas être installé sur un ordinateur puissant, et cette solution a permis aux médecins et aux chercheurs de travailler avec le génome même à partir d'une tablette ou d'un ordinateur portable léger.
Pourquoi?
À l'heure actuelle, le bundle HTML + CSS + JS est l'un des plus puissants en termes de création d'interfaces - non seulement en raison de ses capacités, mais aussi du nombre de solutions construites sur celui-ci - frameworks CSS, bibliothèques de composants visuels, interfaces avec un grand nombre de services et SAAS . En termes d'efficacité dans les heures de développement pour le public potentiel et l'accessibilité, les technologies Web sont en avance sur les solutions mobiles et de bureau. Et maintenant, il s'est divisé en trois domaines:
- Développement de sites entièrement statiques et quasi statiques avec un contenu partiellement dynamique (galeries, popups, etc.)
- Développement d'applications web "classiques" sur des frameworks serveurs (django, rails)
- Développement client web
Et chacun d'eux a une spécificité complètement différente.
Le développement de JS a été vraiment douloureux, alors des solutions ont commencé à apparaître qui ont résolu cette douleur.
Si vous les regardez, vous pouvez voir quelque chose de très intéressant: d'abord, des solutions comme jQuery et CoffeeScript ont commencé à apparaître, réduisant la redondance et la verbosité du langage. Mais ils se sont rapidement évanouis et à leur place sont venus des outils qui ont permis de réutiliser le code aussi efficacement que possible, de détecter statiquement les erreurs et de construire des abstractions efficaces, "cachant" des niveaux de complexité individuels derrière des interfaces simples et bien décrites.
GraphQL est apparu, ce qui résout les problèmes de complexité de description, de documentation et de maintenance de REST. TypeScript et Flow sont apparus, ce qui a résolu les problèmes de manque de frappe. De nouvelles entités linguistiques sont apparues qui vous permettent de travailler efficacement avec des opérations asynchrones, des classes et des flux de données. WebAssembly est apparu, vous permettant de réutiliser le code d'autres langues et de le faire rapidement.
Toutes ces solutions visent la même chose: la réutilisation du code et le potentiel de constitution d'équipes «plates». Ils résolvent le problème afin de prendre le code de quelqu'un d'autre et de commencer à l'utiliser.
C'est la preuve évidente que le web évolue vers le travail en grandes équipes, il est devenu une plateforme de solutions "adultes".
Une série d'événements qui se sont produits plus loin est devenue une preuve encore plus claire: React Native, NativeScript, Dart + Flutter et d'autres solutions pour réutiliser le code sur les plates-formes natives sont apparus. C'est un point très important: en raison du manque de capacité à utiliser d'autres langues sur le Web, les entreprises ont commencé à affiner leurs processus à la recherche d'une "solution miracle" qui leur permettrait de réduire en aucun cas les petits coûts de développement et le temps nécessaire pour offrir de nouvelles fonctionnalités à tous les clients. Il est important que tout projet soit rapide et des spécialistes de haut niveau ont commencé à s'unir à la recherche de l'opportunité de travailler efficacement sur JS.
Soit dit en passant, pour la même raison, les moteurs de modèle ont commencé à mourir partiellement: l'utilisation d'une sémantique supplémentaire s'est avérée moins efficace que l'utilisation de HTML familier avec de petites extensions en JS (Angular, Vue) ou l'utilisation d'un langage pour décrire la mise en page (React, Flutter). L'incapacité à se développer, la nécessité d'introduire les développeurs dans un nouveau langage, le risque de mourir de plate-forme, la décentralisation ont conduit au fait qu'ils ont commencé à préférer les modèles de frameworks qui essayaient d'être aussi proches que possible des plates-formes HTML / DOM.
Cependant, en plus d'écrire du code efficacement, il existe également un «coefficient» pour synchroniser une commande. Si le langage vous permet de travailler très rapidement, mais en même temps, la synchronisation d'une fonctionnalité individuelle entre deux développeurs crée une douleur terrible, cela reste très probablement une niche. Par conséquent, de nombreuses fonctionnalités et solutions de langage visent spécifiquement à réduire les problèmes de synchronisation et l'absence de problèmes. Ils réduisent ce "coefficient", qui indique combien de juniors peuvent contrôler simultanément le milieu et combien de middles peuvent être contrôlés par le développeur principal. Parmi les derniers exemples de telles fonctionnalités, les importations es6 résolvent partiellement le problème de dépendance cyclique, tandis que plus joli vous permet d'obtenir la fusion attendue et bien adaptée dans le code git, quelle que soit la façon dont le développeur l'écrit. Il ne doit pas être beau, il doit être bien synchronisé.
Et en conséquence, en quelques années, le Web en tant que plate-forme a été repris par de grandes entreprises et des équipes sérieuses, c'est pourquoi la majorité a connu une "fatigue javascript" . Soit dit en passant, la principale revendication du quasi-monopole de Google sur le Web face à Chromium est qu'ils poussent ce dont ils ont besoin dans les capacités de la plate-forme Web et de JS (bien que cela coïncide généralement avec ce dont la plupart des entreprises ont besoin).
En conséquence, d'une part, nous avons obtenu une plate-forme absolument délicieuse pour le code réutilisé partout, syntaxe qui vous permet de travailler avec de grandes commandes plates. Mais ...
Tout est devenu compliqué et tout le monde s'est embrouillé
Et personne ne savait quoi faire. Quel est en fait le problème? Dans ces trois catégories différentes.
- Développement de sites entièrement statiques et quasi-statiques avec un contenu partiellement dynamique: ce type d'application se caractérise par HTML comme point d'entrée, vitesse de téléchargement maximale et JS en option
- Développement d'applications web "classiques" sur des frameworks serveurs (django, rails): ces solutions se caractérisent actuellement par le chargement avec HTML comme point d'entrée, mais au lieu de la vitesse de téléchargement maximale, elles se concentrent sur la réutilisation du code, DRY et l'intégration backend. Le code JS est partiellement généré par le framework (notifications, formulaires, liens turbo, etc.), vous devez en partie vous écrire
- Développement d'applications client Web. Ici, l'inattendu se produit: HTML au lieu d'un point d'entrée devient à la fois un manifeste d'application et une plate-forme de rendu, et JS devient un «point d'entrée».
Qu'est-ce que j'entends par un point d'entrée: il s'agit d'une certaine entité, dont le chargement est égal à la livraison minimale à l'utilisateur du produit. Si l'utilisateur doit afficher les informations, nous avons besoin de HTML + CSS, si nous exécutons l'application, nous avons besoin de JS qui s'exécute à partir de HTML.
Et pour embrouiller tout le monde, une quatrième catégorie est apparue:
Applications isomorphes
Sous «isomorphe» dans le développement Web, on entend généralement quelque chose qui fonctionne à la fois sur le serveur et sur le client. Dans ce mode, les applications sur react, angular, vue.js peuvent fonctionner, il existe des frameworks prêts à l'emploi - Next et Nuxt , par exemple.
Les deux tâches leur sont pertinentes: l'application Web doit fournir son état initial à l'utilisateur le plus rapidement possible et agir comme une application. En d'autres termes, ils doivent fournir à la fois HTML et JS comme deux points d'entrée, un pour le contenu et un pour l'application. Cela crée deux paragraphes contradictoires: d'une part, la quantité de données livrées doit être minimale, d'autre part, la réutilisation du code est nécessaire. Pour JS, cela est résolu par des morceaux de webpack, le fractionnement de code et le chargement de code dynamique, les modèles restant pour JS, mais CSS reste. Et le plus important - nous voulons ne pas fournir un seul octet supplémentaire à l'utilisateur. Et puis quelqu'un a eu l'idée: de telles applications ont vraiment deux points d'entrée. Ils peuvent être traités comme deux entités autonomes.
De là, le concept CSS-in-JS est né, se concentrant sur deux processus distincts: la génération d'un fichier CSS pour le contenu statique et l'enregistrement des styles à côté des composants.
Tout est parti pour JS.
Maintenant, dans JS, vous pouvez trouver des styles, une mise en page et le code réel.
Maintenant tout est en js et c'est bien
Cela vaut la peine de faire une autre digression - maintenant du côté de l'épicerie.
Il est important que tout produit en cours de développement ou de développement puisse "évoluer" dans l'autre sens. Il agit à n'importe quel niveau:
La possibilité de transformer un composant visuel en un composant avec une logique minimale en ajoutant une ligne de code est très cool. La nécessité de le réécrire à partir de zéro n'est pas cool.
Rendre bon marché pour devenir une application SPA ou côté serveur est vraiment cool, mais c'est très rarement possible. Il est plus sage, s'il n'impose pas de coûts, de commencer dès le début avec une telle plateforme.
Par conséquent, presque tout projet Web qui présente un risque de devoir être rendu sur le serveur, le risque qu'il soit nécessaire de refactoriser les composants, de passer d'un moteur de modèle à un autre, tente d'éviter les risques.
Lorsqu'il existe une plate-forme unique au sein de laquelle certaines entités peuvent se transformer en d'autres à peu de frais, le développement est très rapide.
Dans le cas d'une application sur angular / react / vue, c'est exactement le cas. Ils sont difficiles à comprendre. Pas aussi compliqué que Angular 1, bien sûr, mais de toute façon - le chemin pour les comprendre est long, et les cours en ligne de six mois ne sont pas suffisants pour les comprendre. Mais ils offrent la possibilité de faire en quelques heures ce qui a été fait plusieurs semaines auparavant et en quelques jours - ce qui prenait auparavant plusieurs mois.
Cependant, l'inverse est également vrai - beaucoup n'en ont pas besoin, mais ils sont utilisés parce qu'ils sont "à la mode".
Lorsque l'architecte de l'infrastructure du groupe d'applications Web et mobiles et le concepteur de mise en page parleront, ce sera sacrément difficile pour eux. Maintenant, ce sont des directions si différentes qu'elles n'auront pas d'intersections dans la connaissance, sauf pour JS.
La prochaine fois que vous voudrez dire "le Web est devenu très complexe et gonflé" - pensez à la difficulté de concevoir et de créer un client de messagerie de boîte de réception Google (avec des entités intelligentes incluses en fonction de la lettre), un IDE Web tel que Cloud9 ou Internet Banking .
Mais si un codeur vient à vous et commence à parler du fait qu'il a besoin de réagir, car il a besoin d'une dactylographie stricte et de décorateurs pour la mise en page de la page de destination, ne cédez pas à la persuasion.