Pour reformuler ce que je pense que la question du PO est vraiment:
Si je crée une application principalement dans Angular 1.x, et (implicitement) à l'ère de Grunt / Gulp / Broccoli et Bower / NPM, et que j'ai peut-être quelques dépendances de bibliothèque supplémentaires, faut-il ajouter clair, spécifique valeur au-delà de ce que j'obtiens en utilisant Angular sans exiger?
Ou, autrement dit:
"Vanilla Angular a-t-il besoin de gérer efficacement le chargement de composants Angular de base, si j'ai d'autres moyens de gérer le chargement de scripts de base? "
Et je crois que la réponse de base à cela est: "pas à moins que vous ayez quelque chose d'autre en cours et / ou que vous ne puissiez pas utiliser des outils plus récents et plus modernes."
Soyons clairs au début: RequireJS est un excellent outil qui a résolu des problèmes très importants et nous a lancé sur la voie que nous suivons, vers des applications Javascript plus évolutives et plus professionnelles. Surtout, c'était la première fois que de nombreuses personnes rencontraient le concept de modularisation et de sortir les choses de la portée mondiale. Donc, si vous allez créer une application Javascript qui doit évoluer, alors Require et le modèle AMD ne sont pas de mauvais outils pour le faire.
Mais, y a-t-il quelque chose de particulier dans Angular qui fait de Require / AMD un ajustement particulièrement bon?Non. En fait, Angular vous propose son propre modèle de modularisation et d'encapsulation, qui à bien des égards rend redondantes les fonctionnalités de modularisation de base d'AMD. Et, l'intégration de modules angulaires dans le modèle AMD n'est pas impossible, mais c'est un peu ... capricieux. Vous passerez certainement du temps à bien intégrer les deux modèles.
Pour une certaine perspective de l'équipe Angular elle-même, il y a ceci , de Brian Ford, auteur de l'Angular Batarang et maintenant membre de l'équipe de base Angular:
Je ne recommande pas d'utiliser RequireJS avec AngularJS. Bien que ce soit certainement possible, je n'ai vu aucun cas où RequireJS a été bénéfique dans la pratique.
Ainsi, sur la question très spécifique d'AngularJS: Angular et Require / AMD sont orthogonaux et se chevauchent par endroits. Vous pouvez les utiliser ensemble, mais il n'y a aucune raison spécifiquement liée à la nature / aux motifs d'Angular lui-même.
Mais qu'en est-il de la gestion de base des dépendances internes et externes pour les applications Javascript évolutives? N'exige-t-il pas de faire quelque chose de vraiment critique pour moi là-bas?
Je recommande de consulter Bower et NPM, et en particulier NPM. Je n'essaie pas de déclencher une guerre sainte au sujet des avantages comparatifs de ces outils. Je veux simplement dire: il existe d'autres façons d'écorcher ce chat, et ces façons peuvent être encore meilleures que AMD / Require. (Ils ont certainement un élan beaucoup plus populaire fin 2015, en particulier NPM, combiné avec des modules ES6 ou CommonJS. Voir la question SO connexe .)
Et le chargement paresseux?
Notez que le chargement différé et le téléchargement différé sont différents. Le chargement paresseux d'Angular ne signifie pas que vous les tirez directement du serveur. Dans une application de style Yeoman avec automatisation javascript, vous concaténez et réduisez l'ensemble du shebang ensemble dans un seul fichier. Ils sont présents, mais pas exécutés / instanciés jusqu'à ce qu'ils soient nécessaires. Les améliorations de la vitesse et de la bande passante que vous obtenez en faisant cela dépassent largement les améliorations alléguées du téléchargement paresseux d'un contrôleur 20 lignes particulier. En fait, la latence du réseau gaspillée et la surcharge de transmission pour ce contrôleur vont être d'un ordre de grandeur supérieur à la taille du contrôleur lui-même.
Mais disons que vous avez vraiment besoin d'un téléchargement paresseux, peut-être pour des éléments de votre application rarement utilisés, comme une interface d'administration. C'est un cas très légitime. Exiger peut en effet le faire pour vous. Mais il existe également de nombreuses autres options , potentiellement plus flexibles , qui accomplissent la même chose. Et Angular 2.0 s'en occupera apparemment pour nous, intégré au routeur . ( Détails .)
Mais qu'en est-il du développement sur ma boîte de développement locale?
Comment puis-je charger toutes mes dizaines / centaines de fichiers de script sans avoir besoin de les attacher tous à index.html manuellement?
Jetez un œil aux sous-générateurs dans le générateur angulaire de Yeoman, ou aux modèles d'automatisation incorporés dans le générateur-gulp-angulaire , ou à l'automatisation Webpack standard pour React. Ceux-ci vous offrent un moyen propre et évolutif de: attacher automatiquement les fichiers au moment où les composants sont échafaudés, ou simplement les saisir tous automatiquement s'ils sont présents dans certains dossiers / correspondre à certains modèles globaux. Vous n'aurez plus jamais besoin de penser à votre propre chargement de script une fois que vous aurez ces dernières options.
En bout de ligne?
Exiger est un excellent outil pour certaines choses. Mais allez avec le grain chaque fois que possible et séparez vos préoccupations autant que possible. Laissez Angular s'inquiéter du modèle de modularisation d'Angular et envisagez d'utiliser des modules ES6 ou CommonJS comme modèle de modularisation général. Laissez les outils d'automatisation modernes s'inquiéter du chargement des scripts et de la gestion des dépendances. Et prenez soin du chargement différé asynchrone de manière granulaire, plutôt qu'en le mêlant aux deux autres préoccupations.
Cela dit, si vous développez des applications angulaires mais ne pouvez pas installer Node sur votre machine pour utiliser les outils d'automatisation Javascript pour une raison quelconque, alors Require peut être une bonne solution alternative. Et j'ai vu des configurations vraiment élaborées où les gens veulent charger dynamiquement des composants angulaires qui déclarent chacun leurs propres dépendances ou quelque chose. Et même si j'essayais probablement de résoudre ce problème d'une autre manière, je peux voir le bien-fondé de l'idée, pour cette situation très particulière.
Mais sinon ... en partant de zéro avec une nouvelle application angulaire et la flexibilité de créer un environnement d'automatisation moderne ... vous avez beaucoup d'autres options plus flexibles et plus modernes.
(Mis à jour à plusieurs reprises pour suivre l'évolution de la scène JS.)