Une comparaison réelle des cadres frontaux avec les références (mise à jour 2018)

MISE À JOUR: Il existe une version plus récente de cet article

Cet article est une actualisation d'une comparaison dans le monde réel des cadres frontaux avec des repères de décembre 2017.

Dans cette comparaison, nous montrerons comment différentes implémentations d'exemples d'applications RealWorld presque identiques se comparent.

L'exemple d'application RealWorld nous donne:

  1. Real World App - Quelque chose de plus qu'un "todo". Habituellement, les «tâches» ne transmettent pas suffisamment de connaissances et de perspectives pour réellement créer de vraies applications.
  2. Standardisé - Un projet conforme à certaines règles. Fournit une API principale, un balisage statique, des styles et des spécifications.
  3. Écrit ou révisé par un expert - Un projet cohérent et réel que, idéalement, un expert dans cette technologie aurait construit ou examiné.

Critique de la dernière version (décembre 2017)

️ Angular n'était pas en production. L'application de démonstration répertoriée sur le dépôt RealWorld utilisait une version de développement, mais grâce à Jonathan Faircloth, elle est maintenant en version de production!

Vue n'était pas répertorié dans le référentiel Real World et n'était donc pas inclus. Comme vous pouvez l'imaginer, dans le monde frontal, cela a causé beaucoup de chaleur. Comment se fait-il que vous n'ayez pas ajouté Vue? Qu'est-ce qui ne va pas chez toi? Cette fois-ci, Vue.js est arrivé! Merci Emmanuel Vilsbol.

Quelles bibliothèques / frameworks comparons-nous?

Comme dans l'article de décembre 2017, nous avons inclus toutes les implémentations répertoriées dans le référentiel RealWorld. Peu importe si elle a un grand public ou non. La seule qualification est qu'il apparaît sur la page de dépôt RealWorld.

Frontends sur https://github.com/gothinkster/realworld (avril 2018)

Quelles mesures examinons-nous?

  1. Performance: combien de temps cette application prend-elle pour afficher le contenu et devenir utilisable?
  2. Taille: quelle est la taille de l'application? Nous comparerons uniquement la taille du ou des fichiers JavaScript compilés. Le CSS est commun à toutes les variantes et est téléchargé à partir d'un CDN (Content Delivery Network). Le HTML est également commun à toutes les variantes. Toutes les technologies se compilent ou se transposent en JavaScript, nous ne dimensionnons donc que ce ou ces fichiers.
  3. Lignes de code: De combien de lignes de code l'auteur a-t-il eu besoin pour créer l'application RealWorld en fonction des spécifications? Pour être honnête, certaines applications ont un peu plus de cloches et de sifflets, mais cela ne devrait pas avoir un impact significatif. Le seul dossier que nous quantifions est src / dans chaque application.

Mesure n ° 1: performances

Découvrez le premier test de peinture significatif avec Lighthouse Audit fourni avec Chrome.

Plus tôt vous peindrez, meilleure sera l'expérience pour la personne qui utilise l'application. Le phare mesure également First interactive, mais c'était presque identique pour la plupart des applications, et il est en version bêta.

Première peinture significative (ms) - plus c'est bas, mieux c'est

Vous ne verrez probablement pas beaucoup de différence en termes de performances.

Métrique n ° 2: taille

La taille du transfert provient de l'onglet réseau Chrome. En-têtes de réponse GZIPed plus le corps de réponse, tels que fournis par le serveur.

Plus le fichier est petit, plus le téléchargement est rapide (et il y a moins à analyser).

Cela dépend de la taille de votre infrastructure ainsi que des dépendances supplémentaires que vous avez ajoutées et de la capacité de votre outil de génération à constituer un petit ensemble.

Taille de transfert (Ko) - plus c'est bas, mieux c'est

Vous pouvez voir que Svelte, Dojo 2 et AppRun font un très bon travail. Je ne peux pas en dire assez sur Elm - surtout quand vous regardez le tableau suivant. J'aimerais voir comment Hyperapp se compare… peut-être la prochaine fois, Jorge Bucaran?

Mesure n ° 3: lignes de code

En utilisant cloc, nous comptons les lignes de code dans le dossier src de chaque dépôt. Les lignes vides et les commentaires ne font pas partie de ce calcul. Pourquoi est-ce significatif?

Si le débogage est le processus de suppression des bogues logiciels, alors la programmation doit être le processus de leur mise en place - Edsger Dijkstra
# lignes de code - moins c'est mieux

Moins vous avez de lignes de code, plus la probabilité de trouver une erreur est faible. Vous avez également une base de code plus petite à gérer.

En conclusion

Je voudrais dire un grand merci à Eric Simons pour la création du référentiel RealWorld Example Apps et à de nombreux contributeurs qui ont écrit différentes implémentations.

Mise à jour: Merci à Jonathan Faircloth pour avoir fourni la version de production d'Angular.

Et si vous avez trouvé cet article intéressant, vous devriez me suivre sur Twitter et Medium.