Discussion :

[grunt2000]

Bonjour,

J'ai souhaité m'autoformer à Angular en achetant le livre édité chez Expert IT : Angular, développez vos applications web avec le framework Javascript, dans sa deuxième édition

Mais je souhaite témoigner ici que j'en suis très déçu, et que si j'avance dans mon apprentissage, c'est en utilisant également Internet pour compléter le livre.
Ce qui m'apparaît pour certain, c'est que bien qu'en deuxième édition, ce livre n'a pas été relu ni son contenu réessayé par ses auteurs à partir d'une machine vierge pour voir si ce qu'ils avaient écrit fonctionnait ou non. Sinon, ils auraient constaté que ce n'était pas le cas et se seraient corrigés.

Et c'est très flagrant :
Le premier chapitre d'importance, le Chapitre 3 : Les fondamentaux d'Angular, fait 30 pages et passe en revue l'exemple de la todo-list, les pipes, les décorateurs,
mais oublie de dire que le composant à créer pour débuter son code de test doit être créé par un ng new todolist, qu'il faudra faire un ng generate component today pour avoir le composant enfant, et faute de test de leur propre contenu, les auteurs ne remarquent pas qu'il manque un import FormsModule from @angular/forms pour que le code proposé fonctionne. C'est au lecteur d'aller le corriger lui-même. Et c'est ainsi toutes les cinq pages... Ça peut-être aussi anodin que des lignes html qui manquent pour afficher le même contenu que ce qui est présenté en démo, que d'assez longues recherches à faire sur Internet quand on ne connaît pas encore bien Angular.

Je suis actuellement au chapitre 6 qui détaille les composants, à essayer de comprendre comment expérimenter une méthode de réaction aux changements de valeurs sur une propriété (avec des get et set sur des backing property) : une méthode est présentée, qui n'est branchée nulle-part, n'est associée à aucun gestionnaire d'évènement d'aucune sorte... Et rien ne se passe de ce qui est décrit que je devrais voir.

Je suis sidéré. Le livre a trois auteurs.
Et il n'y en a pas un qui a pensé à vérifier si ce qui était écrit dedans était correct !

[Marco46]

Bah après le framework lui-même est une véritable usine à gaz, à commencer par l'existence même de angular-cli.

Pas étonnant qu'un livre expliquant une usine à gaz soit mal fichu, c'est à prendre plutôt comme un hommage je pense ...

[krakatoa]

Bah après le framework lui-même est une véritable usine à gaz, à commencer par l'existence même de angular-cli.

Pas étonnant qu'un livre expliquant une usine à gaz soit mal fichu, c'est à prendre plutôt comme un hommage je pense ...

désolé mais moi je ne trouve pas que le framework soit une usine à gaz.

je t'apprends rien, dans son architecture il y a les modules et les composants web avec l'utilisation de service .
c'est pourtant simple à comprendre, en quoi c'est une usine à gaz.

le framework est complet: routing, form, DI....
ce n'est pas plus une usine que react ou vuejs quand on lui ajoute tous les packages nécessaires pour faire un moyen ou gros projet comme sur Angular.
pire, on doit leur ajouter redux alors qu'avec Angular on peut s'en passer (bien qu'on puisse quand même ll'utiliser)
parceque quand on commence à faire des gros trucs avec react ou vuejs... ça commence à être le bordel ! chacun à sa méthode pour faire le truc , c'est super pour la maintenance

la documentation sur angular, j'avoue, est un fourre tout ! mais le framework en lui même NON !
faut arrêter de faire les pleurnicheuses !


react, vuejs, angular.. pour moi sont tous cool et excitant à coder mais mon coup de coeur c'est pour Angular !


@grunt2000, il y a une excellente formation en ligne: angular de l'équipe: ninja squad
c'est payant mais c'est le top !

[Marco46]

Mon principal reproche sur Angular c'est d'avoir remis les modules et le système de DI en provenance d'AngularJS qui sont des abstractions inutiles et redondantes avec les possibilités natives du JS vanilla.

Je trouvais ça cool au début parce que je venais de Java mais après avoir mieux creusé JavaScript on se rend compte que ça ne sert à rien et que ça complique tout pour rien.

