Récemment, l'équipe Qwintry a commencé une migration active vers Vue.js dans tous nos anciens et nouveaux projets:- sur un ancien système Drupal (qwintry.com)
- dans notre nouveau fil qwintry.com complètement réécrit (backend sur Yii2 / Node.js)
- dans nos systèmes B2B (propulsés par Yii2) (logistic.qwintry.com)
- dans tous nos petits projets internes et publics (utilisant principalement PHP et Node.js sur le backend)
Pourquoi nos programmeurs ont opté pour Vue.js, explique le responsable du développement chez Qwintry LLC . Anton Sidashin ➔En bref: le projet Qwintry est utilisé par un demi-million de clients dans le monde, nous avons deux entrepôts (aux États-Unis et en Allemagne) utilisant notre propre logiciel cloud, et nous sommes l'un des plus grands transitaires aux États-Unis en termes de trafic de visiteurs et de départs. Nous aidons les gens à acheter des marchandises dans les magasins en ligne américains et à gérer leurs colis dans notre compte personnel, ainsi que nous pouvons économiser considérablement sur les expéditions internationales. Nous utilisons notre propre plateforme informatique et nos chaînes d'approvisionnement pour fournir une livraison internationale de qualité à un bon prix.
Notre forfait à la porte du client - à partir des avis clientsQwintry possède une base de code assez importante, composée principalement de PHP et JS (+ Swift et Java pour les applications mobiles).Nous avons décidé d'utiliser Vue.js après avoir construit une application de test avec des fonctionnalités identiques - notre calculatrice - sur React, Vue.js et Angular2. React.js
La popularité de React est montée en flèche au cours des deux dernières années, et maintenant, c'est peut-être le choix par défaut pour un développeur JS qui veut écrire quelque chose de plus compliqué sur le front qu'un paragraphe de code de trois lignes.Nous avons vu plusieurs SPA et widgets dynamiques sur React, nous avons testé React Native (pour iOS) et Redux. Je pense que React a été un grand pas pour le monde JS en termes de sensibilisation de l' État , et il a montré à beaucoup de gens ce qu'est une véritable programmation fonctionnelle d'une manière bonne et pragmatique. Je pense également que React Native est génial - il change littéralement tout le paysage du développement mobile.Réagissez aux inconvénients pour moi:
Souvent, la propreté, l'immunité et l'idéologie dominent l'approche pragmatique.
Ne vous méprenez pas. J'apprécie la pureté et la simplicité de l'approche render () - sans aucun doute, c'est une excellente idée qui fonctionne en développement réel. Je parle d'autres choses.Je pense que ce niveau de rigueur et de propreté peut être utile lorsque vous avez 1000 développeurs dans votre entreprise - à peu près au même moment, vous décidez de développer votre propre syntaxe pour traduire tout votre code PHP en types statiques . Ou lorsque vous êtes un développeur Haskell qui a décidé de comprendre JS. Mais la plupart des entreprises ont beaucoup moins de développeurs, des budgets et des objectifs plus petits qui diffèrent des objectifs de Facebook. Je m'attarderai un peu plus sur ce point.JSX suce
Attends une seconde! Je sais! C'est "juste du Javascript pur avec une syntaxe spéciale". Nos gars qui dessinent un dessin dans un croquis et Photoshop puis le convertissent en HTML, qui ont des délais serrés et qui distinguent maintenant ce formulaire en l'enveloppant dans un certain nombre de divs - en ce moment - le tambour est propre et «simple» ES6. Appliquer une certaine conception aux composants React n'est pas une fontaine, car JSX manque de lisibilité. L'incapacité de mettre le bon vieux IF dans un bloc de code HTML est mauvaise, et ne faites pas confiance aux fans de React qui disent que "si () est le siècle dernier, et maintenant tous les programmeurs normaux utilisent des opérateurs ternaires". Permettez-moi de vous assurer que JSX est toujours un fouillis de HTML et JS au moment où vous le lisez et le modifiez, même s'il est ensuite compilé en JS pur.<ul>
{items.map(item =>
<li key={item.id}>{item.name}</li>
)}
</ul>
De nombreux développeurs pensent (et je suis d'accord avec eux pendant un certain temps) que ces restrictions de syntaxe les rendront plus fortes et les aideront à écrire du code plus modulaire, car les limitations JSX (prêtes à l'emploi) vous obligent à mettre des morceaux de code dans de petites fonctions d'assistance et à les utiliser à l'intérieur Fonctions render (), comme cela et de nombreux autres gars l'ont suggéré:stackoverflow.com/a/38231866/1132016JSX vous oblige également à diviser les composants en 15 lignes HTML en 3 composants, 5 lignes HTML en chacun. Ne pensez pas que cette approche fait de vous un meilleur développeur.Voici la chose:Lorsque vous écrivez un composant relativement complexe - que vous n'allez probablement pas publier sur GitHub public rap demain pour le démontrer sur HackerNews - cette approche consistant à diviser des composants en composants super stupides en raison de restrictions JSX vous sort toujours du flux, dans que vous résolvez un vrai problème commercial. Non, je ne dis pas que l'idée de composants fractionnaires est mauvaise ou ne fonctionne pas. Vous devez être clairement conscient que vous devez diviser la fonctionnalité en ses composants afin de garder votre code dans un état contrôlé. Mais vous ne devriez le faire que lorsque vous pensez que cette entité logique particulière dans votre code est préférable d'être un composant distinct avec ses propres accessoires - et nonpour toutes les deux ou trois conditions écrites à l'aide de l'opérateur ternaire! Chaque fois que vous créez un nouveau composant ici et là, cela vous coûte un effort très spécifique et perturbe votre flux., car vous devez passer de la réflexion de l'architecte (lorsque vous vous souvenez déjà de l'état actuel du modèle de composant et que vous avez juste besoin d'ajouter du HTML ici et là pour que la fonctionnalité fonctionne) à la réflexion du gestionnaire: vous devez créer un fichier séparé pour le composant, pensez aux accessoires de ce nouveau composant comment ils mappent sur l'état, comment vous allez transférer les rappels, etc. En conséquence, la vitesse d'écriture du code est réduite, car vous devez consacrer des efforts à la modularité prématurée des composants où vous n'en auriez probablement pas besoin, si la syntaxe JSX était plus flexible. À mon avis, la modularité prématurée est très similaire à l'optimisation prématurée. Pour moi et notre équipe, la lisibilité du code est importante, mais il est toujours très important de prendre plaisir à écrire du code. Ce n'est pas coollorsqu'une simple forme de calculatrice nécessite la création de 6 composants, chacun avec ses propres accessoires.Souvent, une telle hypermodularité est également mauvaise du point de vue de la maintenance, de la modification ou de l'application d'une nouvelle conception, car pour mettre à jour le code HTML dans le widget, vous devez sauter par-dessus plusieurs fichiers / fonctions et vérifier chaque petit morceau de HTML séparément.Encore une fois, je ne propose pas d'écrire des monolithes. Je suggère d'utiliser des composants au lieu de microcomposants pour la programmation quotidienne. C'est une question d'équilibre et de bon sens.Travailler avec des formulaires et Redux vous fera imprimer toute la journée
Réagissez - il s'agit de propreté et d'écoulement à sens unique, vous vous souvenez? C'est pourquoi LinkedStateMixin est devenu une persona non grata., et maintenant vous devez écrire 10 fonctions pour obtenir l'entrée de 10 champs de formulaire. Non, vous pouvez bien sûr écrire une fonction qui vérifiera e.target, mais à la fin il y aura un tel arbre de conditions avec la normalisation des données provenant du formulaire que vous voulez pleurer; donc personne ne fait ça. 80% de ces fonctions contiendront une ligne avec this.setState () ou un appel à l'action Redux. (Ensuite, vous devrez probablement créer 10 constantes supplémentaires - une pour chaque action). Je pense que cette approche serait acceptable si vous pouviez générer tout ce code juste en y réfléchissant ... Mais je ne connais aucun éditeur IDE qui pourrait grandement simplifier l'écriture d'un tel passe-partout. Pourquoi devriez-vous imprimer autant? Parce que les grands ont décidé que la liaison bidirectionnelle est dangereuse dans les applications de grande entreprise.Je peux confirmer que la liaison bidirectionnelle n'est parfois pas aussi simple et pas si lisible, mais la plupart de ces craintes sont liées à la souffrance générale des personnes de la première version d'Angular, où la liaison bidirectionnelle n'est peut-être pas la meilleure. Et pourtant ... ce n'était probablement pas la plus grosse erreur de calcul, même dans Angular. Regardez mon éditeur rapide, que j'ai récemment épuisé avec Vue.js pour notre plate-forme Drupal (je m'excuse à l'avance pour la conception, c'est le backend de l'interface utilisateur pour nos opérateurs, et les concepteurs sont occupés à créer des interfaces pour nos clients, donc cette fonctionnalité attend son heures pour devenir belle):n'était probablement pas la plus grosse erreur de calcul, même dans Angular. Regardez mon éditeur rapide, que j'ai récemment épuisé avec Vue.js pour notre plate-forme Drupal (je m'excuse à l'avance pour la conception, c'est le backend de l'interface utilisateur pour nos opérateurs, et les concepteurs sont occupés à créer des interfaces pour nos clients, donc cette fonctionnalité attend son heures pour devenir belle):n'était probablement pas la plus grosse erreur de calcul, même dans Angular. Regardez mon éditeur rapide, que j'ai récemment épuisé avec Vue.js pour notre plate-forme Drupal (je m'excuse à l'avance pour la conception, c'est le backend de l'interface utilisateur pour nos opérateurs, et les concepteurs sont occupés à créer des interfaces pour nos clients, donc cette fonctionnalité attend son heures pour devenir belle):
Je ne peux pas montrer le code pour des raisons évidentes, mais l'écrire dans Vue était très agréable et le code était très lisible. Et je sais avec certitude que si j'écrivais une fonction distincte pour chaque champ du formulaire, comme dans React, je ne sortirais certainement pas du bonheur.Redux est également verbeux et nécessite beaucoup d'écriture . Et sur Internet, il est facile de trouver des déclarations de développeurs qui accusent Mobx de transformer React en Angular simplement parce que Mobx utilise une liaison de données bidirectionnelle (voir la clause # 1 sur la «propreté»). Il semble que de nombreuses personnes intelligentes apprécient davantage la «propreté» de leur code que la tâche métier rapide et bien résolue (ce qui, en principe, est normal si vous n'avez pas de délais).Dans le même temps, je considère que le concept Flux / Redux lui-même est très cool. Redux est simple et fournit un niveau incroyable de contrôle sur l'état de l'application, et sépare l'état des éléments purement d'interface - cela facilite immédiatement l'écriture de tests. Mais, malheureusement, tout cela est donné par une très grande quantité de gribouillis. Oui, le débogage de voyage dans le temps comme effet secondaire est génial. Mais personnellement, je suis prêt à le sacrifier pour l'écriture de code à grande vitesse et je me demande si vous avez besoin d'un voyage dans le temps si vous devez trouver une constante pour chaque champ dans le formulaire correspondant.Excès excessif d'outils
React fonctionne avec la lunette d'origine sur Babel. Vous ne ferez pas une vraie application React sans un paquet décent de packages npm, à commencer par le compilateur ES5. Une application simple basée sur la version de démarrage officielle de la charge reçoit environ 75 Mo de code JS dans node_modules. Ce n'est pas une chose critique et concerne plus le monde JS dans son ensemble que React, mais ajoute encore de la frustration et de la gêne.Mon verdict React - vous permet d'écrire du bon code lisible, mais l'écrire beaucoup n'est pas amusant. Eh bien, les problèmes pour les concepteurs de mise en page qui ne possèdent pas et ne veulent pas posséder ES6 dans HTML - ne disparaissent pas.Angular 1: Trop de liberté c'est aussi mauvais
Angular 1 est un bon framework pour l'époque, situé dans le coin opposé (de React) d'une carte JS imaginaire de propreté et de lisibilité du code. Angular vous permet de démarrer rapidement, vous permet de profiter de l'écriture des 1k premières lignes de code, puis il vous fait pratiquement écrire du code qui ne fonctionne pas très bien. Vous risquez de vous perdre dans les directives, les étendues et les flux de données bidirectionnels qui pénètrent à travers toutes les couches de votre application seront l'accord final de la chanson cygne de votre code, que les développeurs fraîchement embauchés ne voudront même pas toucher, car quelque chose se cassera. Pourquoi cela se produit-il? Angular.js a été créé en 2009, lorsque le monde du développement frontal semblait assez simple et que personne ne pensait même à un bon contrôle de l'état de l'application. Vous ne devriez pas blâmer les auteurs - ils ont juste fait un concurrent à Backbone avec de nouvelles puces et voulaient imprimer moins (et ils ont tout fait, une autre question à quel prix).Angulaire2
Construisez simplement une application hello-world et regardez le nombre de fichiers qui se retrouvent dans le navet. Je vais devoir utiliser Typescript (et je ne suis pas sûr à 100% de ce que je veux faire tous les jours - non, les gars, la saisie statique dans JS n'est pas une panacée, mais encore une fois je dois imprimer, les bonnes pensées d'Eric Eliott sur ce sujet) et les compilateurs pour commencer. Cela nous a suffi à reporter Angular2 jusqu'à des temps meilleurs. Je suis paresseux, et pour moi, c'est trop de passe-partout avant de commencer à écrire du vrai code. À mon avis, les auteurs d'Angular 2 tentent de construire un système idéal pour une entreprise qui battra React, au lieu d'essayer de créer un cadre qui résout les problèmes commerciaux pour un utilisateur ordinaire et moyen. Peut-être que je me trompe, et mon opinion peut changer - je n'ai pas beaucoup d'expérience dans Angular2, nous venons de construire une application de calculatrice de test, au final. Une merveilleuse page de comparaison sur Vue.js appelle Angular2 un bon système, qui a de nombreuses idées en commun avec Vue.js.Vue.js
Vue.js est une chose que j'attends depuis longtemps (je parlerai ci-après de Vue.js 2, qui a reçu de nombreuses améliorations par rapport à la première version de Vue, et c'est la version stable actuelle du système). Pour moi, en termes d'élégance et de concision, tout en se concentrant sur les solutions aux problèmes du monde réel, Vue.js est la plus grande percée de JS depuis le jour où j'ai été frappé par Jquery en 2007. Si vous regardez les graphiques de la popularité de Vue.js, alors remarquez que cette année il m'a plu non seulement:On Vue Github - Top 1 projet JS de 2016 (parmi les navets avec les codes sources).Par popularité dans Google Trends, Vue.js en 2016 a nettement surperformé React (bien sûr, c'est la température moyenne dans un très grand hôpital, et dépend fortement de la demande formulée - un signe de popularité très indirect).https://www.google.com/trends/explore?q=vue.js,react.js,angular.jsVue.js est l'une des plus dynamiques (en termes de communauté ou du moins de nombre de likes dans le github , et les utilisateurs de Vue Dev Tools en chrome) JS solutions en 2016, et je suis sûr que ce n'est pas juste une autre bibliothèque à la mode pour les hipsters qui passent à un nouveau cadre JS tous les 3 mois, ou le service des relations publiques a un gros travail entreprise.Laravel a ajouté Vue.js au noyau, et c'est une réclamation sérieuse.Avantages de Vue.js
Vue.js maintient un excellent équilibre entre lisibilité, maintenabilité du code et plaisir de celui-ci, ce code, en écriture. Cet équilibre est situé à une distance approximativement équidistante entre React et Angular 1, et si vous regardez la directive vue.js, vous remarquerez immédiatement combien d'idées utiles il a empruntées à ces systèmes.De React Vue.js, j'ai pris l'approche des composants, les accessoires, un flux de données à sens unique pour la hiérarchie des composants, les performances, la capacité de rendu sur le backend et l'importance d'une bonne gestion des états. Vue.js a emprunté à Angular1 des modèles similaires avec une bonne syntaxe et une liaison bidirectionnelle, mais uniquement là où vous en avez vraiment besoin et ne vous permettra pas de tirer immédiatement sur votre jambe (à l'intérieur d'un composant). Il est très facile de commencer à écrire du code sous Vue.js - je l'ai vu dans notre équipe. Vue.js ne nécessite aucun compilateur par défaut, il est donc très facile d'ajouter Vue.js à votre base de code héritée et de commencer à copier le hachage jQuery en code lisible.La bonne quantité de magie
Vue.js est très facile à travailler à la fois en termes d'approche HTML et du point de vue des développeurs JS: vous pouvez créer des modèles assez complexes sans perdre de vue la tâche métier, et le modèle HTML résultant est généralement bien lu même lorsque il est déjà grand. À ce stade, en règle générale, vous avez bien progressé dans la résolution du problème commercial et vous souhaiterez peut-être réorganiser les modèles et les diviser en composants plus petits - à ce moment, vous voyez bien mieux "l'image" de votre application qu'au tout début. Mon expérience montre que ceci est significativement différent de l'approche que les programmeurs React utilisent habituellement, et cette différence permet d'économiser beaucoup de temps et d'efforts pour les programmeurs utilisant Vue.js. Dans React, vous êtes obligé dedécomposez les composants en microcomposants et microfonctions juste au moment de la rédaction de la version initiale, «brouillon» du code, sinon vous serez littéralement enterré dans un mélange de crochets et de HTML entre eux. Dans React, je passe beaucoup de temps à polir les accessoires et à refactoriser les très petits composants (qui, bien sûr, ne seront jamais réutilisés) encore et encore, car je ne le vois pas si clairement quand j'ai soudainement besoin de changer la logique du code au milieu du processus.Formulaires
Travailler avec des formulaires HTML dans Vue.js est un plaisir. C'est là que la reliure double face est vraiment utile. Même dans les cas difficiles, il n'y a aucun problème, bien que les observateurs puissent à première vue ressembler à Angular 1. Un flux de données unidirectionnel est toujours à votre service lorsque vous divisez des composants.La technologie
Si vous voulez la compilation, le linting, PostCSS et ES6 ne sont pas un problème . Les composants à fichier unique semblent devenir le principal moyen d'écrire des composants publics dans Vue.js 2. Soit dit en passant, l'idée que Scoped CSS fonctionne dans les composants à fichier unique hors de la boîte est quelque chose qui a l'air vraiment bien et peut réduire le besoin de règles de nommage CSS strictes des classes et des technologies comme BEM .Gestion de l'État
Vue.js a une gestion d'état assez simple et utile grâce aux méthodes data () et props () - elles fonctionnent bien en développement réel. Si l'âme demande quelque chose de plus pour la gestion de l'état, il y a Vuex (qui, à mon avis, est similaire à Mobx dans React - l'état est mutable là-bas). Je pense qu'un bon pourcentage des applications Vue.js n'auront pas besoin de gestion d'état via Vuex, mais c'est bien d'avoir une alternative.Performances
Le thème est holistique, en général, à la fois réagir et vue.js sont rapides. Mais néanmoins, apparemment, vue.js est en moyenne beaucoup plus rapide.Un merveilleux lien des commentaires sur la course TodoMVC avec les mesures:eigenmethod.imtqy.com/mol/app/bench/#bench=%2Ftodomvc%2Fbenchmark%2F#sample=angular2~angularjs~mol~react~vue~vanillajs#sort=fill#Et ici, il y a des comptes plus détaillés (de la partie intéressée, cependant) .Une autre comparaison de référence détaillée et intelligible:stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.htmlVueJS
Erreurs de modèle d'exécution
Plus gros: erreurs d'exécution désagréables dans les modèles. Victime pour la commodité d'écrire du code. Ceci est très similaire à Angular 1. Vue.js parvient à générer de nombreux avertissements utiles pour le code JS: par exemple, il y a des avertissements lorsque vous essayez de muter les accessoires ou utilisez la méthode data () de manière incorrecte, l'influence positive de React est très perceptible ici. Mais les erreurs de modèle d'exécution sont toujours la faiblesse de Vue.js. Les traces de pile d'exceptions sont souvent inutiles et conduisent aux méthodes internes de Vue.js. Dans ce cas, dans cette classe d'erreurs et de débogage, JSX est souvent plus agréable: en raison de la compilation «de JS à JS», cliquer sur une erreur dans la console du navigateur conduit généralement à exactement où cette erreur s'est produite dans le code.Bibliothèques
L'infrastructure de Vue.js est encore assez jeune. En fait, les composants stables de la communauté peuvent être comptés sur les doigts, et beaucoup d'entre eux ont été construits pour Vue.js 1, et il n'est souvent pas si facile pour les débutants de comprendre pour quelle version de Vue.js une bibliothèque particulière est conçue. Ce problème est atténué par le fait que vous pouvez faire des choses sympas dans Vue.js sans avoir beaucoup besoin de bibliothèques tierces. Vous n'avez probablement besoin que d'une bibliothèque pour les requêtes Ajax ( vue-resource serait un bon choix si vous ne vous souciez pas des applications isomorphes, sinon Axios ) et probablement Vue-router, qui est considéré comme une bibliothèque avec un bon support de Vue.js.Communauté non anglophone
Commentaires chinois dans le code de la plupart des référentiels publics, et cela n'est pas surprenant: Vue.js devient une solution très populaire en Chine (Vue.js parle chinois)Projet pour une personne.
Plutôt, un problème potentiel qu'un vrai, mais parfois vous voulez jouer en toute sécurité. Evan You est le gars qui a construit Vue après avoir travaillé sur Google et Meteor. Laravel, bien sûr, est également un projet monoparental, mais il a quand même beaucoup de succès, non?Vue.js dans Drupal
Avertissement: nous ne prévoyons pas d'utiliser Drupal 8 prochainement dans Qwintry, car nous passons à des cadres PHP et Node.js plus modernes, plus rapides et plus simples, mais notre code hérité est Drupal. Étant donné que le site principal qwintry.com fonctionne sur Drupal, il était très important pour nous de vérifier Vue.js au combat ici. Honnêtement, je ne suis pas fier de nombreuses sections de notre code dans ce référentiel, nous essayons de ne pas entrer dans des endroits importants alors qu'il fonctionne au moins d'une manière ou d'une autre, mais cet ancien projet avec une histoire fonctionne assez bien et génère nos revenus, nous le respectons donc, l'améliorer, et de nombreuses nouvelles fonctionnalités sortent ici. Voici une liste des choses que j'ai construites sur Vue dans Drupal: un formulaire d'édition d'entité rapide qui comprend la génération de factures clients ainsi que la modification rapide des listes de produits.Ici, il était nécessaire de créer une API JSON simple pour charger et enregistrer des entités - rien de spécial, juste quelques rappels. Deux tableaux de bord, via l'API Saas REST des produits que nous utilisons pour notre équipe d'assistance, afin que les opérateurs n'aient pas besoin de parcourir les pages d'administration de sites Web individuels pour vérifier les informations relatives à un client particulier. Maintenant, tout cela est intégré directement dans le profil client sur notre site Web. Je sais que de nombreux développeurs backend sont toujours bloqués en 2010 avec le système de noyau Ajax Drupal. Je sais bien à quel point le code Drupal peut être compliqué lorsque vous essayez de créer une sorte de formulaire complexe à plusieurs étapes en utilisant la fonctionnalité Ajax à partir du noyau - il est presque impossible de maintenir un tel code plus tard. Oui, je parle de vous, ctools_wizard_multistep_form (), et vous,via l'API Saas REST des produits que nous utilisons pour notre équipe d'assistance, afin que les opérateurs n'aient pas à parcourir les pages d'administration de sites Web individuels pour vérifier les informations relatives à un client particulier. Maintenant, tout cela est intégré directement dans le profil client sur notre site Web. Je sais que de nombreux développeurs backend sont toujours bloqués en 2010 avec le système de noyau Ajax Drupal. Je sais très bien à quel point le code Drupal peut être complexe lorsque vous essayez de créer une sorte de formulaire complexe à plusieurs étapes en utilisant la fonctionnalité Ajax à partir du noyau - il est presque impossible de maintenir un tel code plus tard. Oui, je parle de vous, ctools_wizard_multistep_form (), et vous,via l'API Saas REST des produits que nous utilisons pour notre équipe d'assistance, afin que les opérateurs n'aient pas à parcourir les pages d'administration de sites Web individuels pour vérifier les informations relatives à un client particulier. Maintenant, tout cela est intégré directement dans le profil client sur notre site Web. Je sais que de nombreux développeurs backend sont toujours bloqués en 2010 avec le système de noyau Ajax Drupal. Je sais bien à quel point le code Drupal peut être compliqué lorsque vous essayez de créer une sorte de formulaire complexe à plusieurs étapes en utilisant la fonctionnalité Ajax à partir du noyau - il est presque impossible de maintenir un tel code plus tard. Oui, je parle de vous, ctools_wizard_multistep_form (), et vous,Maintenant, tout cela est intégré directement dans le profil client sur notre site Web. Je sais que de nombreux développeurs backend sont toujours bloqués en 2010 avec le système de noyau Ajax Drupal. Je sais bien à quel point le code Drupal peut être compliqué lorsque vous essayez de créer une sorte de formulaire complexe à plusieurs étapes en utilisant la fonctionnalité Ajax à partir du noyau - il est presque impossible de maintenir un tel code plus tard. Oui, je parle de vous, ctools_wizard_multistep_form (), et vous,Maintenant, tout cela est intégré directement dans le profil client sur notre site Web. Je sais que de nombreux développeurs backend sont toujours bloqués en 2010 avec le système de noyau Ajax Drupal. Je sais bien à quel point le code Drupal peut être compliqué lorsque vous essayez de créer une sorte de formulaire complexe à plusieurs étapes en utilisant la fonctionnalité Ajax à partir du noyau - il est presque impossible de maintenir un tel code plus tard. Oui, je parle de vous, ctools_wizard_multistep_form (), et vous,ajax_render !Dans le même temps, ces développeurs sont poussés par les exigences des interfaces modernes, mais la complexité de l'infrastructure JS moderne les entraîne dans une dépression. Oui, je me reconnais il y a un an. Alors les gars, écoutez-moi! Vous ne trouverez pas de meilleur moment et de meilleure façon d'améliorer vos interfaces que de prendre en ce moment Vue.js, de le placer dans sites / all / bibliothèques, de l'ajouter avec drupal_add_js () au modèle et de commencer à écrire du code. Vous serez choqué de voir à quel point il est plus facile de maintenir un système dans lequel Drupal n'est responsable que du JSON généré lorsque tout le code client, y compris les formulaires, est entièrement alimenté par Vue.js.Vue.js dans Yii2
Fait amusant: Yii a été créé par le développeur chinois Qiang Xue. Ainsi, on peut appeler Yii + Vue.js une pile non seulement une pile, dont le nom est presque impossible à prononcer du premier coup, mais aussi une pile d'origine chinoise (dans le bon sens). Pour la nouvelle version de Qwintry.com (non encore publiée), nous avons choisi Yii2, qui, à mon avis, est l'un des meilleurs et des plus rapides frameworks PHP. Il n'est certainement pas aussi populaire que Laravel, qui a pris les devants dans le monde PHP, mais la pile Yii2 nous convient parfaitement.(bien que nous regardions Laravel de temps en temps, les développeurs y exploitent, et là, bien sûr, une infrastructure plus mature en termes de bibliothèques). Nous diminuons progressivement la quantité de code HTML généré par Yii2 et PHP, en nous concentrant davantage sur l'API REST, qui génère du JSON pour la partie client s'exécutant sur Vue.js / Swift / Java. L'approche API-first est utilisée pour la plupart de nos modèles Active Record dans le projet. Ici, nous sommes déjà sérieux au sujet de l'API et c'est pourquoi nous consacrons beaucoup de temps à une bonne documentation de l'API, même si cette API n'est pas publique. Dans les sections de code où la partie HTML est générée au niveau PHP, nous utilisons nos propres solutions et webpack pour regrouper et déployer facilement les widgets Yii2, qui, à leur tour, utilisent des composants à fichier unique Vue. Avec PHP7 et la dernière version de MySQL, le temps de réponse de notre backend Yii2 JSON n'est pas très différent de Node.js backends (je parle d'une vitesse de réponse de l'ordre de 15-20ms), ce ne sont pas des figures cosmiques, franchement, mais c'est plus que suffisant pour nos besoins, et surtout, c'est 10-20 fois plus rapide que ce qu'elle peut donner notre ancien site Drupal. En même temps, c'est un bon vieux PHP (et ennuyeux peut-être) avec toute la force des bibliothèques de compositeurs et une base de code stable. La réactivité des interfaces construites sur Yii2 & Vue.js est très acceptable, et, du point de vue de la lisibilité du code, tout est en ordre ici aussi.La réactivité des interfaces construites sur Yii2 & Vue.js est très acceptable, et, du point de vue de la lisibilité du code, tout est en ordre ici aussi.La réactivité des interfaces construites sur Yii2 & Vue.js est très acceptable, et, du point de vue de la lisibilité du code, tout est en ordre ici aussi.Nous utilisons également Vue.js dans un certain nombre de projets internes et externes, où le backend fonctionne sur Node.js - je n'ajouterai rien de nouveau à ce qui précède, tout fonctionne bien.Conclusion
Nous écrivons du code Vue.js tous les jours depuis environ 4 mois dans divers projets, et les résultats sont impressionnants. 4 mois, ce n'est rien dans le monde du backend, mais pour le monde JS, c'est une période décente pour laquelle cinq frameworks naissent et meurent :) Voyons ce qui se passe ensuite. Je pense que Vue.js sera la principale solution pour JS dans les 16-24 prochains mois si Evan You prend les bonnes mesures, au moins parmi les équipes back-end et small front-end. La pile React sera intégrée en 2017, surtout si React Native continue de croître et de s'améliorer au même rythme qu'aujourd'hui.UPD: Cet article a frappé le haut HackerNews, et il a suivi une discussion utile (plus de 250 commentaires): news.ycombinator.com/item?id=13151317En haut Reddit nous WEBDEV également visité, 60+ commentaires ici. Commentaire-opinion drôle sur Angular2 à partir de là:Toute la documentation de Google, c'est comme lire les documents Microsoft du début des années 2000.
"Mettre en place un projet Angular est un jeu d'enfant! Assurez-vous simplement que le mutateur de prototype de référence sans état hérite de l'objet hérité du chargeur de mémoire de base implémentant le fournisseur de services MODOK (ne fait pas partie du noyau: voir ici pour des détails également illisibles). Vous serez alors prêt à compiler votre noyau angulaire, en faisant attention à utiliser Webpack 2.3.9 (note: pas 2.3.8 comme fourni avec le référentiel). C'est tout ce que vous devez savoir pour démarrer un grand projet Angular. Angular: rendre le développement simple et amusant à nouveau! »
Questions des lecteurs:
JSX est cool et correct, mais vous n'êtes pas très! Si vous voulez vraiment des conditions - programmez votre composant If, ce sont trois lignes!Il est désagréable de choisir un cadre, puis de faire de telles choses contre lui, chaque nouveau développeur qui vient au projet vous posera de telles décisions, et dans les composants des autres, vos yeux trébucheront toujours sur la ternarité.De plus, si le composant écrit «front» aura des problèmes en ce sens que les composants internes sont toujours exécutés. Mais il existe des solutions plus intéressantes: github.com/AlexGilleran/jsx-control-statementsAlors, que suggérez-vous, mon cher, maintenant vous devez abandonner d'urgence React et tout réécrire sur Vue.js?Non, non! React est un excellent framework, et il vous permet d'écrire du code lisible et pris en charge, et aussi une énorme quantité de bibliothèques de haute qualité ont déjà été écrites pour lui (et les micro-composants et les limitations de JSX, que j'ai «grondé» ci-dessus, jouent un rôle positif ici, pour les bibliothèques publiques, c'est déjà souvent justifié), qui ne sont pas pour toute autre solution JS. Si vous et votre équipe êtes satisfait de tout dans JSX et que vous ne vous embêtez pas à taper beaucoup, peut-être qu'il est inutile de passer à Vue.js, le jeu ne vaut tout simplement pas la chandelle. De nombreux amateurs de JS ont récemment adoré sauter d'un cadre à un cadre. N'en abusez pas, à mon avis, il vaut mieux passer ce temps sur quelque chose de plus intéressant que les utilisateurs de votre projet remarqueront.Mais si vous ne pouviez pas vous lancer dans React en raison d'outils massifs et d'autres difficultés, et que votre code rencontre des problèmes jQuery ou Backbone, Vue.js peut être une excellente option, pas académique, simple et concise.Je n'ai pas lu tout l'article, mais dans le titre vous y avez dit quelque chose de négatif à propos de l'immunité, vous n'êtes probablement pas orthodoxe à cause de votre inexpérience et de votre stupidité, vous ne comprenez pas à quel point une approche fonctionnelle est géniale!Séparons l'immunité en tant que paradigme fonctionnel (nous respectons grandement l'approche fonctionnelle, le concept d'immunité et la pureté des fonctions) et l'état actuel du monde JS et de ses bibliothèques. Si un développeur, après avoir lu le blog Facebook, saisit Immutable.js avec joie et le met en production, puis se rend compte qu'il n'a pas un très bon dock, Lodash et tout le reste du code écrit par la génération de développeurs précédente ne travaillent pas avec lui (oui, je suis au courant sur les enveloppes immuables autour de lodash, merci), et donc le développeur ne respecte pas le délai - cela signifie que le développeur n'a pas acheté le paradigme fonctionnel, mais plutôt le battage médiatique autour de la bibliothèque spécifique. Ne pensez pas que si Facebook a de vrais problèmes qu'ils résolvent en utilisant Immutable.js, cela signifie que vous aurez des problèmes d'un ordre similaire dans votre page de destination ou votre SPA.Probablement pas, plutôtvos investisseurs manqueront d'argent, vous devrez déployer des fonctionnalités fonctionnelles le plus rapidement possible, et il suffit que le code soit normal et ne mute pas là où il n'est pas nécessaire, il n'a pas besoin d'utiliser Immutable.js pour cela (vous pouvez lire l'avis sur Immutable.js, par exemple, ici ). Séparément, je note qu'un grand nombre de développeurs JS, dont je considérais les opinions comme la principale caractéristique tueuse d'Immutable.js, ne sont pas appelés la pureté et la fiabilité du code résultant, mais - attention! - augmentation de la productivité (nous parlons de comparaisons rapides de structures)! Quelque chose dans ce monde ne va pas si les gens poussent un élément fonctionnel de ce niveau pour améliorer les performances de leur projet. Il semble que la mode soit à nouveau intervenue ...Si vous voulez simplifier votre vie, arrêtez simplement de muter votre condition, passez à des accessoires, et ces choses simples amélioreront votre vie dès maintenant.