nicht angemeldet
Ich bin doch gewohnt eine inde.html in ein Verzeichnis meines lokalen Webservers zu legen und den entsprechenden Pfad dann als http:// localhost/pfad/zu/meiner/index.html dann im Browser einzugeben.
Daran hat sich auch nicht viel geändert. Der Befehl, den du in die Konsole eingegeben hast, hat einfach nur einen lokalen Webserver gestartet 😉 In der JavaScript-App-Entwicklung ist es nicht unüblich, dass Frameworks ihre eigenen Debugging-Webserver mitbringen, um einen schnellen Start zu ermöglichen. Immerhin erspart dir das die Mühe einen marktreifen Webserver zu installieren und zu konfigurieren. Außerdem ersparen dir diese Mini-Webserver häufig das manuelle Ausführen deiner Buildchain, wenn sich Dateien geändert haben, weil sie unter der Haube alle Änderungen überwachen und dann on-the-fly reagieren. Alles in allem, solltest du keine Angst davor haben, sondern dich einfach damit vertraut machen. Anfangs wird das manchmal haarig sein, wie bei jedem neuen Skill, aber nach einer Weile wirst du wohl nie wieder zu deinem alten Workflow zurück kehren wollen 😉
Dann werden im head ein paar Skripte bspw. jquery.min.js eingebunden und ich kann danach mit dem jquery-Code loslegen. Da habe ich eine Vorstellung, was passiert. In der jquer.min.js werden irgendwelche Klassen und Objekte erzeugt, mit denen ich später arbeiten kann.
Das ist der bequemene Workflow mit dem wir alle mal angefangen haben. Das Problem damit ist, dass er sehr starr ist. Production-Code soll ja im Idealfall konkateniert und minifiziert werden, also kommt da schon mal mindestens irgendwo ein Build-Schritt dazwischen. Dann möchtest du jQuery irgendwann updaten und dich vergewissern, dass auch alle abhängigen Module mit der neuen Version kompatibel sind. Dann möchtest du wohlmöglich irgendwann eine Testsuite haben, weil das händische Ausprobieren auf Dauer zu mühsam wird. Und so wachsen deine Aufgaben ständig und dieser sehr simple Workflow wird plötzlich zu einem ernsthaften Problem: dann bist du mehr Zeit damit beschäftigt, deine Aufgaben zu managen als sie zu bearbeiten. Dann wird es Zeit deinen Workflow zu optimieren. Tools wie Babel, Node, Webpack, Gulp, Grunt und wie sie alle heißen, sind dabei deine besten Helfer. Aber am besten lernt man diese Sachen aus der Erfahrung: Wenn du 100 mal den Babel-Compiler ausgeführt hast, denkst du vielleicht beim 101 Mal darüber nach, dass man diesen Schritt besser automatisieren sollte. Dann passt du deine Webpack konfiguration an und die nächsten 1.000 oder 10.000 Male übernimmt Webpack diesen Schritt für dich und du bist froh, weil du dich wieder den wichtigen Dingen zu wenden kannst.
Und ich habe auf meinem lokalen Entwicklungssystem auch node.js. Aber das brauchte ich auch nur, um die lokale Entwicklungsumgebung aufzusetzen und ich habe auch dafür nur irgendwelche Tutorials abgearbeitet ohne wirklich zu begreifen, warum ich hier node.js installieren muss und was das überhaupt ist.
Node.js ist das Schweizertaschenmesser der JavaScript-Entwicklung: Es ist deine Paket-Verwaltung, deine Toolchain, dein Webserver und vieles mehr. Auch hier gilt: Es ist noch kein Meister vom Himmel gefallen. Anfangs wirst du einfach nur den Instruktionen der Tutorials folgen, aber irgendwann, wirst du (ohne es zu merken) selber Node.js-Befehle eintippen und ausführen.
In der produktiven Version der Website macht man dann mit einem Compiler aus der .less eine .css, die statt dessen eingebunden wird.
Aber was passiert hier? ... in einfachen Worten ausgedrückt
Das gleiche, du benutzt Babel, um aus deinen .jsx-Dateien eine ausführbare .js-Datei zu generieren. Das setzt natürlich voraus, dass du keine inline-Skripte benutzt.