Discussion :

[RPGamer]

comme bon nombre de produit, pour angular c'est souvent les performances qui sont décrié quand on le compare à vue, react, backbone, ember, Mithril...

Cette vidéo montre plutôt les performances spectaculaires d'Angular. Depuis, avec le lazy loading dans la v8 et bientôt Ivy dans la v9 d'autres progrès ont été fait.
Il y a toujours une grosse confusion : Angular n'est pas AngularJS.

[Sodium]

Cette vidéo date de 2015, pas sûre qu'elle soit toujours pertinente aujourd'hui, toutes les technos ont évolué dans leur coin depuis.

Personnellement, dans tous les cas la qualité du code m'importe plus que les performances dans des benchmarks absurdes ne représentant pratiquement jamais un besoin réel.

[RPGamer]

Cette vidéo date de 2015, toutes les technos ont évolué dans leur coin depuis.

Effectivement, comme je le disais les performances d'Angular (Angular2 dans la conf) ont encore augmenté pour certains cas (lazy loading dans les grosses apps) et dans les temps de compil. Et AngularJS (Angular1 dans la vidéo) est mort. Dire que les performances ne sont pas au rendez-vous est faux.

[Spartacusply]

tu peux très bien faire cela avec en autre thymeleaf, vaadin avec encore moins de ligne de code

Basé du nouveau code sur un projet abandonné (GWT) me semble quand même être très délicat...

bof

Bah non pas bof, les nouveaux frameworks front ont permis d'opté pour une techno Javascript, non pas que ça me fasse particulièrement plaisir mais au moins c'est la techno native des navigateurs.

[marc.collin]

Cette vidéo montre plutôt les performances spectaculaires d'Angular. Depuis, avec le lazy loading dans la v8 et bientôt Ivy dans la v9 d'autres progrès ont été fait.
Il y a toujours une grosse confusion : Angular n'est pas AngularJS.

un affichage de tableau.... présenter une vrai application serait plus réaliste...

[marc.collin]

Basé du nouveau code sur un projet abandonné (GWT) me semble quand même être très délicat...

projet qui n'est pu utilisé par google... comme bon nombre d'autre.... et qui est surement pas le derniers, c'est une des marques de commerce de google... qu'elle sera d'ailleurs le prochain? angular dans 4 ans... qui sait

vaadin existe depuis plus de 17 ans, son ui a utilisé diverses technologies au fil du temps et le produit est toujours pas mort


en fait vaadin utilse les web component et au besoin polymer

tu peux utiliser un wrapper js ou gwt

[krakatoa]

Alors tu pars mal parce qu'Angular n'est particulièrement pas un framework MVC. AngularJS oui, mais tu as plusieurs guerres de retard.



Ce sont des guidelines génériques là, je parle d'une structuration beaucoup plus globale d'une grosse application. Dans une application Symfony, il y UNE manière globale d'organiser son projet. C'est clair, précis, elle est déjà générée lors de la création du projet et tout le monde la respecte. Lors de la création d'un projet Angular, on a un dossier app-component et c'est marre. C'est aux développeurs, avec l'expérience et beaucoup d'erreurs, de savoir comment tout ranger au mieux, gérer les inter-dépendances entre les composants, services, modèles, je mets ça où... oui là... ah mais finalement je vais en avoir besoin ici aussi... bon ben je vais créer un module alors, etc etc.

