JavaScript modularisieren

[Heiko]

Hallo,
ich würde gerne mein JavaScript-"Projekt" bisschen übersichtlicher gestalten und Funktionen die logisch zusammengehören in eine extra .js-Datei auslagern.

Das hat neben der Übersichtlichkeit, besserer Wartbarkeit den vorteil, dass bestimmte Funktionen nicht nur in diesem Projekt eingesetztw erden können aber die Seiten spezifischen Dinge nicht für alle wichtig sind.

Das heißt natürlich, dass alle benötigten .js-Dateien in die Seite eingebunden werden können.

Ich finde es nicht gut, wenn dann alle imports in der .htm-Datei gemacht werden müssen. Zum einen weil es dort dann sehr "überlaufen" mit .js-Imports ist und zum anderen weil das Problem dann auf einen anderen Programmierer verlagert wird, der damit gar nichts zu tun hat.

Die Web-Designer sollen sich nicht damit beschäftigen müssen, wie ich es aufgesplittet habe oder was ich jetzt schon wieder ausgelagert habe.

Die .js-Dateien erst im JavaScript-Code zu importieren geht ja nicht so leicht, da JavaScript erst im Browser ausgewertet wird.

Ist mein Vorhaben also doof und ich soll bei der "alten, übersichtlichen"-Form bleiben oder gibt es eine Möglichkeit, dies sinnvoll umzusetzen?

Danke für eure Meinung und Hilfe

[T-Rex]

Moin Heiko,

dein Vorhaben ist Lobenswert und ein logischer Schritt in deiner Entwicklung als Entwickler.
Ich möchte hier zu Diskussionszwecken meine Lösung präsentieren.
Ich habe Javascript Dateien in diversen Ordnern verstreut. Im Moment sind das Basis Klassen in einer Bibliothek und für die Projekte individuelle Javascript Klassen. In meinem HTML code lade ich eine einzige Javascript Datei. Die heißt z.B. 1317311073.js. Der Name wird im PHP bestimmt und als Templatevariable ins HTML gegeben (also dynamischer Name). Der Name orientiert sich an der aktuellsten Javascriptdatei und gibt deren Änderungsdatum als Timestamp zurück. Per htacces leite ich den Aufruf an ein PHP Script. Dieses wiederum vereint alle Javascript Dateien und gibt diese gebündelt und komprimiert zurück.

Vorteil:

• Der Name der Javascript Datei heißt bei einer Änderung anders. Das umgeht das leidige Problem das Javascriptdateien gecached werden.
• Die Javascript Sachen sind komprimiert, was einges an Traffic spart und Ladezeit bringt.
• Du hast nur einen Request für dein Javascript Zeugs.

Nachteil:

• Es werden auch Javascript Sachen geladen die du eventuell nicht brauchst auf der Seite. Sollte dich das Stöhren finde ich den Ansatz von YUI (von Yahoo) sehr interessant. Denn die haben ihre Bibliothek in Module aufgeteilt. Wenn du die Basisklasse Lädst musst du angeben welche Module du brauchst. Die werden dann in das Script nachgeladen.

Freue mich über Kritik meiner Idee!

Gruß
Kritik freudiger
T-Rex

[molily]

Hallo,

es ist üblich und sehr sinnvoll, Module bei der Entwicklung streng in verschiedene kleine Dateien zu trennen. Erst beim Deployment bzw. der Weiterverbreitung werden diese kompiliert, also zu größeren Paketen zusammengefasst. Dafür gibt es verschiedene Lösungen, die z.B. auf make, ant, rake, jake oder ähnliche Build-Tools setzen. Im Zuge dessen kann der Code auch z.B. mit JSLint/JSHint geprüft werden und z.B. mit YUI Compressor oder Google Closure Compiler komprimiert werden. Fast alle größeren JavaScript-Projekte arbeiten so – schau dir einfach mal auf Github die Build-Scripte von jQuery und Prototype an.

Ein weiteres Thema ist das modularisierte Laden von Scripten auf der Clientseite on-demand. Aber darauf wolltest du nicht hinaus, oder? Wenn doch, kannst du dir mal LABjs und RequireJS ansehen sowie diesen Vergleich von Loading-Scripten.

Mathias

[peterS.]

gruss Heiko,

für die Modularisierung anspruchsvoller Web-Applikationen
setze ich nur noch auf RequireJS. Dieses Framework arbeitet
hybride - als clientseitiger Loader und/oder als Buildprozess.

In der Entwicklungsphase nutzt man RequireJS ausschließlich
als clientseitigen Loader. Dieser *erkennt* Abhängigkeiten von
Modulen und lädt diese dann entsprechend sequentiell oder eben
parallel. Da Module in dieser Phase weder zusammengefasst noch
komprimiert sind, gestaltet sich die Fehlersuche sehr einfach.

Über Eclipse lassen sich seit geraumer Zeit auch sehr gut
JavaScript-IDEs bauen, die einem automatische Unit- bzw. Ober-
flächentests abnehmen.
RequireJS hat dort ebenfalls seinen Platz, und übernimmt die
Aufgabe, auf Knopfdruck *builds* zu erstellen. Modularisierung/
Packaging bzw. Komprimierung lassen sich im buildscript beliebig
einstellen. Auf die Vorteile des clientseitigen parallelen Ladens
muss man trotzdem nicht verzichten, wenn man z.b. aus 50 Modulen
3 bis 5 handlich, komprimierte Pakete erstellt.

Ein weiterer, von mir sehr geschätzter Vorteil von RequireJS ist,
dass gleichlautende Modulnamen verschieden implementiert sein
können, da RequireJS zum einen den globalen Namensraum nicht
verseucht und zum anderen die Module intern auf deren Pfaden
basierend verwaltet.

so long - peterS. - [e-mail]

[Heiko]

Danke für die Antworten. Ich werde mir am Dienstag die Sachen genauer anschauen