Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La version finale d'Angular 2.0 désormais disponible
L'équipe Angular évoque déjà les prochaines nouveautés et améliorations du framework JavaScript

Le , par Michael Guilloux

43PARTAGES

11  0 
Mise à jour le 15 / 09 / 2016 : La version finale d’Angular 2.0 désormais disponible, l’équipe Angular évoque déjà les prochaines nouveautés et améliorations du framework JavaScript

Deux ans après avoir été annoncé, Angular 2.0 est désormais disponible en version stable. La réarchitecture du framework JavaScript libre et open source développé par Google apporte des gains de performances énormes. Angular 2.0 devrait également permettre de développer les applications plus rapidement et les rendre plus maintenables. Mais la rupture avec la version 1 inquiète de nombreux développeurs. Pour faciliter la migration vers Angular 2, Google devrait donc publier un outil open source, déjà utilisé en interne, pour aider les développeurs à migrer semi automatiquement leurs applications, même en cas de changements de rupture. Il existe par ailleurs un guide de Telerik pour aider les développeurs à « convertir » leurs connaissances Angular 1 vers Angular 2.

L’équipe Angular évoque déjà les nouveautés et améliorations qui pourraient arriver bientôt dans le framework. Il s’agit entre autres des Web Workers qui devraient quitter la phase expérimentale, mais également d’Angular Material 2, une suite de composants de material design pour Angular 2. L’équipe prévoit aussi de travailler plus sur les animations et d’améliorer le support pour plus de langages, y compris Java et Go. Les développeurs pourront également disposer de plus de guides et exemples pour différents cas d’utilisation spécifiques d’Angular 2.

Sources : Blog AngularJS, Changelog (GitHub), Blog Juri Strumpflohner

La version 2.0 d’Angular, le framework JavaScript libre et open source développé par Google, vient d’atteindre la phase bêta. Ce qu’il faut noter dans cette nouvelle version, c’est une réécriture et une réarchitecture du framework qui ont permis d’introduire de nombreux avantages. Gain de vitesse impressionnant et de meilleures capacités de développement mobile sont ce qui caractérise Angular 2.0 dont la version finale est prévue au début de l’an prochain.

Angular 2.0 est beaucoup plus rapide qu’Angular 1. La vitesse du framework aurait été multipliée par huit, d’après Brad Green, directeur de l’ingénierie de Google en charge du framework. Ce gain de performance peut être observé au niveau du rendu et de la mise à jour des pages. En effet, la nouvelle version fournit un support pour accélérer le chargement initial des pages grâce à un prérendu côté serveur. Elle introduit encore une compilation hors-ligne et unique qui permet d’accélérer le démarrage des applications.

À cela, il faut ajouter un algorithme pour une détection ultra rapide des changements, que ça soit pour les grandes applications de bureau ou pour les applications sur les appareils à faible mémoire comme les téléphones mobiles. Comme autre expérience introduite avec Angular 2.0, vous pourrez exécuter tout votre code et une bonne partie du framework dans un processus séparé via des Web Workers, a expliqué Brad Green dans un billet le mois dernier. Au-delà des applications web pour bureau, Angular 2 a été conçu de sorte à bien fonctionner également pour les applications mobiles web, hybrides et natives.

Comme l’explique le directeur de l’ingénierie de Google chargé d’Angular, la phase bêta signifie que le framework peut être utilisé pour construire avec succès de grandes applications. Les développeurs peuvent donc dès maintenant envisager de construire des applications avec Angular 2 ou mettre à niveau leurs applications Angular 1 existantes. Google propose pour cela deux bibliothèques : ngUpgrade et ngForward.

La première bibliothèque permet aux développeurs de commencer à écrire des composants Angular 2 dans leurs applications Angular 1 existantes, et ensuite remplacer les composants Angular 1 au fur et à mesure qu’ils sortent de nouvelles versions de leurs applications. ngUpgarde facilite ainsi la transition entre les deux versions en permettant de tirer parti des avantages d’Angular 2 tout en conservant les fonctionnalités d’Angular 1. Les développeurs pourront par exemple profiter de l’amélioration de la vitesse et des API d’Angular 2 immédiatement alors qu’ils remplacent des composants Angular 1 pendant les sorties de nouvelles versions de leurs applications.

En ce qui concerne la deuxième bibliothèque ngForwrad, elle cible les développeurs qui, pour une raison ou une autre, voudront éviter d’avoir à la fois des bibliothèques Angular 1 et 2 exécutées simultanément dans leurs applications. ngForward vous permet d’écrire des applications Angular 1 en utilisant les conventions et styles d’Angular 2. Les développeurs pourront ainsi s’habituer à la nouvelle version, et auront beaucoup moins de travail à faire lorsqu’ils seront prêts à migrer vers Angular 2.


