Version imprimable
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.Citation:
Envoy� par marc.collin
Il y a toujours une grosse confusion : Angular n'est pas AngularJS.
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.
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.Citation:
Envoy� par Sodium
Bas� du nouveau code sur un projet abandonn� (GWT) me semble quand m�me �tre tr�s d�licat...Citation:
tu peux tr�s bien faire cela avec en autre thymeleaf, vaadin avec encore moins de ligne de code
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.Citation:
bof
un affichage de tableau.... pr�senter une vrai application serait plus r�aliste...Citation:
Envoy� par RPGamer
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 saitCitation:
Envoy� par Spartacusply
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
Citation:
Envoy� par Sodium
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
Quand on n'a rien � dire et que l'on est largu� dans un d�bat, ne restent plus que les agressions personnelles ;)
Citation:
Envoy� par Sodium
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....
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.Citation:
Envoy� par krakatoa
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�mesCitation:
Envoy� par Sodium
�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...
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 :ptdr:
�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:ptdr:
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.Citation:
Envoy� par marc.collin
Pas du tout: SRP, naming, application structure, etc. tout y est. Je vois pas ce qu'il te faut de plus...Citation:
Envoy� par Sodium
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 direCitation:
Envoy� par RPGamer
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.Citation:
Envoy� par frfancha
L'auteur �crit:Citation:
Envoy� par RPGamer
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.
Non mais encore une fois on s'en fout d'un benchmark de technos de 2015 :weird:
Bon j'ai lu le code React.Citation:
Envoy� par RPGamer
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.
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.Citation:
Envoy� par RPGamer
CEPENDANT: tester sur base de
au lieu de npm run dev divise le temps par 2,2 sur ma machine ...Code:
2
OR dans les readme des github du test il est dit qu'il tourne react en dev:
et angular en build prod:Code:npm run dev
Donc il faut diviser son temps react par 2 (au moins!) ...Code:
2
3
4
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