puisque tu joue sur les mots, je reformule : ANGULAR à une approche MVC. (je doute que tu comprennes ce qu'est le MVC)

Dans Symfony, pendant très longtemps les devs ne savaient pas comment organiser leurs projets avec ces histoires de bundles et avec d'un coté /app et l'autre /src ....
(depuis sf4, c'est plus clair)

c'est pas beau de mentir pour justifier tes méconnaissances... En réalité, tu connais rien ni à Symfony, ni à Angular

[Sodium]

Quand on n'a rien à dire et que l'on est largué dans un débat, ne restent plus que les agressions personnelles

[krakatoa]

Quand on n'a rien à dire et que l'on est largué dans un débat, ne restent plus que les agressions personnelles

déjà, je te rappel ton propos qui me fait passer pour un imbécile: mais tu as plusieurs guerres de retard.



ça n’enlève rien à la réalité des choses que tu avances des arguments faux.
je t'ai mis sous le nez la preuve avec Symfony que tu mentais honteusement pour avoir raison..
c'est pas de bolle pour toi, il se trouve que je connais très bien Symfony et ce, depuis Symfony 1.4 .... ça te fait mal d'être pris en flagrant délie de mensonge alors sans arguments tu retournes la chose contre moi.



je vais te donner d'autres preuves..

tape sur google : symfony comment organiser un projet
tu verras une multitude de sujets sur les forums demandant de l'aide et aussi de multiple tutorials essayant d'expliquer comment organiser un projet Symfony.
(parceque en fait, tout le monde avait sa théorie...)

mais je sais que tu vas forcement nier en bloque et me retourner la politesse....


allez, ce n"est pas grave..... ce n'est qu'un forum, ça va aller... la vérité ça fait mal au début, mais tu va voir en réalité ça fait du bien de l'accepter et de se remettre en cause....

[Sodium]

je t'ai mis sous le nez la preuve avec Symfony que tu mentais honteusement pour avoir raison..
c'est pas de bolle pour toi, il se trouve que je connais très bien Symfony et ce, depuis Symfony 1.4 .... ça te fait mal d'être pris en flagrant délie de mensonge alors sans arguments tu retournes la chose contre moi.

Yup, pendant tout un temps Symfony était basé sur un système de bundles, ensuite ils ont recommandé de ne plus utiliser qu'un seul bundle AppBundle et la version 4 les dégagent complètement. Dans le fond, rien ne change, on range juste ses fichiers autrement. En plus de dix ans, il me paraît normal qu'un projet de cette taille évolue régulièrement. Entre-temps tu as toujours des controllers, des entités fortement liées à l'ORM doctrine (alors qu'Angular n'a pas particulièrement de couche modèle pré-conçue), un système de routage (qu'on peut utiliser ou pas dans Angular), un langage de templating... tout cela constitue un squelette solide qui fait qu'un développeur extérieur à un projet retrouve rapidement ses petits.

Je ne comprends pas bien en quoi tes propos me prendraient en "flagrant délit" car tu n'apportes absolument aucun argument visant à me contredire, l'attaque ad hominem n'étant pas un argument mais un aveux de faiblesse. Je pense que tu te sentirais plus à l'aise sur le forum 15-18 ans de jeuxvideo.com.

[krakatoa]

Yup, pendant tout un temps Symfony était basé sur un système de bundles, ensuite ils ont recommandé de ne plus utiliser qu'un seul bundle AppBundle et la version 4 les dégagent complètement. Dans le fond, rien ne change, on range juste ses fichiers autrement. En plus de dix ans, il me paraît normal qu'un projet de cette taille évolue régulièrement. Entre-temps tu as toujours des controllers, des entités fortement liées à l'ORM doctrine (alors qu'Angular n'a pas particulièrement de couche modèle pré-conçue), un système de routage (qu'on peut utiliser ou pas dans Angular), un langage de templating... tout cela constitue un squelette solide qui fait qu'un développeur extérieur à un projet retrouve rapidement ses petits.

Je ne comprends pas bien en quoi tes propos me prendraient en "flagrant délit" car tu n'apportes absolument aucun argument visant à me contredire, l'attaque ad hominem n'étant pas un argument mais un aveux de faiblesse. Je pense que tu te sentirais plus à l'aise sur le forum 15-18 ans de jeuxvideo.com.

si tu savais bien lire, j'ai bien dit que sf4 avait réglé ces problèmes
ça ne change rien à la réalité avec Symfony 2 et 3 (car j'ai exclus le 4) c'était le bordel.... et donc tu ne peux pas affirmer le contraire concernant Symfony mais bon tu peux toujours essayer de faire semblant de ne pas comprendre; Je m'enfou


Angular n'a pas encore 10 ans....

En Angular, heureusement on peux créer parfaitement des modèles sous forme de classe (comme les entités Symfony) ou via des interfaces... je ne vois pas ou tu veux en venir ou je ne vois pas ou est la complexité ? et il n'y a pas besoin d'un truc comme doctrine puisqu'il n'y a pas de base de données mais des requêtes API.....
le routage est très simple à utiliser ....

non mais tu délires ... arrête

en effet, je me sentirais certainement mieux sur un forum 15/18 ans car je suis sûr que leurs maturités serai sans doute bien plus élevés que le tiens...

[Sodium]

Encore une fois Symfony 3 (je ne vais pas me prononcer sur le deux car je ne l'ai que briévement utilisé il y a un paquet d'années) avait exactement le même fonctionnement, les fichiers étaient juste rangés ailleurs.

Mais continue, tes attaques et ton niveau de langue dignes d'un pré-ado me font beaucoup rire

[krakatoa]

ça y est, tu arrives au niveau de l'attaque sur le niveau de langue...
ensuite tu vas évoquer le trolling
c'est toujours pareil.....


il y a du soleil aujourd'hui, va en profiter

[RPGamer]

présenter une vrai application serait plus réaliste...

Ce qui est réaliste c'est de mettre entièrement à contribution les capacités des outils que l'on souhaite tester, de façon systèmatique et répétée. Le test standard du calendar est largement utilisée encore aujourd'hui pour comparer les performances et les résultats sont sans appel.

Ce sont des guidelines génériques là, je parle d'une structuration beaucoup plus globale d'une grosse application. Dans une application Symfony, il y UNE manière globale d'organiser son projet. C'est clair, précis, elle est déjà générée lors de la création du projet et tout le monde la respecte. Lors de la création d'un projet Angular, on a un dossier app-component et c'est marre. C'est aux développeurs, avec l'expérience et beaucoup d'erreurs, de savoir comment tout ranger au mieux, gérer les inter-dépendances entre les composants, services, modèles, je mets ça où... oui là... ah mais finalement je vais en avoir besoin ici aussi... bon ben je vais créer un module alors, etc etc.

Pas du tout: SRP, naming, application structure, etc. tout y est. Je vois pas ce qu'il te faut de plus...

[frfancha]

Ce qui est réaliste c'est de mettre entièrement à contribution les capacités des outils que l'on souhaite tester, de façon systèmatique et répétée. Le test standard du calendar est largement utilisée encore aujourd'hui pour comparer les performances et les résultats sont sans appel

Sauf que la présentation de React qui est faite est pour le moins étrange, donc si c'est ce gars-là qui a écrit le code React du benchmark il est -possible- (pas certain on est d'accord), qu'il soit mal écrit et que les résultats ne veulent rien dire