La bêta d’Angular 2.0 annonce aussi de manière imminente la sortie de la version finale. Pour cela, l’équipe de développement a déjà abordé la dernière ligne droite pour apporter quelques améliorations supplémentaires et faciliter l’apprentissage de la nouvelle version. On pourra citer dans leur liste de tâches les points suivants :

  • réduire la taille des binaires Angular ;
  • rendre la CLI (Command Line Interface) Angular utilisable tout au long du processus de développement ;
  • développer une API qui répond aux besoins des développeurs pour le Component Router ;
  • un support pour les animations ;
  • un support I18n et L10n ;
  • plus de documentation, en particulier sur l’utilisation d’ES5/ES6 ;
  • une meilleure performance de démarrage et d’exécution ;
  • un guide de style architectural ;
  • amélioration des tests unitaires et des tests de bout en bout ;
  • plus de support pour le web mobile et les applications mobiles installables ;
  • des composants Material Design pour Angular 2 ;
  • une plateforme d’outils pour un support d’IDE avancé ;
  • un meilleur support pour ECMAScript 6 et le compilateur Babel.


Page AngularJS pour commencer à apprendre la nouvelle version

Source : Blog AngularJS

Et vous ?

Utilisez-vous ce framework JavaScript ? Que pensez-vous de cette nouvelle version ?

Voir aussi

AngularJS : les développeurs dans le trouble au sujet de la version 2.0, quel va être l'avenir du framework JavaScript de Google ?
AngularJS : faut-il aller vers la version 2.0 ? Un point sur les coûts de migration vers cette nouvelle version
Angular 2 sera basé sur TypeScript : convergence de AtScript et TypeScript 1.5, c'est une collaboration entre Google et Microsoft

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 17/12/2015 à 16:05
Ca a l'air assez prise de tête de s'y mettre en tout cas.
Ca me fatigue tous ces tutos de frameworks qui commencent par 20 pages sur l'installation et l'utilisation de gestionnaires de dépendances, d'installeurs externes, de contrôle de version, etc.
Quand je m'intéresse à une nouvelle techno, je veux un bref aperçu de comment le langage fonctionne afin de savoir s'il peut m'intéresser, pas connaître de manière exhaustive comment gérer un projet de manière optimale.
6  0 
Avatar de rattlehead
Membre expérimenté https://www.developpez.com
Le 21/12/2015 à 15:13
Un truc qui n'a rien à voir. Par pitié essayer de faire un effort dans l'utilisation de sa et ça et de se et ce, s'il vous plaît
Dans des pavés ça commence à être dure à lire.
Merci les gars :-)
5  0 
Avatar de yann2
Membre expérimenté https://www.developpez.com
Le 03/03/2016 à 19:31
Citation Envoyé par p5yk0 Voir le message
Avec Angular Universal tu peux effectuer le rendu de ta page côté serveur.
Ça permet entre autres un chargement des pages plus rapide sur les terminaux les moins puissants (mobiles), une meilleure visibilité du point de vue des moteurs de recherche, une génération automatique de screenshot de ton appli, etc...
En gros, ce qu'on fait depuis des années avec PHP, JSP, ASP ou, soyons fous, CGI
6  1 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 03/03/2016 à 17:48
J'ai pas encore check la version 2 mais quelqu'un pourrait m'expliquer le coup du serveur ?

Normalement le cas usuel c'est un serveur qui expose des endpoints fournissant du json. En quelle techno ce serveur est écrit, qu'on soit en 1 ou en 2, on ne le sait pas forcément et ça n'a pas d'importance.

Du coup je comprends pas trop ...
4  0 
Avatar de voyager57
Membre du Club https://www.developpez.com
Le 16/12/2015 à 15:48
Ils essayent un peu de pousser l'utilisation de TypeScript, or j'aurais aimé utilisé le simple JS. J'attend de voir si cela ne pose pas de problème pour utiliser ce framework.
3  0 
Avatar de goldbergg
Membre actif https://www.developpez.com
Le 17/12/2015 à 9:01
Le rendu coté serveur sert aussi au référencement des page par google (entre autre) avec l'utilisation des ancres commençant par "#!" par exemple.
3  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 14/01/2016 à 14:50
Citation Envoyé par goldbergg Voir le message
Qui te dit que je pouvais me permettre de n'afficher qu'une seul partie de ma matrice a l’écran?
C'est marrant ces mec qui pense tous savoir de se que font les autres
Parce que tu étais sur smartphone ou en tout cas possiblement. Au boulot aussi on a une application avec un Gantt très riche limite en dessous de 27" tu n'y penses pas. Mais jamais j'aurais l'idée de comparer le portage de cette application sous smartphone.