Le 2ème gros reproche c'est de mettre des classes partout alors que c'est totalement inutile. En Java on utilisait des classes comme container parce qu'on avait pas de modules et que les fonctions n'étaient pas first class mais c'est useless en JS.

Le 3ème gros reproche c'est que du fait de cet usage abusif des classes, leur utilisation de TypeScript est atroce alors que c'est une formidable extension à JS pour documenter les entrées / sorties des fonctions.

Le 4ème gros reproche c'est d'avoir popularisé cette daube infâme de angular-cli qui fait que les devs ne mettent plus les mains dans le cambouis pour comprendre comment est structuré un projet front et sont complètement dépassés dès qu'il y a un soucis quelconque avec leur outil de travail. Nononon, il faut être sérieux et apprendre chaque outil indépendamment. Ça prend pas tant de temps que ça et ça permet de parfaitement contrôler ce qu'on veut faire et de capitaliser sur ces outils.

Et puis Karma et Jasmine merci kiki ... Yeeeeerk. Quand t'as gouté à Jest c'est juste plus possible en fait ...

Franchement en 2020 j'éviterais de me former à Angular c'est vraiment pas le bon cheval. Choisissez Vue ou React.

[dukoid]

pas d'accord ! Angular c'est bien pour 2020 et +

[krakatoa]

pas d'accord !

les modules permettent d'avoir le gros avantage de rendre des fonctionnalités réutilisables: on déclare les packages et composants que l'on a besoin dans son module. ensuite l'ensemble de ce module + composants, on le réutilise ailleurs, simplement.
ça fait aussi espace de nom . De plus, on peut avoir un service déclaré en tant que singleton au niveau d'un module.. pas besoin que cette classe soit disponible pour tous les modules ou toutes les parties d'un projet
on s'en sert aussi pour lui accorder son propre routing (chaque module, son routing)
et on gère l'ensemble, facilement !

Pour l'architecture, je n'ai pas la même vision que toi. fournir de la liberté, c'est donner la possibilité à chacun de faire à sa sauce, résultat bonjour la maintenabilité
par contre avoir une architecture bien défini, c'est --> (c'est la qualité de son défaut)
parceque je sais comment structurer un projet Angular, il est vrai qu'on peut être perdu et que la doc ne donne pas de voie à suivre malheureusement.
c’était le cas avec Symfony, un gros framework PHP ou on ne savait pas comment structurer un projet avec les bundles...

quand à angular-cli, tu lui reproches son utilité alors que s'il n'existait pas, d'autres critiqueraient ce fait
pour ma part, je trouve ça pratique ! c'est un outil, pourquoi dire non à un outil ..
si il y a des gens qui ne savent pas se servir d'une perceuse pourquoi ils priveraient les autres ... C'est STUPIDE

ce que je trouve pas possible c'est de faire du redux parcequ'il n'y a pas d'autres choix.. la bonne blague

je recommande de se former sur Angular en 2020 parceque déjà on ne fait pas le mouton, on ne suit une mode et parceque Angular c'est fiable, performant, complet, architecturé. De plus c'est demandé sur le marché de l'emploi et bien payé

[Marco46]

les modules permettent d'avoir le gros avantage de rendre des fonctionnalités réutilisables: on déclare les packages et composants que l'on a besoin dans son module. ensuite l'ensemble de ce module + composants, on le réutilise ailleurs, simplement.
ça fait aussi espace de nom . De plus, on peut avoir un service déclaré en tant que singleton au niveau d'un module.. pas besoin que cette classe soit disponible pour tous les modules ou toutes les parties d'un projet
on s'en sert aussi pour lui accorder son propre routing (chaque module, son routing)
et on gère l'ensemble, facilement !

Et donc c'est très exactement un doublon inutile des modules ES6. Du coup ça ne sert absolument à rien. C'est pas un hasard si Angular et le seul framework front à implémenter un tel système. Il n'y a rien de comparable nulle-part parce que c'est d'une inutilité totale.

En revanche pour Angular c'est utile dans le cadre de leur DI à la sauce Java qui ne sert elle-même à rien compte tenu des capacités natives de JS (modules + fonctions first class + currying + partial application = DI out of the box). Mais évidemment ça suppose d'avoir des développeurs qui connaissent JS un minimum et pas d'avoir des gens qui viennent de J2EE pour se mettre au fullstack.

