Bill Fassinou 
Angular n'a rien avoir avec angular.js => oui en effet, mais c'est juste parce que angular est différent, rien à voir avec le changement de langage. Angular aurait pu tout aussi bien être écrit en JavaScript.Envoyé par RPGamer
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Angular n'a rien avoir avec angular.js => oui en effet, mais c'est juste parce que angular est différent, rien à voir avec le changement de langage. Angular aurait pu tout aussi bien être écrit en JavaScript.
Commence par lire la documentation de TypeScript, ce que je t'explique y est écrit en gros dès la home du site de TypeScript.
Concernant la team Angular, tu confonds le choix d'aller vers une conception fortement orientée objet par classes avec le choix d'un outil qui ajoute du typage statique en ajoutant une phase de compilation.
La manière dont la team Angular utilise TS, et qui est fortement discutable, est propre à cette team. Ce n'est pas nécessairement de cette manière qu'il faut utiliser TS. Les auteurs de TS l'ont déjà expliqué à plusieurs reprises.
D'ailleurs je te ferai remarquer que de très nombreuses teams utilisent React avec TypeScript alors que la conception de React est fortement orientée prog fonctionnelle et que Vue dans sa version 3 intégrera TS out of the box (Vue est agnostique question paradigme).
Il ne restera plus rien comme petit avantage concurrentiel à Angular, d'où l'énorme gamelle qu'il se ramasse. Comme d'hab on a quelques années de retard en France sur ce sujet mais c'est la tendance lourde observée depuis 2 ans maintenant dans le reste du monde.
Perso je suis sorti d'Angular dès que j'ai pu ... Mais j'adore TypeScript... Mais malheureusement il est mal compris et encore plus mal utilisé
Il fait ce que fait Babel en supportant les dernières fonctionnalités de JS et en permettant de target une version obsolète de JS pour supporter tous les navigateurs possibles et imaginables.
Et en plus de cette feature il ajoute du typage statique.
Voilà, il ne fait rien de plus (enfin c'est déjà beaucoup).
Il s'agit donc littéralement de JS + typage statique. Ça ne sert à rien d'argumenter ce n'est pas une opinion c'est un fait.
Comme le dit très justement defZero, TS est bien un superset de JS, ça signifie que ça n'est justement pas du JS, mais que tout code JS est en principe du code TS valide, c'est tout.
Les décorateurs ont été ajouté par le team TS à la demande de la team Angular précisément, marquant la fin prématurée du projet AtScript et ce qui rend sont approche complétement différente de JS d'ailleurs.
Angular propose déjà tous les outils et l'architecture élégante d'une app out of the box en TS justement, c'est en ça qu'il est le seul réel framework, qui se suffit à lui-même. React n'est qu'une bibliothèque. Ils ne jouent donc pas du tout dans la même catégorie, et c'est la confusion que tu fais et qui est faite dans cet article.
C'est pas "en principe", c'est une règle. Et la seule chose qui diffère entre JS et TS c'est le système de typage.
Les decorators sont en stage2 au TC39. Ça finira par devenir du JS vanilla. Ça arrive régulièrement qu'une feature qui n'est pas encore terminée pour JS soit intégrée en avance de phase. Dernier exemple en date l'optionnal chaining.
tsc fait aussi le boulot de Babel, c'est peut être ça qui crée la confusion dans votre esprit. Tu peux retrouver les décorateurs dans un code JS avec Babel et le plugin qui va bien. Mais tu vas peut être tenter de m'expliquer que du JS généré par Babel "n'a rien à voir" avec JS ?
Oui l'écosystème React est un peu bordélique et il faut assembler brique par brique pour avoir l'ensemble de l'équivalent des features proposées out of the box par Angular, mais on parle de seulement 3 ou 4 briques. Pour avoir l'équivalent d'un Angular t'as besoin du core, d'un routeur, d'un state manager et basta dans 95% des cas. Et apparemment c'est cette approche qui est privilégiée par la communauté JS puisque c'est Angular qui se casse la gueule, React qui a gagné et Vue qui creuse gentiment son trou.
Après le débat framework vs lib, j'ai eu ce genre de questionnements il y a quelques années, j'en arrive à la conclusion que c'est une question sans importance parce que la communauté a tranché. Vue a pris la même approche que React, tu tires les dépendances dont tu as besoin plutôt que de te retrouver avec une usine gaz qui contient plein de choses inutiles pour toi.
La différence est colossale.Et la seule chose qui diffère entre JS et TS c'est le système de typage.
Il n'y a pas de débat, ce sont bien deux concepts définis et différents et la question est fondamentale et globale (bien au-delà de TS ou JS). L'approche framework permet justement de tenir des projets importants de façon cohérente, auto-documentée, etc. et même si l'approche bordélique de React ou NPM s'est beaucoup développée récemment (à cause du sentiment de liberté produit par ce bordel justement), il ne s'agit que d'un effet de mode. On ne peut rien construire de pérenne et fiable sur du bordel et de la confusion. Ca rejoint l'un des premiers commentaires qui questionne où en serons-nous dans 5 ans.Après le débat framework vs lib, j'ai eu ce genre de questionnements il y a quelques années, j'en arrive à la conclusion que c'est une question sans importance
Tu continues à confondre TS et JS, framework et bibliothèque, AngularJS et Angular. Ces concepts sont totalement distincts. Ses outils ne sont pas comparables. React ne gagne rien et Angular ne se casse rien. Angular reste le framework le plus plebiscité par la communauté (notons quand même la confusion AngularJS/Angular de l'article), tout domaine de développement confondu et n'a aucun rapport avec l'abandon d'AngularJS faisant chuter son usage.Et apparemment c'est cette approche qui est privilégiée par la communauté JS puisque c'est Angular qui se casse la gueule, React qui a gagné et Vue qui creuse gentiment son trou.
Pourquoi des outils et des plugins additionnels tiers alors qu'on peut l'avoir de facto? Encore du bordel en plus.tsc fait aussi le boulot de Babel, c'est peut être ça qui crée la confusion dans votre esprit. Tu peux retrouver les décorateurs dans un code JS avec Babel et le plugin qui va bien. Mais tu vas peut être tenter de m'expliquer que du JS généré par Babel "n'a rien à voir" avec JS ?
Je suis surpris que la côte d'Angular dégringole à ce point !
C'est que c'est un framework exigeant qui demande beaucoup de temps et d'efforts avant de commencer à travailler avec. J'ai d'ailleurs renoncé à l'imposer au sein de mon équipe pour ne pas gréver le projet, on est plutôt parti sur une solution bateau : Spring Java + Thymeleaf + Bootstrap + JQuery. Le projet terminé on ne regrette pas ce choix car tous le monde s'y est senti très à l'aise dès le départ et dans ce cas de figure c'est le prinicpal. Après même si les autres frameworks JS sont plus intéressants sur le papier il manquera toujour les nombreuses bibliothèques de composants dédiés de qualité pro dont Angular est richement doté et ça celà n'a pas de prix lorsqu'on developpe pour les entreprises.
solution que j'ai opté pour quelques projets et je ne l'ai pas regretté.
l'appel ajax de fragment est intéressant et il y a quand même possiblité de faire du code propre
tu veux dire des bibliothèques de composant graphique pour angular?
je trouve que c'est quand même assez pauvre quand on regarde smartclient, extjs...
@marc.collin
il y a le material design de google https://material.angular.io/
et bien sur, les bootstrap 4 etc...
@Jitou
concernant le choix : Spring Java + Thymeleaf + Bootstrap + JQuery.
donc tu n'avais pas besoin d'un site dynamique et donc pas besoin d'un framework js
je ne trouve pas qu'Angular demande beaucoup d'investissement d'apprentissage.
faut juste comprendre le système des web composant, qui au final fait gagner du temps par sa re-utilisabilité
et la communication entre composant (parent-enfant et enfant-parent)
le reste : routing, form, services, model... c'est pareil que n'importe quel autre framework MVC .... (à la syntaxe près)
Angular est surtout compliqué parce qu'il n'y a pas de guidelines claires et précises sur la bonne façon d'organiser un projet.
c'est pourtant claire, c'est du web composant en MVC
MVC, classique sur de nombreux framework ... je ne vois pas ce qu'il y a de compliqu" à comprendre....
au pire, il y a des tutos, des forums comme ici heiin quand on ne comprends pas... les forums c'est pas seulement pour le plaisir de contredire tout le monde AH AH AH
Bien sûr que si, et même plus, un style guide rigoureux et justifié point par point: https://angular.io/guide/styleguide
c'est totalement en dessous de smartclient et extjs (sencha)
sencha a d'ailleurs fait ext angular pour pallier à ce manque
c'était la même chose quang gwt est sortie... très pauvre en composant, fallait prendre gxt( sencha) ou smartgwt pour avoir une richesse à ce niveau
en quoi qu'utilise ces technos ne permets pas d'avoir un site dynamique?
c'est justement un des points qui mis en son désavantage, la courbe d'apprentissage qui est assez élevé
j'en ai fait et ça été le premier point que j'ai négatif, sans compté le nombre de ligne de code à écrire pour faire pas grand chose
la roue est trop souvent réinventer en web pour pas vraiment de gain
en composant graphique GRATUIT !
en payant, il y a aussi :https://primefaces.org/primeng/#/
jQuery pour faire du dynamique .... ok je me rends !
le nombre de code pour pas grand chose ... ?????
---> c'est du déliredu grand n'importe quoi
j'ai testé React et Angular, je préfère Angular.
Je trouve qu'Angular est injustement trollé comme le fait principal qu'on lui reproche est qu'il soit fermé.... c'est faux.
Ensuite les versions, tous les 6 mois il y a une nouvelle version .... c'est exact, mais cela ne casse pas la compatibilité entre les versions 4, 5, 6, 7, 8, 9....
(avec une commande, on upgrade facilement et si jamais il y a une chose à modifier, c'est indiqué en warning...)
avec Angular 9 et le nouveau moteur ivy qui va permettre des performances au top et une taille minimale optimisé aux petits oignons j'espère que ça va reprendre du poil de la bete ....
sinon, je trouve pathétique la gueguere genre mon framework, mon langage est mieux que le tiens...
pour moi, tous les framework et langages se valent.
bien sur, il y a des petites différences, certains sont plus destinés dans un domaine que d'autres.
bien sur, certains ont des avantages ou inconvénients
MAIS AU FINAL, ils font tous le job. C'est bien là le principal, non ?
mais bon.... je vous laisse vous chamailler comme des gamins
Encore un débat aussi constructif qu'un avis sur la meilleure voiture du moment...
Dommage qu''on ne voie pas de spots publicitaires sur Javascript à la télé, ce serait drôle de voir ce que les marketeux pourraient nous pondre ...
Ma page Developpez - Mon Blog Developpez
Président du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts)
Deux règles du succès: 1) Ne communiquez jamais à quelqu'un tout votre savoir...
Votre post est résolu ? Alors n'oubliez pas le Tag
Venez sur le Chat de Développez !
Une voiture, chacun prend celle qu'il a envie et c'est marre.
Au niveau des langages, les erreurs de conception nous impactent tous au quotidien, rendant notre travail beaucoup plus difficile que ce qu'il ne devrait l'être, il y a donc de quoi susciter des débats passionnés.
Pour la voiture le choix n'est pas uniquement issu de l'envie, loin de là, c'est bien plus complexe, il y a bien d'autres facteurs qui entrent en ligne de compte.
Un choix n'est pas toujours issu d'une logique implacable. Chacun sa "stratégie" de choix.
Il n'y a plus qu'à créer une AI pour déterminer quel est le meilleur langagevu que visiblement l'humain n'est pas capable d'arriver à un consensus, mais du coup il aurait sans doute un parti pris
Ma page Developpez - Mon Blog Developpez
Président du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts)
Deux règles du succès: 1) Ne communiquez jamais à quelqu'un tout votre savoir...
Votre post est résolu ? Alors n'oubliez pas le Tag
Venez sur le Chat de Développez !
le but d'une voiture c'est d'aller d'un point A à un point B
toutes les voitures offrent se service.
le but d'un langage ou framework est de concevoir une application
tous les langages/framework offrent ce service
Venant d'Angular je trouve à titre personnel que c'est enfin le moment où le framework atteint une période de maturité et qu'il devient accessible (doc au top) à tous... qu'il est délaisse. Alors qu'il y a encore quelque temps tout le monde se jetait dessus alors qu'il y avait des patchs majeurs tous les 6 mois qui impliquaient toujours des incompatibilités de code qui étaient assez insupportable pour une montée en compétences sereine sur le framework. C'est un peu étrange et étonnant de mon point de vue mais le fait que je maitrise désormais bien l'environnement doit forcément biaiser mon opinion.
L'avantage certain que je vois avec React c'est une intégration au top sur le mobile avec React native qui fait du natif justement alors qu'on ne peut en dire autant sur ionic pour angular... qui pour le coup est assez incontestablement derrière son concurrent.
Merci pour ces remarques très constructives.
Perso, ça ne me choque pas qu'un topic sur "l'état de JS et de ses frameworks" discute des différents frameworks JS... En fait, je trouve même ça plus constructif que d'en choisir un au pif ou de perdre du temps à les tester tous.
Répondre avec citation
Partager