[RPGamer]

Sauf que la présentation de React qui est faite est pour le moins étrange, donc si c'est ce gars-là qui a écrit le code React du benchmark il est -possible- (pas certain on est d'accord), qu'il soit mal écrit et que les résultats ne veulent rien dire

Le projet est un benchmark standard, qui n'a rien à voir avec l'auteur de la présentation et qui est parfaitement open source. Si le code est jugé "mal écrit", il est tout-à-fait possible de proposer une alternative. Bonne chance.

[frfancha]

Le projet est un benchmark standard, qui n'a rien à voir avec l'auteur de la présentation et qui est parfaitement open source. Si le code est jugé "mal écrit", il est tout-à-fait possible de proposer une alternative. Bonne chance.

L'auteur écrit:

Here are screenshots of __my__ benchmark test
__I__ make a calendar with 31 days and 24 hours.

J'y vois une forte référence à "son" benchmark, pas vraiment à un standard.

Mais oui en effet le code utilisé est dispo, c'est intéressant, je vais y jeter un coup d'oeil.

[Sodium]

Non mais encore une fois on s'en fout d'un benchmark de technos de 2015

[frfancha]

Le projet est un benchmark standard, qui n'a rien à voir avec l'auteur de la présentation et qui est parfaitement open source. Si le code est jugé "mal écrit", il est tout-à-fait possible de proposer une alternative. Bonne chance.

Bon j'ai lu le code React.
Le benchmark simule 744 appels ajax simultanés (simulés par setTimeout random 500) qui changent chacun une petite partie de l'écran (la cellule qui lance la fonction random).
Pour arriver à cette simulation toutes les cellules s'enregistrent dans un array global au moment de leur création, et les 744 appels sont générés dans un loop sur cet array global.

Bon. D'accord.

Mais si ton application balance 744 requêtes ajax en même temps ... tu crois pas qu'il y a un profond problème quelque part ???

Et si vraiment il y a un endroit où 744 requêtes ajax sont balancées simultanément et que le résultat final prend 1,3 secondes (=1,8 seconde - la 0,5 seconde des requêtes les plus longues) ça fait 1,7 millième de seconde par requête ajax pour mettre à jour le DOM...
C'est pas suffisant?
Tu écris des app qui lancent 2000 requêtes simultanément et ça va être trop juste?

Par curiosité et à titre d'exercice je vais essayer de réécrire le benchmark avec des hooks pour voir si cela change quelque chose en mieux, en pire ou pas du tout.

[frfancha]

Le projet est un benchmark standard, qui n'a rien à voir avec l'auteur de la présentation et qui est parfaitement open source. Si le code est jugé "mal écrit", il est tout-à-fait possible de proposer une alternative. Bonne chance.

Ok j'ai essayé, et utiliser une base create-react-app "moderne" ou des hooks ne change rien du tout au temps d'exécution.

CEPENDANT: tester sur base de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
npm run build
serve -s build

au lieu de npm run dev divise le temps par 2,2 sur ma machine ...

OR dans les readme des github du test il est dit qu'il tourne react en dev:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

npm run dev

et angular en build prod:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ ng build -prod
$ npm install -g http-server
$ cd dist
$ http-server

Donc il faut diviser son temps react par 2 (au moins!) ...

Et tient donc, son temps react 1819 ms divisé par deux c'est son temps angular 931 ms (et même un peu moins mais bon)

Bon tout cela n'est pas très important mais quand même, avant de tirer des conclusions trop définitives sur un Benchmark il faut voir ce qu'il y a derrière