Angular a été conçu pour permettre aux devs J2EE de chez Google (parce que le plus clair du SI de Google est en Java) de faire du front en fullstack sur un outil moderne.

De même que React a été conçu pour des devs issus de PHP car le SI de Facebook est historiquement en PHP, et on sent très clairement les influences avec leur CSSinJS et le JSX, ça sent, j'ai même envie dire ça pue le PHP !

Et Vue lui au contraire a été conçu pour, chose incroyable, écrire des webapps ! Et ce indépendamment des intérêts RH de Facebook ou Google. Et ça se sent à l'usage même si Vue a une forte influence de AngularJS. Normal tu vas me dire puisque Evan Yu est un ancien googler qui travaillait sur ... Angular xD

Mais bref je digresse ...

Pour l'architecture, je n'ai pas la même vision que toi. fournir de la liberté, c'est donner la possibilité à chacun de faire à sa sauce, résultat bonjour la maintenabilité
par contre avoir une architecture bien défini, c'est --> (c'est la qualité de son défaut)
parceque je sais comment structurer un projet Angular, il est vrai qu'on peut être perdu et que la doc ne donne pas de voie à suivre malheureusement.
c’était le cas avec Symfony, un gros framework PHP ou on ne savait pas comment structurer un projet avec les bundles...

Tu confonds l'architecture logicielle avec le fait de mettre tel ou tel fichier dans tel ou tel répertoire ce qui relève de la convention mais certainement pas de l'architecture.

De même que créer des classes "pour faire comme en Java" ce n'est pas de l'architecture et quand on dispose de modules en natif ça relève même de l'erreur. Le bon outil c'est le module pas la classe.

J'ajouterais qu'avoir un projet créé avec Angular (ou React ou Vue) n'est garant en rien de la maintenabilité de ta webapp. La maintenabilité ne relève quasiment que de la qualité du travail des développeurs qui est de traduire les exigences métiers en code source.

quand à angular-cli, tu lui reproches son utilité alors que s'il n'existait pas, d'autres critiqueraient ce fait
pour ma part, je trouve ça pratique ! c'est un outil, pourquoi dire non à un outil ..
si il y a des gens qui ne savent pas se servir d'une perceuse pourquoi ils priveraient les autres ... C'est STUPIDE

C'est un outil qui abstrait des éléments essentiels de ton outil de travail (serveur de dev, bundler, transpilation, linting, tests, etc ...). Pour moi c'est comme utiliser le module Git de WebStorm ou Visual Studio Code sans jamais avoir appris la ligne de commande. Pour être compétent il faut mettre le nez dans le détail.

ce que je trouve pas possible c'est de faire du redux parcequ'il n'y a pas d'autres choix.. la bonne blague

L'utilité des Redux like est discutable en effet. Il n'est pas obligatoire de les utiliser pour faire du Vue ou React et comme tous les outils il présente certains caveat non-négligeables.

De plus c'est demandé sur le marché de l'emploi et bien payé

Oui bah comme Vue et React. Mais en France les DSI suivent les tendances US avec quelques années de retard. On est pas moteur, on suit la vague avec du retard. Compte tenu de la forte décrue d'Angular à l'international ces 3 dernières années je pense pas que ça soit un très bon choix pour l'avenir.

Tu noteras que la plupart des startups va sur du React ou du Vue mais très très peu sur de l'Angular. C'est un signal fort de ce que seront les SI de demain !

Mais c'est comme vous voulez

[krakatoa]

bref, on ne sera jamais d'accord.

[grunt2000]

@Marco46 :
- Venir cracher sur Angular et faire la promotion de React sur un forum Angular, seul un modérateur peut se le permettre. Et ce n'est pas constructif.
- Si je me forme sur Angular, ce n'est pas par plaisir, c'est par nécessité. Les annonces d'emploi que je cherche dans le monde Java ont Angular en à-côté, et pas React. Quand j'en verrai avec React en proportion supérieure, je m'y intéresserai. Mais pour le moment, c'est lui.

