Non ho mai compreso l'attrattiva dei caricatori AMD per il Web lato client in generale, anche se a un certo punto avevano un senso per i dispositivi mobili perché i file delle risorse non venivano memorizzati nella cache su Android e le prestazioni di analisi non erano eccezionali.
Se alleghi file di script in 3 categorie nel seguente ordine,
- Librerie di terze parti generali
- Librerie interne specifiche dell'app che fanno riferimento alle librerie di terze parti
- Codice di implementazione che può fare riferimento a entrambi
... dov'è il problema? Gli script che non vengono utilizzati in una pagina non sono mai più di un singolo successo in termini di prestazioni di caricamento perché sono memorizzati nella cache. Se destreggiare le dipendenze all'interno di queste categorie solo aggiungendo i tag di script nell'ordine corretto è diventato un compito estremamente difficile, definirei un problema di gestione dell'architettura / file che non dovrebbe essere difficile da gestire con un po 'di clean-up / consolidamento .
Se due funzioni o costruttori condividono una dipendenza, di solito ha senso avere tutti nello stesso file e questo non dovrebbe essere difficile quando hai separato il codice che implementa, dalle cose che sono utilizzate dall'implementazione, dal 3 ° cose da festa che possono essere usate ovunque. All'interno di una determinata categoria non dividere le cose in file separati se condividono un dominio problematico comune. E naturalmente combinare / ridurre in produzione.
Se tutto quello che stai usando JS è il template sul lato client, non mi aspetterei che qualcuno voglia usare AMD. Come regola generale, non utilizzare nulla che non fornisca un vantaggio evidente / immediato. È più facile aggiungere più tardi di quanto non sia necessario.