État de JavaScript en 2019 : les développeurs aiment un peu plus React, Angular est en déclin

Version imprimable

Voir 40 message(s) de cette discussion en une page

04/01/2020, 23h39
RPGamer

Citation:

Envoyé par marc.collin

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.
05/01/2020, 00h03
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.
05/01/2020, 00h09
RPGamer

Citation:

Envoyé par Sodium

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.
05/01/2020, 00h34
Spartacusply

Citation:

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...

Citation:

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.
05/01/2020, 01h50
marc.collin

Citation:

Envoyé par RPGamer

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...
05/01/2020, 02h14
marc.collin

Citation:

Envoyé par Spartacusply

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
05/01/2020, 09h12
krakatoa

Citation:

Envoyé par Sodium

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
05/01/2020, 10h06
Sodium

Quand on n'a rien à dire et que l'on est largué dans un débat, ne restent plus que les agressions personnelles ;)
05/01/2020, 10h57
krakatoa

Citation:

Envoyé par Sodium

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....
05/01/2020, 12h31
Sodium

Citation:

Envoyé par krakatoa

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.
05/01/2020, 13h01
krakatoa

Citation:

Envoyé par Sodium

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...
05/01/2020, 13h08
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 :ptdr:
05/01/2020, 13h11
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:ptdr:
05/01/2020, 15h59
RPGamer

Citation:

Envoyé par marc.collin

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.

Citation:

Envoyé par Sodium

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...
06/01/2020, 18h07
frfancha

Citation:

Envoyé par RPGamer

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
06/01/2020, 20h00
RPGamer

Citation:

Envoyé par frfancha

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.
06/01/2020, 20h49
frfancha

Citation:

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.

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.
06/01/2020, 20h52
Sodium

Non mais encore une fois on s'en fout d'un benchmark de technos de 2015 :weird:
06/01/2020, 21h26
frfancha

Citation:

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.

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.
06/01/2020, 23h11
frfancha
Citation:

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.

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:

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:

npm run dev

et angular en build prod:
Code:

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
06/01/2020, 23h33
Invité

En benchmark de frameworks frontend, j'ai plutôt entendu parler de celui-ci : https://rawgit.com/krausest/js-frame...lts/table.html
07/01/2020, 10h01
frfancha

Citation:

Envoyé par frfancha

Ok j'ai essayé, et utiliser une base create-react-app "moderne" ...

Finalement, comme dernier test, j'ai mis le state des cellules dans le calendar (les cellules reçoivent leur partie du state (isSearching, options) par props), en remplaçant les 744 calls par un seul mettant à jour le "calendar".
Dans ce cas qui me semble nettement plus réaliste le rendu est instantané.
09/02/2020, 06h29
MaximeCh

Citation:

Envoyé par defZero

Juste par curiosité, mais 400 tables dans une DB SQL et JS pour une application métier, c'était volontaire ou c'est suite à une demande client de suicide collectif ?

Tu peux développer?

Voir 40 message(s) de cette discussion en une page