[Marco46]

1/ Je ne fais pas la promotion de React ce n'est pas non plus ma tasse de thé, je préfère Vue et de très loin.

2/ Dans la mesure où la critique est constructive (il ne s'agit pas de crachat mais d'expliquer avec des éléments concrets) je ne vois pas le problème, c'est le but d'une discussion.

3/ Il est important de connaître pourquoi Angular est construit de cette manière, surtout si on vient de Java.

4/ Je t'invite fortement à commencer par apprendre TypeScript avant Angular (et JavaScript avant TypeScript mais je pars du principe que c'est déjà le cas en ce qui te concerne), ce qui signifie se taper l'intégralité de la documentation et des articles de blogs officiels et je ne parle pas seulement de lecture mais bien d'expérimenter concrètement comment ça fonctionne en exécutant les codes et en examinant le code JavaScript généré par tsc. Rien que pour ça il faut deux grosses semaines à temps plein. Angular sera certainement plus clair ensuite. Malheureusement tu constateras par la suite que 99% de tes collègues n'ont pas fait ce travail et font donc n'importe quoi avec le framework.

5/ Il y a effectivement pas mal de DSI avec du J2EE historique qui ont eu la brillante idée d'ouvrir des postes fullstack Java / TypeScript parce que Angular et TypeScript "ont dirait que c'est comme J2EE yaura pas besoin de former les devs Java". Heureusement il y a plein d'autres types de postes. Sur des postes fullstack avec des stacks ayant en front du React ou du Vue on va plutôt être sur du node ou PHP en back (sauf si les postes sont séparés front / back, comme dans le grand compte pour lequel je bosse actuellement où le back est en Java et le front en Vue).

[dukoid]

2/ être constructif ne veut pas dire que c'est une vérité, qu'on a raison. je conteste la plupart de tes arguments
4/ merci pour ces informations. ça, j'aime. les conseils non orientés que l'on peut donner
5/ il y a du taf avec Angular, ne t'en déplaise

[Marco46]

2/ être constructif ne veut pas dire que c'est une vérité, qu'on a raison. je conteste la plupart de tes arguments

Vérité, raison, ... Oui évidemment ça n'est jamais que mon opinion et ça s'argumente, je t'invite donc à le faire. Tu contestes mes arguments ok mes lesquels et comment ? Parce que sur certains points c'est du factuel, le doublon des modules c'est pas une opinion c'est un fait, pareil sur la DI. Sur angular-cli OK ça c'est une opinion. L'usage abusif des classes ça aussi c'est une opinion encore que on est à mi-chemin.

Du coup voilà.

5/ il y a du taf avec Angular, ne t'en déplaise

J'ai pas dit le contraire, il y a du taf en France sur de l'Angular notamment dans les vieux départements informatiques de certains grands comptes mais si on regarde le tableau général à l'international (qui précède souvent la situation française de 5 ans environ) la situation est inquiétante. Si le state of js te suffit pas tu peux regarder les stats du registre npm. Sur 5 ans (ou all time) c'est très parlant, React bouffe tout et Vue a une croissance plus rapide (pas de beaucoup certes) que Angular.

Sur le même outil tu peux mettre en perspective le nombre de stars GitHub qui sont un bon indicateur de popularité et là c'est sans appel.

Du coup c'est quand même important de le dire aux gens qui se forment sur Angular, il y a danger.

[dukoid]

toujours pas d'accord !

[RPGamer]

Sur le même outil tu peux mettre en perspective le nombre de stars GitHub qui sont un bon indicateur de popularité et là c'est sans appel.

Du coup c'est quand même important de le dire aux gens qui se forment sur Angular, il y a danger.

Les tendances vont et viennent, les stars sur GitHub n'ont aucune valeur. Je n'ai d'ailleurs jamais mis la moindre star à un projet, mes projets ne sont même pas sur GitHub du reste...

Beaucoup d'entreprises utilisent en priorité des techno éprouvées et matures. Elles ne peuvent pas se permettre de basculer tous les 6 mois. Les tendances de popularité n'ont d'intérêt que pour le quidam qui souhaite faire quelques projets et expérimenter dans son coin. C'est un autre univers.