Il n'y a pas longtemps, un internaute m'a demandé à utiliser les obligations et les Seajs sur le front-end. Je lui ai demandé si votre entreprise avait une bibliothèque JavaScript ou un cadre JavaScript écrit par lui-même. Sa réponse n'était rien. Il vient d'entendre que les exigences et les Seajs sont de nouvelles choses et de nouvelles technologies, qui sont très précieuses, il voulait donc l'utiliser.
Le problème de cet internaute m'a fait réfléchir à la technologie de chargement du module JavaScript. Dans le dernier article, j'ai donné la structure de base d'une bibliothèque JavaScript que j'ai écrite. En fait, l'une des raisons de la rédaction de cet article est que je souhaite utiliser des technologies telles que les exigences ou les SeaJS pour repenser le modèle de base de ma bibliothèque JavaScript. Après avoir appris à connaître cette technologie en profondeur, j'ai constaté que l'utilisation du système de chargement du module pour résoudre le problème du découplage du code commun et du code commercial dans la bibliothèque JavaScript est incorrect. La portée du système de chargement du module est de résoudre le problème de dépendance entre différentes bibliothèques JavaScript, plutôt que de vous aider à développer une bibliothèque JavaScript.
Alors, qu'est-ce qu'un système de chargement de module JavaScript?
Le système de modules est principalement utilisé pour résoudre le problème de conflit de dénomination des objets d'opération dans différentes bibliothèques JavaScript et le problème de dépendance entre différentes bibliothèques JavaScript. Le système de chargement du module s'adresse à de grandes applications sur le Web ou aux applications Front-end géantes.
Généralement, dans les pages d'application Front-end géantes, la page a des fonctions très riches et des affaires complexes. De plus, au fil du temps, les fonctions de la page changent souvent, ce qui conduit à des développeurs frontaux en développant souvent des modules fonctionnels pour de nouvelles fonctions. Cependant, les fonctions entre divers modules fonctionnels dans l'activité réelle peuvent également se pénétrer mutuellement, dépendre les uns des autres et avoir des relations complexes. Lorsque la page est complexe, la relation entre chaque bibliothèque frontale sera difficile à gérer et à contrôler, et le système de chargement du module sera utile pour le moment.
Pour la plupart des programmeurs, il n'y a pas beaucoup de possibilités de supporter indépendamment une si grande application Web frontale, et il existe de nombreuses opportunités de développer de petites et moyennes applications sur le Web. Par exemple, les projets Web au niveau de l'entreprise, il existe très peu de types de bibliothèques JavaScript utilisées dans de tels projets, et les dépendances de chaque bibliothèque sont faciles à contrôler, il n'est donc pas nécessaire d'introduire un système de gestion de modules. Même les pages Web de nombreuses petites et moyennes sociétés Internet de taille moyenne ne sont probablement pas aussi compliquées que celles des applications Web de niveau d'entreprise, de sorte que la relation entre ses modules ou bibliothèques JavaScript est facile à gérer. En fait, les applications petites et moyennes ci-dessus sont toutes pour certains scénarios ou spécifiques. Par conséquent, je pense personnellement que face à de tels projets Web frontaux, nous pouvons enfin former une bibliothèque JavaScript indépendante. Les caractéristiques de cette bibliothèque doivent être similaires à celles d'un type de bibliothèque: une bibliothèque principale plus plusieurs bibliothèques de plug-in. Le but de la bibliothèque principale est de résoudre le problème de la généralité, et il doit être réutilisable et migré. Le but de la bibliothèque du plug-in est souvent lié au code commercial. Cependant, afin de distinguer la portée de la bibliothèque principale et de la bibliothèque du plug-in, j'ai ajouté la fonction d'espace de noms à la bibliothèque.
La technologie de chargement des modules JavaScript et la technologie Hadoop ont des similitudes, c'est-à-dire ce sont les deux technologies pour les systèmes super-grands, et ils ne peuvent jouer leur rôle que dans certaines conditions. Par conséquent, ces technologies sont lancées à partir de grandes sociétés Internet, car les grandes sociétés Internet doivent résoudre des problèmes après que leurs applications deviennent plus grandes et plus complexes. Lorsque votre système en est encore à ses balbutiements, vous devez souvent être prudent dans l'utilisation de ces technologies. Nous devrions trouver le moyen le plus simple et le plus efficace de résoudre nos problèmes réels. Si vous pensez que ce système deviendra plus grand à l'avenir, vous devez conserver l'interface pour utiliser ces technologies à l'avenir. S'il est utilisé trop tôt, il est très probable que lorsque l'échelle du système se développe, le coût de refactorisation de votre code sera plus élevé.
Pour les systèmes de chargement des modules, le scénario le plus approprié est de résoudre le problème du découplage entre les grands modules d'application Front-end. Si nous écrivons simplement un nouveau fichier JavaScript et utilisons immédiatement la technologie de chargement du module, ce n'est pas un peu de technologie d'abus. Avant d'utiliser une certaine technologie, nous ne devons pas seulement considérer comment l'utiliser ou comment il est utilisé, mais nous devons également réfléchir à la valeur de l'utiliser.
Enfin, je tiens à dire que je pense que les petits et moyens frontaux Web sont utilisés pour le déploiement de la production. Parce que JavaScript n'est pas le plus complexe, il est préférable d'emballer tous les fichiers JavaScript externes dans un fichier externe JavaScript. Cet avantage est qu'il réduit le nombre de demandes HTTP. L'utilisation de la technologie de chargement des modules rendra les fichiers très gênants et ne peut même pas être effectué (des modules tels que les exigences et les SeaJS sont tous basés sur des fichiers, et chaque module est un fichier indépendant), ce qui est contraire à la résolution de l'objectif de réduire HTTP.