Question

Quelles sont les pratiques standard pour gérer une application JavaScript de taille moyenne à grande ?Mes préoccupations concernent à la fois la vitesse de téléchargement du navigateur et la facilité et la maintenabilité du développement.

Notre code JavaScript est à peu près « espace de noms » comme suit :

var Client = {
   var1: '',
   var2: '',

   accounts: {
      /* 100's of functions and variables */
   },

   orders: {
      /* 100's of functions and variables and subsections */
   }

   /* etc, etc  for a couple hundred kb */
}

Pour le moment, nous disposons d'un fichier JavaScript (décompressé, non supprimé, hautement lisible) pour gérer toute la logique métier de l'application Web.De plus, il existe jQuery et plusieurs extensions jQuery.Le problème auquel nous sommes confrontés est qu'il faut pour toujours rien dans le code JavaScript et le navigateur a encore une dizaine de fichiers à télécharger.

Est-il courant d'avoir une poignée de fichiers JavaScript « sources » qui sont « compilés » en un fichier JavaScript final compressé ?Avez-vous d'autres conseils pratiques ou bonnes pratiques ?

Était-ce utile?

La solution

L'approche que j'ai trouvée qui fonctionne pour moi consiste à avoir des fichiers JS séparés pour chaque classe (comme vous le feriez en Java, C# et autres).Vous pouvez également regrouper votre JS en zones fonctionnelles d'application si cela vous facilite la navigation.

Si vous placez tous vos fichiers JS dans un seul répertoire, vous pouvez faire en sorte que votre environnement côté serveur (PHP par exemple) parcoure chaque fichier de ce répertoire et génère un <script src='/path/to/js/$file.js' type='text/javascript'> dans un fichier d'en-tête inclus par toutes vos pages d'interface utilisateur.Vous trouverez ce chargement automatique particulièrement pratique si vous créez et supprimez régulièrement des fichiers JS.

Lors du déploiement en production, vous devez disposer d'un script qui les combine tous dans un seul fichier JS et le « réduit » pour réduire la taille.

Autres conseils

Aussi, je vous suggère d'utiliser celui de Google API des bibliothèques AJAX afin de charger des bibliothèques externes.

Il s'agit d'un outil de développement Google qui regroupe les principales bibliothèques JavaScript et facilite leur déploiement, leur mise à niveau et leur allégeance en utilisant toujours des versions compressées.

En outre, cela rend votre projet plus simple et plus léger car vous n'avez pas besoin de télécharger, copier et conserver ces fichiers de bibliothèques dans votre projet.

Utilisez-le de cette façon :

google.load("jquery", "1.2.3");
google.load("jqueryui", "1.5.2");
google.load("prototype", "1.6");
google.load("scriptaculous", "1.8.1");
google.load("mootools", "1.11");
google.load("dojo", "1.1.1");

Il existe un excellent article sur Vitamin de Cal Henderson de Flickr sur la façon dont ils optimisent la livraison de leurs CSS et JavaScript : http://www.iamcal.com/serving-javascript-fast/

Juste un sidenode - Steve l'a déjà souligné, vous devriez vraiment "minifier" vos fichiers JS.En JS, les espaces comptent réellement.Si vous avez des milliers de lignes de JS et que vous supprimez uniquement les nouvelles lignes non obligatoires, vous avez déjà enregistré environ 1 Ko.Je pense que vous comprenez l'idée.

Il existe des outils pour ce travail.Et vous ne devriez jamais modifier à la main le JS « minifié »/dépouillé/obscurci !Jamais!

Dans nos grandes applications javascript, nous écrivons tout notre code dans de petits fichiers séparés - un fichier par « classe » ou groupe fonctionnel, en utilisant une structure d'espace de noms/répertoire similaire à celle de Java.Nous avons alors :

  • Une étape de compilation qui prend tout notre code et le réduit (en utilisant une variante de JSMin) pour réduire la taille du téléchargement
  • Une étape de compilation qui prend les classes qui sont toujours ou presque toujours nécessaires et les concatène en un gros paquet pour réduire les allers-retours vers le serveur.
  • Un « chargeur de classes » qui charge les classes restantes au moment de l'exécution, à la demande.

Pour des raisons d'efficacité du serveur, il est préférable de combiner tout votre javascript dans un seul fichier minifié.

Déterminez l'ordre dans lequel le code est requis, puis placez le code minifié dans l'ordre dans lequel il est requis dans un seul fichier.

La clé est de réduire le nombre de requêtes nécessaires pour charger votre page, c'est pourquoi vous devez avoir tout le javascript dans un seul fichier pour la production.

Je recommanderais de conserver les fichiers divisés pour le développement, puis de créer un script de construction pour tout combiner/compiler.

De plus, en règle générale, assurez-vous d’inclure votre JavaScript vers la fin de votre page.Si JavaScript est inclus dans l'en-tête (ou n'importe où au début de la page), il empêchera toutes les autres requêtes d'être effectuées jusqu'à ce qu'il soit chargé, même si le pipeline est activé.Si c'est à la fin de la page, vous n'aurez pas ce problème.

Lisez le code d'autres (bonnes) applications javascript et voyez comment elles gèrent les choses.Mais je commence avec un fichier par classe.Mais une fois prêt pour la production, je combinerais les fichiers en un seul gros fichier et je les réduirais.

La seule raison pour laquelle je ne combinerais pas les fichiers, c'est si je n'avais pas besoin de tous les fichiers sur toutes les pages.

Ma stratégie se compose de 2 techniques majeures :Modules AMD (pour éviter des dizaines de balises de script) et le modèle de module (pour éviter un couplage étroit des parties de votre application)

Modules AMD :très simple, voir ici : http://requirejs.org/docs/api.html il est également capable de regrouper toutes les parties de votre application dans un seul fichier JS minifié : http://requirejs.org/docs/optimization.html

Modèle de module :j'ai utilisé cette bibliothèque: https://github.com/flosse/scaleApp tu demandes maintenant, qu'est-ce que c'est ?plus d'infos ici : http://www.youtube.com/watch?v=7BGvy-S-Iag

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top