En tout cas pas as-is et donc dans le contexte mobile, il n'y aurait pas des milliers d'éléments à afficher ou alors éventuellement je génère une image, etc. C'est bien là ou je voulais en venir avec la maîtrise de la conception et de l'architecture. Il faut mettre en relation et adéquation les contraintes techniques et fonctionnelles.

Citation Envoyé par goldbergg Voir le message
Après le résultat de merde obtenue (je rappelle que c'était il y a deux ans, depuis tout a évolué), je me suis bien évidement documenté sur ma technique a savoir si je m'y prenait bien ou pas (sachant qu'en vanilla j'avais en rendu 100x plus rapide), je suis même allé jusqu’à étudier les source de angular, analysé différent benchmark (et je passe encore très régulièrement sur jsperf pour suivre les évolution) et la conclusion que les framework du type angular consomme énormément et par conséquent ne sont pas adapter au appareil qui ont de faible ressource, elle ne vient pas que de mois, j'ai lue des article complet sur le sujet (et en même temps si on y réfléchie bien sa parait logique)

Mais bon, si on s'attarde a faire que des petit projet CRUD, oui je suis bien d'accord que sa passera probablement bien même sur un smarphone qui a 5ans.
Cela ne prouve toujours qu'une chose : ton cas d'utilisation ne correspond pas à un développement mobile.

Citation Envoyé par goldbergg Voir le message
Tu débarques en sortant se genre de phrase alors que visiblement tu n'a même pas chercher a comprendre on l'on voulais en venir
J'ai essayé de reprendre tous les "sujets" (je ne parle même pas d'arguments ici). Mais je vais détailler, tu me diras (si tu n'es pas trop fatigué) ce que j'ai mal compris et omis :
  • Citation Envoyé par Sodium Voir le message
    Ca me fatigue tous ces tutos de frameworks qui commencent par 20 pages sur l'installation et l'utilisation de gestionnaires de dépendances, d'installeurs externes, de contrôle de version, etc.
    Quand je m'intéresse à une nouvelle techno, je veux un bref aperçu de comment le langage fonctionne afin de savoir s'il peut m'intéresser, pas connaître de manière exhaustive comment gérer un projet de manière optimale.
    L'aperçu le plus bref c'est d'utiliser les outils qui te permettent d'aller rapidement à l'essentiel. Quand tu fais un tuto Java, tu te plains pas d'avoir à installer Eclipse, la JRE, Maven et tout le tralala. Surtout que si ce n'est pas trop mal foutu (surtout avec NPM & co.), tu récupère les sources, une commande pour préparer l'environnement et une dernière pour l'exécution.
  • Citation Envoyé par goldbergg Voir le message
    J'aurai bien un certain Node.js a pointer du doigt, qui pour moi n'a fait que complexifier la prise en main de certain framework (avec notamment l'utilisation de CLI, de gestionnaire de package, etc...) mais je risque de me faire huer pour sa ^^

    Elle était belle l'époque ou il y avait juste un zip a dl et une fois décompressé tout était prés a l'emploi! (bon encore heureux sa se faire encore)
    Au choix tu récupères NPM et tu joues trois commandes (et c'est même prêt pour les différents staging en cerise sur le gâteau), soit tu dl XXXX fichiers, que tu dois référencer, etc. Ou encore tu te paluches 3-4k lignes de code buggées pour arriver à la moitié du résultat. Tu choisiras la complexité que tu veux, mais le plus simple je pense c'est tout de même la première solution. Je me trompe ?
  • Citation Envoyé par Sodium Voir le message
    Ca fait bien partie des choses que je pointe du doigts.
    Quand l'apprentissage d'une technologie comme par 20 minutes à taper des commandes, installer les modules et remplir des fichiers de configs auxquels l'on ne comprend encore rien, il y a un soucis.
    Après une entrée en la matière rapide et l'exécution de quelques exemples simples, je vais peut-être me poser la question de l'utilisation des meilleurs modules, serveurs etc, pas avant.
    Au choix : écrire un tuto de 40 minutes pour chaque partie ou bien aller à l'essentiel et laisser le lecteur se documenter sur ce qu'il pourrait l'intéresser. Quand tu consultes un dictionnaire, tu t'attends pas à avoir l’encyclopédie pour chaque définition, non ?
    Sinon je vous laisse avec joie aller configurer PHP, JavaEE, IIS, Apache, etc. Et je parle même pas des Make ou autres. Les besoins en installation et de configuration, n'ont rien de neuf et beaucoup de choses ont été faites pour les faciliter.
  • Citation Envoyé par goldbergg Voir le message
    C'est vrais que c'est 100% plus rapide que :
    -Clique-droit => extraire-ici
    Sauf que ce n'est pas suffisant et ne correspond pas à toutes les étapes nécessaires. Donc oui, ouvrir mon frigo c'est plus rapide que d'aller faire les courses. Mais cela n'a pas grand chose à voir non plus.
  • Citation Envoyé par goldbergg Voir le message
    Je fais pas mal de site SPA sans Node.js* (d'ailleurs angular n'a pas besoin de Node.js pour fonctionner), coté serveur j'ai des WS REST, la techno on sans fous (généralement de l'ASP.NET Web API, mais sa peut tout autant être du PHP ou du JEE).
    Se qui ne me plais pas c'est qu'on nous impose tous se bazar...
    Non ce n'est pas imposer mais recommander pour certains usages et aller plus vite. Ce n'était pas d'ailleurs ce point de détail que tu pointais deux phrases plus tôt ? Et d'ailleurs, il t'a fallu combien de temps pour initier ton projet jusqu'au déploiement pour ton WS ? Et "Convention over configuration", ca te parle ? Oui si tu suis certaines conventions (ce n'est pas qu'une question d'organisation et de nommage des "unités de compilation", tu te taperas moins de configuration.
  • Citation Envoyé par goldbergg Voir le message
    pour tous dire Node.js j'en est fais un peux, je n'y est vue aucun intérêt vis a vis de la concurrence coté serveur (dans le cadre de mon utilisation bien sur), donc j'ai laissé tombé, en se qui me concerne l'ASP.net MVC est bien plus pratique et productif, sans compter le partage de ressource avec d'autre projet pas forcement web et l'interop.
    La praticité et la productivité ne se mesure qu'avec l'expérience sur un long moyen/terme. Même si je suis pas d'accord avec l'expression exacte mais ce n'est pas pour rien qu'on parle de "10x developper".
    Le partage de ressources meilleur sous une autre techno que JS ? Je crois que c'est un comble. Par nature même, tous les scripts sont meilleurs de ce point de vue. Et l'intérop se base uniquement sur des protocoles et historiquement et par nature, l'écosystème JS repose sur des échanges textuels avec des formats "légers" et ouverts.
  • Citation Envoyé par goldbergg Voir le message
    J'ai de plus en plus l'impression qu'aujourd'hui faire du JS signifie faire du Node.js se qui est archie faux... persso je distingue encore la partie cliente de la partie serveur et je trouve sa très importent que dans un site SPA le couplage sois le plus faible possible.
    Deux choses : NPM repose sur Node.js mais l'utiliser ne veut pas dire faire qu'on fait du développement côté serveur. L'idée c'est tout au plus de réutiliser les compétences pour améliorer ton propre environnement de travail. Si je pouvais me passer de scripts Batch/Shell et tout faire en Java, je m'en priverai pas !
    Deuxièmement, la séparation client/serveur n'est pas sans poser quelques soucis de duplication de code, de logique et de divergence. Certains projets n'en souffrent pas (pour différentes raisons qui passent par la gestion de projet à la nature même du projet) mais pour d'autres le non-couplage est moins évident.
  • Citation Envoyé par Sodium Voir le message
    Eh bien je ne sais pas pour les autres mais personnellement, je demande à comprendre ce que je fais, et ce n'est pas le fait d'exécuter une série de commandes qui vont faire 200 trucs automatiquement qui vont m'y aider.
    Encore une fois, je n'ai rien contre le fait d'améliorer son workflow autant que possible une fois qu'on est plongé dans le bain, mais pour commencer, donnez-moi une archive à extraire avec un Hello World pour que j'ai une vague idée de ce que fait la techno et comment.
    Dans ce cas faut pas regarder les tutos mais les exemples. Ou changer de tutos si le niveau requis ne te semble pas en adéquation. Néanmoins de mon expérience (et je lis pas mal de tuto en diagonale), les commandes sont relativement simples et leurs intentions très claires. Et si je comprends pas quelque chose ou que j'ai un doute, je consulte la ressource qui m'apportera au mieux le type de réponse que j'attends : le manuel de référence, le "man", un tuto, etc.
  • Citation Envoyé par goldbergg Voir le message
    Pour une entreprise (ou un simple dev) qui est habituer a utiliser différent framework ou libs, oui c'est très bien, perso si je n'utilise pas npm dans node.js, mais j'utilise souvent nuget dans VS.
    Mais là on parle de la mise a disposition de framework seul, donc soit y a qu'un seul fichier, soit une archive avec tous se qu'il faut de fournie.
    Sauf qu'un framework peut en dépendre d'autres.
  • Citation Envoyé par goldbergg Voir le message
    Angular 2, tu doit telecharger et installer Node.js, puis tu installer npm, puis pianoteer quelque commande, etc... avant même de toucher a du code on se retrouve a configurer toute un tas de chose pas forcement utile sur l'instant.
    Non tu peux comme Angular 1 si ca te chantes mais tu n'en tiras pas tous les bénéfices. Quand tu suis un tuto C#, tu te plains pas d'avoir installer VS et son lot de composants ? Alors pourquoi chouiner sur deux applications de 10 Mo ? Dont l'une ne tient qu'en un seul fichier exécutable et le tout s'installe en deux clics !
    Je fais même pas la comparaison avec Java, c'est imbattable
  • Citation Envoyé par goldbergg Voir le message
    Et malheureusement angular n'est pas le seul, j'avais voulu tester la lib web de google (Web Starter Kit), je ne sait pas si sa a changer depuis, mais j'avais été obligé d'installé Node.js ainsi que gulp pour pouvoir tester alors que c'est juste une lib material design sans aucune logique.
    Bientôt juste pour récupérer un bout de code sur stackoverflow ou codepen il faudra passer par npm
    Non tu ne seras pas obligé mais l'avantage c'est que tu peux déjà presque le faire
  • Citation Envoyé par goldbergg Voir le message
    Bref se que je dit c'est que l'utilisation de toute cette machinerie devrait être un choix du dev et non de l’éditeur du framework, pas que les outils ne servent a rien.
    Le choix tu l'as. Ces outils ne font que de la manipulation de texte, te prépares et exécutes des choses pour toi. De sortes qu'en une seule commande de l'outil, tu t'économises des centaines de manipulations manuelles.
  • Citation Envoyé par goldbergg Voir le message
    Et les solution alternative sa te parle?
    Si tu as les moyens de les développer, pourquoi pas. D'ailleurs c'est un peu le principe de l'Open-Source, libre à chacun de contribuer à sa manière. Et certains se "spécialisent" dans l'intégration avec d'autres outils. Mais il faut pas toujours s'attendre à un haut niveau de maturité, d'investissement, etc. même si certaines alternatives deviennent meilleures que les solutions/intégrations originales.
  • Citation Envoyé par goldbergg Voir le message
    Et l'envie d'utiliser le framework juste pour ou apprendre ou tester des chose sans faire de test ni de gestion de source c'est interdit en 2015? (sa veut dire quoi sa "un framework professionnel"?, théoriquement n'importe qu'elle framework l'est).
    Et l'intérêt du choix il est ou dans ce cas ? Sinon un framework "professionel", c'est un framework industrialisable.(ou industrialisé ?), il correspond aux critères de sélection d'une entreprise pour une mise à disposition à grande échelle.
  • Citation Envoyé par goldbergg Voir le message
    On est censé maîtriser un framework des notre premier utilisation?
    Je pense pas que quelqu'un est dit cela ... Mais il y a tout de même toujours un minimum à connaître.
  • Citation Envoyé par goldbergg Voir le message
    Se que j’accuse c'est justement cette façon de nous imposer notre façon de faire, le choix des outils, etc... c'est quand même pas difficile a comprendre?
    Ce qui est difficile à comprendre c'est déjà se besoin d'avoir le choix ... et de critiquer son absence quand il existe mais aussi de ne pas assumer ce choix : "on nous reommande des outils mais c'est trop long sans" ... Si tu tiens les deux côtés de la corde, faut pas s'étonner qu'elle ne bouge pas ! Si on te sort un argument dans un sens, tu sors un argument dans l'autre camp.
  • Citation Envoyé par goldbergg Voir le message
    Et y a une différence entre un framework et les bonne pratique d'utilisation ainsi que les outils recommandé...
    Il y a une différence entre un framework, les bonnes pratiques et les outils recommandés ? Soit tu as mal exprimé ton idée, soit c'est toi qui est à côté de la plaque. La force d'un framework c'est autant ses fonctionnalités et que son utilisabilité.
    Sinon tout au plus c'est une lib comme une autre.
  • Citation Envoyé par goldbergg Voir le message
    Npm, Node.js etc... ne font pas partie du framework angular, sa n'est juste que des outils qui peuvent être remplacer par d'autre, en l'occurrence visual studio permet aussi de créé un projet angular sans npm, node.js & cie.
    Preuve en est que des alternatives existent mais tu dois bien avouer que VS ne doit pas être l'outil le plus répandu chez les utilisateurs d'Angular 1/2 ? Là, l'éditeur du framework te propose un outillage facile à intégrer même dans une ligne de commande. Et il ne faut pas confondre l'abscence d'alternative avec l'impossibilité d'en avoir.
  • Citation Envoyé par frfancha Voir le message
    C'est justement là qu'on est pas d'accord: ces tâches PEUVENT être exécutées par des tasks runners écrits en JS mais ne DOIVENT pas l'être.
    Soit c'est mal dit, soit c'est idiot (désolé mais voir juste ci-dessous).
  • Citation Envoyé par frfancha Voir le message
    Par exemple si dans mon process le minify se fait dans un Bundle en visual studio, pourquoi faudrait-il changer cela pour le remplacer par grontgulglopglip pour utiliser angular.
    Simplement parce que la solution visual studio n'est pas industrialisable et intégrable dans une chaîne de livraison.
  • Citation Envoyé par frfancha Voir le message
    Node.js + grontgulglopglip est UNE façon de développer mais ce n'est pas la seule (heureusement), et le fait de "l'imposer" (parce que toutes les aides et tutoriaux sont basés dessus) me semble malsain (ainsi qu'à quelques autres intervenants semble-t-il)
    Parce que personne n'a mis les moyens (ou envie de les mettre) pour mettre en place une solution alternative sans valeur ajoutée. Si tu parles des papiers officiels, ils peuvent pas prévoir tous les cas d'usages mais t'offrent une façon de travailler qui s'intègre à tous les environnements (ligne de commande, IDEs favoris, serveur d'intégration continue, etc.).
    Ce qui me semble malsain, c'est de ne pas s'en rendre compte.

    Si cela concerne les autres sources (outre les mêmes raisons qui s'appliquent), sachez que Developpez.com accueillera très favorablement et avec beaucoup de plaisir vos tutoriaux. Mais sachez aussi que vous toucherez surement un public moins grand qu'en étant plus "ouvert" (par opposition à "imposer" ).
  • Citation Envoyé par goldbergg Voir le message
    Hum, bien qu'il y est un menu déroulant permettant de choisir JavaScript plutôt que TypeScript, je trouve que se choix par défaut va aussi à l'encontre de se que tu dit sur les mauvaise pratique.
    Après tous TypeScript n'est rien d'autre qu'une surcouche dégueulasse et contre-nature du JavaScript au yeux d'un puriste apprécient le JavaScript pour se qu'il est! On pourrait même sentir une sorte d'insulte au JavaScript en proposant un langage plus proche de la POO par class que de la POO par prototype. (bien évidement sa n'est qu'une façon de penser, chacun l'entend comme il le veut)
    L'idée c'est d'apporter des structures plus déclaratives (et donc statiques) contrairement à la nature dynamique de JavaScript. Et donc plus lisible et plus sûr (ajout de contrôles statiques) et par conséquent plus maintenable.
    Bien évidemment cela n'est qu'une façon de penser mais c'est presqu'un critère de choix plus qu'une simple fonctionnalité.
  • Citation Envoyé par goldbergg Voir le message
    Sa m'en vient a formuler une autre remarque, je veut bien que sa soit une mauvaise pratique pour qui veut partager ses source (sur Git par exemple) de ne pas utilisé les outils recommandé, mais pour n'importe qu'elle éditeur de logiciel et/ou SSII, les bonne pratique sont imposé par l'entreprise et non par des bien pensant sur le web qui proposent/impose leurs façon de penser et je rappelle que la majorité des entreprise ne fait pas d'open-source (pas besoin d'être un génie pour comprendre pourquoi), donc bien formater sont projet pour pourvoir plus facilement le partager, on sans fous royalement, se qui importe c'est que les convention de l'entreprise soit respecter (se qui peut inclure d'utiliser un IDE plutôt que les outils de base). Et j'en profite pour rappeler que dans bon nombre d'entreprise on ne nous laisse ni choisir l'OS, ni l'IDE et/ou outils de dev, dans se cas là, a quoi bon apprendre avec npm ou encore TypeScript si au final on aura même pas la possibilité de l'utiliser.
    A ton avis d'où sortent toutes les conventions et choix d'outils proposés/imposés dans les entreprises ? Sur quels critères ces choix sont-ils fait ?
    Et si stratégiquement les entreprises décident d'utiliser Angular 2, stratégiquement elles adopteront les outils qui vont avec. Comme les entreprises qui utilisent Java ce sont mis à Ant, puis Maven et aux Servlets. Ce sont des technologies qui s'imposent par stratégie et non par contraintes. Excepté si tu considères la facilité comme une contrainte, mais c'est l'histoire du verre à moitié vide ou à moitié plein.
  • Citation Envoyé par goldbergg Voir le message
    Et par malsain, bien que sa n'est pas moi qui est utilisé se terme, se que j'entend, c'est que pour quiconque qui débarque, on ne leurs dit pas "vous avez tel ou tel choix" (comme c'était le cas pour angular 1), mais juste "installe npm", comme si c'était la seul chose logique a faire. Et sa, surtout pour une plateforme qui a une grosse communauté de linuxien, je trouve que sa va profondément a l'encontre de la philosophie du libre choix (vue que même si au final on a le choix, on nous le masque au première abord).
    Ce qui est ironique c'est que le choix, c'est ce qui a causé du tord Angular. Et que les évolutions de la technologie et sa présentation (guide, tutorial, référence) ont été conduit par justement être plus directif parce que sinon les gens optaient pour de mauvaises pratiques et donnaient une mauvaise image du framework (ex - presque au hasard - : saturé l'IHM de 1500 éléments).

    Commencer par maîtriser les choses basiques me semblent une approche pas trop idiote avant de continuer avec des choses plus freestyle mais dont il faut maîtriser l'usage. Il faut pouvoir être capable d'assumer ses choix. Et quand on débute, on le peut pas.
  • Citation Envoyé par goldbergg Voir le message
    C'est juste qu’après de nombreuses année a dev en JS (je fais su SPA depuis ~2011) a utiliser différente lib et framework ou sa se résumé simplement a dl un fichier sur un site et c'est tous, depuis que l'arrivé de npm, on nous redirige systématiquement vers cette plateforme (sans compter les autre outils qui vont derrière tel que grunt par exemple) avec se sentiment que quelqu'un cherche forcer notre changement d'habitude.
    Il serait idiot de se passer d'un facilitateur. Surtout si dans le cadre d'un article, ca te permet d'initialiser le projet en un rien de temps. Et il y a fort à parier qu'une bonne partie des lecteurs connaissent ou soient amenés à connaître.
  • Citation Envoyé par goldbergg Voir le message
    A croire qu'un dev JS se doit obligatoirement de passé a tous sa et que le temps ou un simple Notepad couplé a n'importe quel navigateur suffisait pour coder en js et terminé...
    Je pense que c'est quasiment le cas. Notepad ca dépanne parce que c'est installé partout mais aujourd'hui il faut un minimum d'outillage pour travailler convenablement que ce soit la mise en forme (ex : coloration syntaxique), le formattage, l'autocomplétion, l'analyse statique, etc.
  • Citation Envoyé par goldbergg Voir le message
    Sa me fait ressentir la même chose de se qui est arrivé il y a quelque année avec jQuery avant le retour en force de Vanilla, ou a chaque fois qu'on cherchais un tuto ou un bout de code sur le net c'était forcement du jQuery..., comme si sa n'était plus possible de dev sans...
    Il y a des techniques ou technologies qui s'imposent. Quand 90% des projets reposent dessus, ca me paraît pertinent que 90% des questions, tutoriaux, etc. reposent également dessus. Surtout quand tu peux exprimer en 3-4 lignes ce qu'il faudrait faire en 10-20 lignes de code purement natif.
  • Citation Envoyé par goldbergg Voir le message
    Et sinon, désolé mais non, tous les éditeur n'on pas un repo sur git d'accessible, donc que les source soit disponible n'est pas une évidence (faut arrêté de penser que tout est open-source!) et pour beaucoup de logiciel dispo sous Linux, on nous propose généralement de DL les source sans passer par un repo, je vois pas pourquoi en JS sa ne serais pas/plus le cas.
    un FTP, CDN, un serveur HTTP x/y, Git ou autre, ca reste des dépôts. L'avantage de GitHub c'est juste sa facilité de déploiement et d'accès ainsi que sa popularité. Faut pas de leurrer la plupart des projets sont hébergés sous GitHub.
  • Citation Envoyé par melka one Voir le message
    je pense que ce qui est mis en avant c'est qu'il n’existe que des tuto a base de npm & co ce n'est pas une négation envers cette mouvance mais l'impression qui en ressort impose de faire de cette façon et pas une autre.
    Si je te dis que "Pour aller de Toulouse à Paris, passes à l'autoroute A20". T'as l'impression que je te l'impose ou simplement que c'est le choix le plus logique. Peut-être que tu préfères que je t'énumères tous les trajets possibles ? Si c'est le cas compte pas sur moi, et je pense que c'est pareil pour toi.
    S'il suffit qu'on vous présente une façon de faire, pour croire que c'est la seule. Le problème n'est pas du côté de la source.
  • Citation Envoyé par Sodium Voir le message
    Un premier problème que je vois avec cet approche, c'est que les ressources sur AngularJS deviennent dépendantes d'autres technologies amenées à changer, disparaître ou être remplacées. Il m'est déjà arrivé de perdre plusieurs heures sur un tuto parce qu'il introduisait le sujet avec des informations obsolètes. Pour moi, la manière de générer un projet avec un programme tiers, aussi populaire soit-il devrait être ajoutée à titre informatif et facultativement.
    Bienvenue dans le monde de l'informatique ou dans le monde des sciences/technologies de manière générale. Tu trouveras encore également beaucoup de livres qui parlent de la machine à écrire Je suis gentillement moqueur mais c'est bien ainsi qu'est fait notre société. Internet est très facile d'accès et les choses(techniques et technologies) évoluent.
    Pour être productif/clair à une époque, on utilise les outils et méthodes disponibles à ce moment là. Par exemple, le design pattern Singleton a fait son temps mais tu devrais plus le trouver dans un écrit récent. L'obsolescence est inévitable, tout va très vite alors on s'appuie sur des choses qui permettent d'aller vite.
  • Citation Envoyé par Logan Mauzaize Voir le message
    Après on oblige à rien mais d'un côté on se plaint de ne pas pouvoir faire les choses rapidement mais de l'autre on se plaint de l'utilisation d'outils qui permettent d'aller plus vite
    Cela résumait mon premier message et résume aussi celui-ci.


Pour compléter, j'ai juste l'impression d'enfants qui découvrent le monde de l'entreprise et l'industrialisation de notre métier. Je prone depuis mon arrivée sur le monde du travail pour l'outillage et si possible existant publiquement.
Les outils ne sont pas indispensables mais essentiels. Et dans un contexte économique, oui essentiel est l'égal d'indispensable.
3  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 15/01/2016 à 1:22
La première chose dont il faut se soucier en matière de performances sur un projet web, c'est le réseau. La RAM ou le CPU du client sont des données complètement négligeables, le temps de traitement des données côté client ne représentant qu'une toute petite fraction du temps de requête. Même sur un smartphone bas de gamme, trier/filtrer 10.000 objets prend 100 millisecondes tout au plus, avec Angular ou autre chose. En revanche, télécharger les données de ces 10.000 objets prendra plusieurs secondes. C'est d'ailleurs un des arguments principaux du templating client: alléger les requêtes en faisant transiter des données sérialisées et non préformatées.

Généralement, je charge jusqu'à 500ko max de données par requête client. Au delà, je pagine côté serveur. Ce qui n'empêche pas de garder un cache des données côté client et de venir charger progressivement le reste à la demande de l'utilisateur.

Pour votre histoire de milliers de bindings à gérer, on a déjà trouvé une solution à ce problème, ça s'appelle la pagination virtuelle : http://www.ag-grid.com/angular-grid-...irtual-paging/ ; c'est le meilleur des mondes, plein de données sur une seule page mais un DOM et des bindings réduit à la portion de la page que voit l'utilisateur sur son écran.
3  0 
Avatar de wchegham
Membre habitué https://www.developpez.com
Le 20/03/2016 à 13:38
Hello,
ravi de voir qu'on commence à parler d'Angular 2 (tout doucement mais certainement) ^^

Je suis contrib et membre de l'équipe Angular 2 Universal. Effectivement, un des problèmes traités par Universal c'est le chargement de la première page. Mais pas que, il y a aussi la SEO et l'expérience utilisateur et surtout la gestion des "states" lors du chargement de l'application.

Je parle de tout ça dans mon talk : http://slides.com/wassimchegham/angular2-universal

Pour le moment, on se concentre principalement sur Nodejs. Mais on a en tête d'autres technos comme PHP, Java ou encore .Net. Ou n'importe quelle platform avec un bridge JS/V8

Jeff et Patrick donneront un talk à la ng-conf sur l'avancement du projet, si vous voulez en savoir plus.
3  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 08/05/2016 à 15:50
Citation Envoyé par devwebsympa Voir le message
Le succès d'angular 1 a été provoqué par le développeur, qui a créé son nouveau framework, Aurélia.
La raison du succés aux usa fut le concept MVC pour Javascript et le 2 way binding(même si c'est pas forcément terrib').

Moi je vais donc suivre le développeur à l'origine du succès d'angular 1 et je feras donc du aurélia.
Rob Eisenberg n'a jamais bossé sur Angular 1... Il bossait sur Durandal avant, et a joint l'équipe d'Angular 2 en février 2014 : http://eisenbergeffect.bluespire.com...aving-angular/

Malheureusement, raconter n'importe quoi n'est pas une infraction sur ces forums, c'est juste fatiguant pour tout le monde.
5  2