Hallo Raketenschnellschießer,
Oder macht man das inzwischen anders?
Die Antwort ist die übliche: "Kommt drauf an". Wenn Du aus irgendwelchen Gründen unbedingt etwas im global scope brauchst, dann ja, mach ein Root-Objekt und nenn es Namespace.
Das machen die Client-Scripte von Microsofts ASP.NET beispielsweise so. Die Scripte sind zu verteilt, um das Modulkonzept umsetzen zu können. Und außer <code>Sys</code> haben sie auch nichts im global scope.
JQuery macht das auch. Es gibt $ als globale Variable, der Rest hängt da drunter.
Wenn Du ein isoliertes Stück Code hast, mach ein Modul draus. Entweder auf die klassische Art, oder als ECMAScript-Modul (was in unserem Wiki noch fehlt oder ich finde es gerade nicht).
Ein ECMAScript-Modul hat den Vorteil, dass Du es aus anderen Modulen importieren kannst und es trotz mehrerer Imports nur einmal im System ist. Alles, was Du von dort nicht exportierst, bleibt im Modul isoliert.
Bei klassischen Modulen geht das über einen AMD-Loader wie require.js. Da gibt's eine Menge Patterns, wie man Scripte so schreibt, dass sie mit unterschiedlichen AMD-Loadern funktionieren, aber eins haben sie gemeinsam: Entweder AMD, oder ECMAScript.
Wobei das bei jQuery wieder seltsam ist, der Source ist ECMAScript, aber die Downloads sind AMD. Offenbar transpilieren sie das.
Wenn Du dein Alarm-Modul also als ECMAscript Modul bereitstellen willst, schreibt der Anwender
<script type="module">
import Alarm from './lib/alarm.js';
Alarm("Hilfe!");
</script>
Da Module grundsätzlich deferred geladen werden, spart sie oder er oder they sich damit auch das Warten auf DOMContentLoaded.
Und du schreibst in dein Script am Ende
export default Alarm
;
Feddich.
Rolf
sumpsi - posui - obstruxi