Pourquoi Magento 2 utilise Knockout au lieu de Angular ou React

28 septembre 2018 0 Par admin
Pourquoi Magento 2 utilise Knockout au lieu de Angular ou React

Ma question est aussi simple que dans le titre. C’est pourquoi Magento choisirait-il KO au lieu d’autres cadres comme angular ou react?

Y a t-il une raison spécifique?

 

Je crois que c’est la même raison pour laquelle ils ont choisi LESS plutôt que Sass – React n’avait pas une grande communauté stable quand Magento 2 a été lancé, je ne sais pas si Angular a fait mais Angular est assez complexe et À mon avis, Magento serait exagéré.

Knockout est léger, pas excessif et répond aux exigences de Magento à l’époque.

 

Il existe une version de Magento basée sur React basée sur une application Web progressive (PWA), que nous devrions pouvoir consulter à un moment ou à un autre cette année, mais il n’ya pas de date de sortie car elle est dans une phase de conception précoce. Pour plus d’informations à ce sujet, lire la suite:

 

Chez Magento, nous croyons fermement que les applications Web progressives (ci-après les PWA) sont l’avenir du Web et qu’un jour bientôt, les techniques que nous appelons PWA deviendront aussi obligatoires pour un bon site Web que le design réactif et la compression d’images. Et ainsi, nous avons conclu une collaboration avec Google pour intégrer les PWA dans l’histoire de Magento.

 

PWA?
Le terme «application Web progressive» lui-même a été inventé par Google, bien que Google n’ait aucun droit de propriété intellectuelle sur les PWA de la manière dont, par exemple, Adobe est propriétaire de Flash. Au lieu de cela, les PWA sont construites à partir de standards ouverts, que Google promulgue et implémente souvent, mais qui ne sont jamais propriétaires. Google maintient un portail complet de recherches et de documentation pour expliquer ces éléments, que vous vous retrouvez dans un onglet de navigateur lorsque vous apprenez et implémentez des PWA. Et Google fait l’outil canonique pour évaluer la performance de PWA, Lighthouse.

 

Qu’est-ce qui distingue une PWA d’un site Web raisonnablement rapide?

  • Réduit le trafic réseau afin qu’il fonctionne correctement sur une connexion lente ou inexistante.
  • First pageload sert un très petit document shell avec des ressources intégrées pour accéder à First Paint.
  • Le trafic Web est servi via HTTPS et fortement mis en cache.
  • Installe un ServiceWorker qui effectue une mise en cache intelligente sur les requêtes suivantes.
  • Pas de publication ou d’actualisation de la page: l’application JS d’une seule page est acheminée sur le client et interagit avec les données via des requêtes API minces.
  • Le code de l’application charge lui-même de nouvelles fonctionnalités au fur et à mesure des besoins, comme les données.
  • Utilise des techniques non bloquantes pour garder la réactivité de l’interface utilisateur à 60 images par seconde, de sorte qu’elle ressemble à une application native au lieu d’une simulation étrangement lente.
  • Ne touche pas directement les éléments DOM, mais effectue le rendu via une bibliothèque de composants de vue telle que Polymer, React ou Vue.
  • Diffère des calculs complexes pour éviter les problèmes de présentation, voire les envoie à ServiceWorker, pour obtenir une véritable concurrence et éviter de verrouiller le thread JavaScript appartenant à l’interface utilisateur.
  • Le CSS intégré du «chemin de rendu critique» établit immédiatement des dimensions pour tous les éléments, de sorte que la page ne «saute pas» en même temps que le contenu.
  • Installe un ServiceWorker pour étendre les fonctionnalités de l’application mono-page côté client afin qu’il puisse agir davantage comme un «client intelligent» qui ne nécessite pas de trafic réseau pour chaque interaction.
  • Intercepte toutes les requêtes réseau et les envoie via une correspondance avec les «middlewares» enregistrés par modules ou thèmes.
  • Met en cache les requêtes / paires de réponses désérialisées à l’aide de structures de données in JavaScript.
  • Détecte le mode hors connexion, avertit l’utilisateur et commence à desservir la partie traversée du magasin en réponse aux demandes AJAX.
  • Peut demander une autorisation Push Notifications et exécuter une fonction JavaScript dans ServiceWorker lorsqu’une notification est reçue… même lorsque le navigateur est fermé!
  • Sur les systèmes d’exploitation pris en charge (premier Android, désormais Windows Phone, et bientôt plus), s’enregistre comme une application pouvant être diffusée sur votre écran d’accueil en même temps que des applications natives, plutôt que sur un navigateur Web.
  • Evite les magasins d’applications restrictifs de différents fournisseurs
    Écrivez une fois, exécutez partout.
  • S’exécute toujours dans un processus de navigateur (WebView), mais le système d’exploitation le traite comme une application distincte et supprime l’interface utilisateur du navigateur qui l’entoure.
  • S’installe instantanément – vous l’avez déjà téléchargé! – bien plus rapidement que l’installation d’une application binaire native à partir d’une boutique d’applications.
  • Il y aura pas mal de nouveaux trucs là-dedans! Je sais ce que ça fait de lire. Nous sommes très conscients que certains de nos outils ont été opaques ou difficiles à maîtriser, en particulier sur le front-end. De plus, nous savons que les PWA représentent un léger changement dans les compétences du développeur frontend. C’est pourquoi la quasi-totalité de nos premières réflexions en matière de conception concerne l’expérience des développeurs et la découverte des développeurs.
  • Nous ne faisons pas que créer et publier un «thème PWA». Nous nous concentrons sur l’expérience d’auto-apprentissage, le cycle de retour d’information, l’assurance qualité, le déploiement et l’extension.
Please follow and like us: