Vor nicht allzu langer Zeit fragte mich ein Internetnutzer nach der Verwendung von Anforderungen und SeaJs am Frontend. Ich fragte ihn, ob Ihr Unternehmen eine JavaScript -Bibliothek oder ein JavaScript -Framework vor sich selbst geschrieben habe. Seine Antwort war nichts. Er hörte nur, dass Forderung und SeaJs neue Dinge und neue Technologien sind, die sehr wertvoll sind, also wollte er es verwenden.
Das Problem dieses Internetnutzer hat mich dazu veranlasst, über die Ladetechnologie des JavaScript -Moduls nachzudenken. Im letzten Artikel gab ich die Grundstruktur einer JavaScript -Bibliothek, die ich geschrieben habe. Tatsächlich ist einer der Gründe für das Schreiben dieses Artikels, dass ich Technologie wie Anforderung oder SeaJs verwenden möchte, um das Grundmodell meiner JavaScript -Bibliothek neu zu gestalten. Nachdem ich diese Technologie in der Tiefe kennengelernt hatte, stellte ich fest, dass die Verwendung des Modul -Ladesystems zur Lösung des Problems der Entkopplung des gemeinsamen Codes und der Geschäftsordnung in der JavaScript -Bibliothek falsch ist. Der Umfang des Modul -Ladesystems besteht darin, das Abhängigkeitsproblem zwischen verschiedenen JavaScript -Bibliotheken zu lösen, anstatt Ihnen zu helfen, eine JavaScript -Bibliothek zu entwickeln.
Was ist also ein JavaScript -Modul -Ladesystem?
Das Modulsystem wird hauptsächlich verwendet, um das Namenskonfliktproblem von Betriebsobjekten in verschiedenen JavaScript -Bibliotheken und das Abhängigkeitsproblem zwischen verschiedenen JavaScript -Bibliotheken zu lösen. Das Modul-Ladesystem richtet sich in großen Webanwendungen mit Web-Front-End-Anwendungen oder riesigen Web-Front-End-Anwendungen.
Im Allgemeinen verfügt die Seite auf riesigen Web-Front-End-Anwendungsseiten über sehr reichhaltige Funktionen und komplexe Geschäfte. Darüber hinaus ändern sich im Laufe der Zeit die Funktionen der Seite häufig, was dazu führt, dass Front-End-Entwickler häufig funktionale Module für neue Funktionen entwickeln. Die Funktionen zwischen verschiedenen Funktionsmodulen im tatsächlichen Geschäft können jedoch auch gegenseitig eindringen, voneinander abhängen und komplexe Beziehungen aufweisen. Wenn die Seite komplex ist, ist die Beziehung zwischen jeder Front-End-Bibliothek schwer zu verwalten und zu steuern, und das Modul-Ladesystem wird zu diesem Zeitpunkt nützlich.
Für die meisten Programmierer gibt es nicht viele Möglichkeiten, unabhängig eine so große Anwendung von Web-Front-End-Anwendungen zu tragen, und es gibt viele Möglichkeiten, kleine und mittelgroße Web-Front-End-Anwendungen zu entwickeln. In Webprojekten auf Unternehmensebene werden beispielsweise nur sehr wenige Arten von JavaScript-Bibliotheken in solchen Projekten verwendet, und die Abhängigkeiten jeder Bibliothek sind einfach zu steuern. Daher müssen ein Modulverwaltungssystem eingeführt werden. Sogar die Webseiten vieler kleiner und mittelgroßer Internetunternehmen sind wahrscheinlich nicht so kompliziert wie die von Webanwendungen auf Unternehmensebene, sodass die Beziehung zwischen ihren Modulen oder JavaScript-Bibliotheken einfach zu verwalten ist. Tatsächlich sind die oben genannten kleinen und mittleren Anwendungen für bestimmte oder bestimmte Szenarien. Daher denke ich persönlich, dass wir angesichts solcher Web-Front-End-Projekte endlich eine unabhängige JavaScript-Bibliothek bilden können. Die Merkmale dieser Bibliothek sollten denen einer Bibliotheksart ähnlich sein: eine Hauptbibliothek sowie mehrere Plug-in-Bibliotheken. Der Zweck der Hauptbibliothek ist es, das Allgemeingültigkeitsproblem zu lösen, und es sollte wiederverwendbar und migriert werden. Der Zweck der Plug-in-Bibliothek hängt häufig mit der Geschäftsordnung zusammen. Um jedoch den Umfang der Hauptbibliothek und die Plug-in-Bibliothek zu unterscheiden, habe ich der Bibliothek die Namespace-Funktion hinzugefügt.
Die Ladungstechnologie und die Hadoop-Technologie von JavaScript-Modul haben einige Ähnlichkeiten, dh beide Technologien für super große Systeme und sie können ihre Rolle nur unter bestimmten Bedingungen spielen. Daher werden diese Technologien von großen Internetunternehmen eingeführt, da große Internetunternehmen Probleme lösen müssen, nachdem ihre Anwendungen größer und komplexer werden. Wenn Ihr System noch in den Kinderschuhen steckt, sollten Sie diese Technologien häufig vorsichtig sein. Wir sollten den einfachsten und effektivsten Weg finden, um unsere tatsächlichen Probleme zu lösen. Wenn Sie der Meinung sind, dass dieses System in Zukunft größer wird, sollten Sie die Schnittstelle beibehalten, um diese Technologien in Zukunft zu verwenden. Wenn es zu früh verwendet wird, ist es sehr wahrscheinlich, dass die Kosten für die Wiederbelebung Ihres Codes, wenn sich die Systemskala erweitert, höher ist.
Für Modulladesysteme besteht das am besten geeignete Szenario darin, das Problem der Entkopplung zwischen großen Anwendungsmodulen der Web-Front-End-Anwendungen zu lösen. Wenn wir nur eine neue JavaScript -Datei schreiben und die Modul -Lade -Technologie sofort verwenden, ist dies nicht ein wenig die Missbrauchstechnologie. Bevor wir eine bestimmte Technologie verwenden, sollten wir nicht nur überlegen, wie sie sie verwenden oder wie sie verwendet wird, sondern wir sollten auch darüber nachdenken, ob es wertvoll ist, sie zu verwenden.
Schließlich möchte ich sagen, dass ich denke, dass kleine und mittelgroße Web-Frontends für die Bereitstellung von Produktion verwendet werden. Da JavaScript nicht die komplexeste ist, ist es am besten, alle externen JavaScript -Dateien in eine externe JavaScript -Datei zu verpacken. Dieser Vorteil ist, dass es die Anzahl der HTTP -Anforderungen reduziert. Durch die Verwendung von Modul -Lade -Technologie wird es sehr problematisch, Dateien zu verpacken, und kann sogar nicht durchgeführt werden (Module wie ReformenJs und SeJs basieren auf Dateien, und jedes Modul ist eine unabhängige Datei), was der Lösung des Zwecks der Reduzierung von HTTP widerspricht.