react, node, angular ...
heinetz
react, node, angular ...
heinetz
Hallo Forum,
ich stosse an meine Grenzen ;(
Ich habe 2001 angefangen, Websites zu bauen. Damals wurden vom Grafiker JPGs und GIFs ausgeschnitten, um damit HTML-Tabellen zu bauen. Interaktionen bestanden darin, Formulare zu verschicken, sie serverseitig mit PHP zu verarbeiten und HTML-Code zum Browser zurückzusenden oder was sehr viel hakeliger war, auf Browser-Events mit Javascript zu reagieren, das für Netscape vollkommen anders war, als für den Internet Explorer. Mich hat dennoch letztes sehr viel mehr gereizt, weil es irgendwie bunter und lebendiger war und ich habe mich immer mehr aufs Frontend konzentiert und Spass daran gehabt, Javascript zu coden. Ich war gut darin und habe mich selbständig gemacht. Fertige Lösungen habe ich lange abgelehnt und lieber alles von Hand gemacht, weil ich immer wissen wollte, was "unter der Haube" passiert. In 2010 habe ich mich dann an jQuery herangetraut und wieder Erwarten sogar schnell einen Sinn für Out-Off-Box-Lösungen entwickelt. Endlich liessen sich ganze einfach mit Ajax wirklich interaktive Lösungen umsetzen. Als ich 2013 habe ich dann meine erste rein mobile Website Anwendung mit jQuery mobile baute, eröffnete sich mir mit HTML5 und CSS3 ein weiterer Horizont und 2014 habe ich sogar Gefallen an Bootstrap gefunden. Jetzt haben wir 2017, ich habe gerade meinen Kunde, den ich 10 Jahre lang betreut habe, verloren und suche nach neuen Projekten. Ich lese von react, node, angular und denke, als jemand der sich von Anfang an auf Javascript konzentriert hat, dürfte das doch alles kein Problem sein. Die Idee, eine Website als Javasrcipt-Applikation zu denken, die im Browser läuft, finde ich auch naheliegend. Aber nach meinen ersten Gehversuchen mit react, node, angular ich fühle mich total erschlagen und habe den Eindruck, das ist eine ganz andere Dimension, wenn ich eine Internetseite mit Befehlen auf der Kommandozeile erstelle.
Ich weiss auch nicht, warum ich diese ganz lange Geschichte hier aufgeschrieben habe. Wahrscheinlich damit mir irgendwer hier sagt, so schlimm sein das alles garnicht.
Könnt Ihr mir vielleicht einen Tipp geben, wo ich anfangen soll?
1000 Dank und
gruss, heinetz
-
Tach!
Fertige Lösungen habe ich lange abgelehnt und lieber alles von Hand gemacht, weil ich immer wissen wollte, was "unter der Haube" passiert.
Das stimmt so garantiert nicht. Du hast auch damals schon gegen fertige APIs programmiert und nicht alles selbst in Maschinencode geschrieben. Und selbst bei Maschinencode blendet man recht viel aus, das auf der Hardwareebene passiert, also unter der Haube. Man wechselst die Ebenen weiter nach oben, weil man seine Aufgabe fertigbekommen möchte und nicht für das Beschäftigen mit der Materie an sich bezahlt wird - wenn man kein Forscher ist. Und selbst wenn man das nicht professionell macht, wird man auf diese Weise arbeiten müssen, um nicht zu viel (Frei)zeit in die Programmierung der Infrastruktur zu stecken.
Aber nach meinen ersten Gehversuchen mit react, node, angular ich fühle mich total erschlagen und habe den Eindruck, das ist eine ganz andere Dimension, wenn ich eine Internetseite mit Befehlen auf der Kommandozeile erstelle.
Ja, das ist ungefähr so, wie von Programmierung von DOS-Programmen auf grafische Oberfläche umzusteigen. Der ganze Programmablauf folgt einer komplett anderen Philosophie.
Ich weiss auch nicht, warum ich diese ganz lange Geschichte hier aufgeschrieben habe. Wahrscheinlich damit mir irgendwer hier sagt, so schlimm sein das alles garnicht.
So schlimm ist das alles garnicht.
Könnt Ihr mir vielleicht einen Tipp geben, wo ich anfangen soll?
Wie immer, im kleinen Rahmen und dann wachsen. Erstmal den Kopf freimachen, nicht zu viel mit dem Bisherigen vergleichen oder mit den bisherigen Methoden die völlig neue Welt zu meistern versuchen. Stattdessen Tutorials schnappen und die Philosophie des Systems kennenlernen. Bei Problemen nach Lösungen gemäß der Philosophie des Systems suchen, statt was dranzustricken. Wenn du die Möglichkeiten kennst, wirst du auch Ideen bekommen, wie du deine Projekte damit oder mit einem anderen System lösen kannst und wie die Eigenschaften der Systeme für den individuellen Einsatzzweck bewertet werden können, damit du das passende für den Zweck auswählen kannst. Das ist im Grunde nicht grundlegend anders als wie du bisher mit deinen Werkzeugen umgegangen bist.
Und das Schöne ist, man kann immer noch unter die Haube schauen, weil das meiste Open Source ist.
dedlfix.
-
Hi!
Wahrscheinlich damit mir irgendwer hier sagt, so schlimm sein das alles garnicht.
Es ist leider so schlimm!! ;-D
Ich kann dein Gefühl des "Erschlagenseins" verstehen. Das Thema ist groß und wächst tag-täglich. Vor allem weil mit neuen Frameworks meist noch weitere Neuerungen zusammen hängen: Ecmascript 6, Typescript, Module, Bundler, CLIs u.s.w.
Was ich dir sagen: Vieles ist alter Wein aus neuen Schläuchen. Wenn du jQuery und Ajax kennst, kennst du dynamische Webseiten und Benutzeroberflächen die von Javascript profitieren.
Was man heute mit React und Angular macht ist aus Sicht des Users nichts Neues. Das hat man früher mit jQuery auch gemacht. Heute geht es nur einfacher, geregelter und schneller. Verzwickte Anwendungen mit JS haben wurden auch schon vor 10 Jahren gebaut. Das war schrecklich. Es fehlten die Strukturen wie React und Angular welche vorgeben. Darunter das Denken in "UI Komponenten" mit Parametern, einem Zustand und einem HTML Template (oder halt Virtual DOM Rendering bei React). Und das "saubere" Verwalten und Ändern von Daten. Das war mit jQuery alleine eine Schweinerei. Oder man mußte sich was dazu programmieren.
Die Idee, eine Website als Javasrcipt-Applikation zu denken, die im Browser läuft, finde ich auch naheliegend.
Ja, aber dieses "alte" Modell das du beschreibst ist deshalb nicht überflüssig:
Interaktionen bestanden darin, Formulare zu verschicken, sie serverseitig mit PHP zu verarbeiten und HTML-Code zum Browser zurückzusenden
Wichtig ist sich das Vorurteils-freie Denken zu bewahren. Eine Website will ersteinmal den Nutzern etwas bieten. Die Techniken sucht man danach aus ob sie zu diesem Zweck dienen. Wenn keine Notwendigkeit besteht brauche ich weder Angular noch React, sondern lasse die Website auf dem Server mit irgendeiner Sprache erzeugen. (das kann Z.B. auch Node + React sein!)
Klar doch, Dynamisches im Browser braucht man früher oder später. Dann mußt du dich fragen ob ein bisschen magischer jQuery Feenstaub ausreicht. Oder ob die Logik kompliziert wird und ein Komponenten-System und eine ausgeklügelte Datenverarbeitung deinen Code radikal vereinfachen können. Ich finde an den Punkt kommt man mit jQuery sehr schnell!
Alle Libs und Frameworks kanst du auch als Feenstaub verwenden um nur einzelne Teile der Seite mit Javascript zu kontrollieren. Wenn du eine JS Logik hast, die gerade mit jQuery o. ä. (etwas dir Vertrautem) gemacht ist, kannst du dir Z.B. Angular und React schnappen und genau diese Logik nachbauen. So ein klares greifbares ziel ist für den Einstieg am einfachsten.
Zum Rumspielen mit React:
https://github.com/facebookincubator/create-react-app
Ein älteres React Tutorial (von jQuery nach React):
http://chibicode.com/react-js-introduction-for-people-who-know-just-enough-jquery-to-get-by/
MFG
Andreas
-
Hallo Andreas,
zunächst mal vielen Dank für Dein Einfühlungsvermögen 😉
Was ich dir sagen: Vieles ist alter Wein aus neuen Schläuchen.
Ja, das trifft's. Genau zu dem Schluss komme ich während der gesamten Zeit, die ich mich mit dem Thema Frontend beschäftige auch immer wieder. "Gab's doch immer, sah nur anders aus" In der Nachbetrachtung fällt mir auf, wie wichtig diese Erkenntnis jeweils für meine Sicherheit war.
Ein älteres React Tutorial (von jQuery nach React):
http://chibicode.com/react-js-introduction-for-people-who-know-just-enough-jquery-to-get-by/
Das war ein sehr sehr guter Tipp. Es beschreibt nicht nur, wie mit react.js umzugehen ist, sondern vor Allem warum. Das war mein persönlicher Break-Even. Es löst Probleme, mit denen ich mich persönlich bei entwicklen mit jQuery immer wieder konfrontiert sehe. Ich freue mich auf das Thema, fehlt nur noch die Aufgabestellung …
danke und gute nacht, heinetz
-
Hallo Forum,
Ein älteres React Tutorial (von jQuery nach React):
http://chibicode.com/react-js-introduction-for-people-who-know-just-enough-jquery-to-get-by/
Das war ein sehr sehr guter Tipp. Es beschreibt nicht nur, wie mit react.js umzugehen ist, sondern vor Allem warum. Das war mein persönlicher Break-Even. Es löst Probleme, mit denen ich mich persönlich bei entwicklen mit jQuery immer wieder konfrontiert sehe. Ich freue mich auf das Thema, fehlt nur noch die Aufgabestellung …
Nachdem ich nun einen kleinen Einblick in react.js bekommen und ein Verständnis dafür bekommen habe, wie sich react.js von jQuery unterscheidet, kommt das nächste grosse Fragezeichen:
Ich habe den HTML-Code aus meinem jsbin jetzt einfach herauskopiert, als HTML-File auf meiner lokalen Entwicklungsumgebung gespeichert und im Browser aufgerufen.
<!DOCTYPE html> <html> <head> <script src="https://fb.me/react-15.1.0.js"></script> <script src="https://fb.me/react-dom-15.1.0.js"></script> <link href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css" rel="stylesheet" type="text/css" /> <meta charset="utf-8"> <title>JS Bin</title> </head> <body> <div id="container"></div> <script> var TweetBox = React.createClass({ getInitialState: function() { return { text: "", photoAdded: false }; }, togglePhoto: function(event) { this.setState({ photoAdded: !this.state.photoAdded }); }, remainingCharacters: function() { if (this.state.photoAdded) { return 140 - 23 - this.state.text.length; } else { return 140 - this.state.text.length; } }, overflowAlert: function() { if (this.state.photoAdded) { var beforeOverflowText = this.state.text.substring(140 - 23 - 10, 140 - 23); var overflowText = this.state.text.substring(140 - 23); } else { var beforeOverflowText = this.state.text.substring(140 - 10, 140); var overflowText = this.state.text.substring(140); } if (this.remainingCharacters() < 0) { return ( <div className="alert alert-warning"> <strong>Oops! Too Long:</strong> ...{beforeOverflowText} <strong className="bg-danger">{overflowText}</strong> </div> ); } else { return ""; } }, handleChange: function(event) { console.log(event.target.value); this.setState({ text: event.target.value }); }, render: function() { return ( <div className="well clearfix"> { this.overflowAlert() } <textarea className="form-control" onChange={this.handleChange}></textarea> <br /> <span>{ this.remainingCharacters() }</span> <button disabled={this.remainingCharacters() === 140} className="btn btn-primary pull-right">Tweet</button> <button className="btn btn-default pull-right" onClick={this.togglePhoto}> {this.state.photoAdded ? "✓ Photo Added" : "Add Photo" } </button> <br /> </div> ); } }); ReactDOM.render( <TweetBox />, document.getElementById("container") ); </script> </body> </html>Das funktioniert leider nicht, was ich aber erwartet hatte. Was mir, als jemand der gewohnt ist mit jQuery zu arbeiten, nun fehlt ist eine Idee warum das nicht funktioniert.
Gibts einen einfach Antwort?
gruss, heinetz
-
Tach!
Ich habe den HTML-Code aus meinem jsbin jetzt einfach herauskopiert, als HTML-File auf meiner lokalen Entwicklungsumgebung gespeichert und im Browser aufgerufen.
Das verlinkte Tutorial ist kein vollständiger Ersatz für die hauseigene Dokumentation von React. Ich würde es als Einstieg nehmen, aber dann auch die Originaldokumentation durcharbeiten.
Das funktioniert leider nicht, was ich aber erwartet hatte. Was mir, als jemand der gewohnt ist mit jQuery zu arbeiten, nun fehlt ist eine Idee warum das nicht funktioniert.
JSX wird genausowenig von Browsern verstanden wie TypeScript, wenn du mit Angular arbeiten würdest. Da ist ein Übersetzungsprozess in herkömmliches Javascript notwendig.
Gibts einen einfach Antwort?
Die steht auch im verlinkten Tutorial. Aber nur als Verweis, weil eine Einführung in diese Übersetzungsmechanik nicht Teil des Artikels ist.
dedlfix.
-
Hello,
Das verlinkte Tutorial ist kein vollständiger Ersatz für die hauseigene Dokumentation von React. Ich würde es als Einstieg nehmen, aber dann auch die Originaldokumentation durcharbeiten.
Damit hatte ich ursprünglich angefangen. Daraufhin habe ich mein Leid hier geklagt, dass ich das Gefühl habe, nur noch Bahnhof zu verstehen. Ich habe die Beispiel-Appplikation erstmal zum Laufen gebracht aber dass ich dazu einen Befehl im Terminal eingeben muss und danach meine "Website" mit http://localhost:3000 erreiche, hat mich verunsichert. 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. 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. 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.
JSX wird genausowenig von Browsern verstanden wie TypeScript, wenn du mit Angular arbeiten würdest. Da ist ein Übersetzungsprozess in herkömmliches Javascript notwendig.
Gibts einen einfach Antwort?
Die steht auch im verlinkten Tutorial. Aber nur als Verweis, weil eine Einführung in diese Übersetzungsmechanik nicht Teil des Artikels ist.
Ich habe meinen erste Gehversuch mit react.js auch mittlerweile zum Laufen bekommen, indem ich zwei Dinge angepasst habe:
- ich habe zusätzlich eine babel.min.js im head eingebunden.
- ich habe meinem <script> ein type="text/babel" hinzugefügt.
Nun habe ich eine ungefähre Ahnung davon, was ich damit gemacht habe. babel.min.js erkennt an dem Type-Attribut, was es zu übersetzen gilt und übersetzt dann den JSX-Code in reines Javascript, das der Browser versteht. So etwas ähnliches habe ich bei LESS kennengelernt. Da gibts auch ein Script, dass im head eingebunden wird, um dann <style type="stylesheet/less"> im Laufzeit zu übersetzen. Was langsam ist und deshalb nur während der Entwicklung Sinn macht. 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
danke und gruss, heinetz
-
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.
-
Ok, ich arbeite also das Tutorial ab ohne es zu verstehen. Vielleicht fügt sich ein Puzzle zusammen. Aber ich werde immer wieder hier fragen!
Auch wenn ich fleissig das offizielle Tutorial abarbeite, versuche ich "Boden unter den Füßen" zu bekommen, indem ich mir hier und da ein Häppchen Wiedererkennungswert suche.
- Ich habe mir also erstmal die Verzeichnisstruktur meines Projekts angesehen und nach einer index.html Ausschau gehalten. Nachdem ich die gefunden hatte, habe ich sie zum test umbenannt, um zu sicherzustellen, dass sie relevant ist. Sie ist es offenbar, denn meine Ausgabe ist nicht mehr das TicTacToe-Spiel, sondern eine Meldung "Failed to compile". Um das Ganze erstemal wieder heil zu machen, habe ich die Datei dann wieder in index.html umbenannt. Allerdings ohne Erfolg. Es erscheint immernoch die Fehlermeldung. Der mir bekannte Browser-Cache scheint nicht daran Schuld zu sein. Lässt sich eindeutig sagen, was statt dessen die Ursache ist und wie ich den Fehler wieder behebe?
Beheben konnte ich das Ganze eben damit, dass ich im Terminal erneut 'npm start' eingegeben habe. Es wurde offenbar etwas neu compiliert. Was bleibt mir bisher ein Rätsel ;)
- Aus welchem Grund funktioniert meine "Website" mit dem Request http://localhost:3000 während sie mit http:// localhost/pfad/zu/meiner/index.html nicht funktioniert?
danke für Tipps und
gruss, heinetz
-
Tach!
Ok, ich arbeite also das Tutorial ab ohne es zu verstehen. Vielleicht fügt sich ein Puzzle zusammen. Aber ich werde immer wieder hier fragen!
Auch wenn ich fleissig das offizielle Tutorial abarbeite, versuche ich "Boden unter den Füßen" zu bekommen, indem ich mir hier und da ein Häppchen Wiedererkennungswert suche.
Das ist vielleicht der Fehler. Betrachte ein neues System möglichst unvoreingenommen. Wenn du Parallelen findest, dann ist es gut, aber such nicht speziell nach ihnen. Das verstellt unter Umständen sonst den Blick auf das Eigentliche, das dann vielleicht doch anders ist.
- Aus welchem Grund funktioniert meine "Website" mit dem Request http://localhost:3000 während sie mit http:// localhost/pfad/zu/meiner/index.html nicht funktioniert?
Der Standard-Port für http ist 80. Dein Entwicklungswebserver lauscht aber auf 3000. Wenn da was auf 80 lauscht, ist das ein anderer Webserver.
P.S. Ich kann nur allgemeine Fragen beantworten. React ist nicht meine Baustelle, sondern Angular.
dedlfix.
-
Hello,
Das ist vielleicht der Fehler. Betrachte ein neues System möglichst unvoreingenommen. Wenn du Parallelen findest, dann ist es gut, aber such nicht speziell nach ihnen. Das verstellt unter Umständen sonst den Blick auf das Eigentliche, das dann vielleicht doch anders ist.
Vielleicht. Das Tutorial, das ich zuerst abgearbeitet hatte, hat mir ein bisschen Sicherheit gegeben, weil es Vergleiche zog. Dass das nicht den Anspruch erfüllt, eine Dokumentation zu ersetzen, ist mir klar. Ich kenne auch Momente, in denen ich etwas Neues einfach erstmal unvoreingenommen gemacht habe und es dann irgendwann durch die Wiederholung selbstverständlich wurde. Aber in den meisten Fällen habe ich immer nach Verbindungen mit etwas mir Bekanntem gesucht und so eine Dynamik entwickelt.
- Aus welchem Grund funktioniert meine "Website" mit dem Request http://localhost:3000 während sie mit http:// localhost/pfad/zu/meiner/index.html nicht funktioniert?
Der Standard-Port für http ist 80. Dein Entwicklungswebserver lauscht aber auf 3000. Wenn da was auf 80 lauscht, ist das ein anderer Webserver.
Dass hier unterschiedliche Webserver den Request beantworten, ist schon klar. Aber warum mein lokal installierter Webserver (Port 80) die Anfrage nich genauso beantworten kann, wie der Entwicklungswebserver nicht.
P.S. Ich kann nur allgemeine Fragen beantworten. React ist nicht meine Baustelle, sondern Angular.
Ich glaube, das ist auch ganz gut so, denn es geht bei mir ja momentan noch eher um das allgemeine Verständnis.
danke und gruss, heinetz
-
Tach!
Dass hier unterschiedliche Webserver den Request beantworten, ist schon klar. Aber warum mein lokal installierter Webserver (Port 80) die Anfrage nich genauso beantworten kann, wie der Entwicklungswebserver nicht.
Es kann sein, dass der noch etwas zusätzliches einfügt, um den Entwicklungsprozess zu unterstützen, beispielsweise automatischer Refresh bei Änderungen oder das Kompilieren von JSX.
Bei Angular (konkret, wenn man mit Angular CLI arbeitet) ist es so, dass man für den Produktiveinsatz einen eigenen Build laufen lässt, und dann kann das auch allein laufen.
Schau mal in die package.json, da gibt es einen Abschnitt scripts. Vielleicht gibt es da einen Eintrag, der sich auf das Erstellen der Produktionsversion bezieht (eventuell prod oder dist). Den kannst du mit
npm run name_des_eintragslaufen lassen und solltest dann alles so haben, dass du es in einen normalen Webserver bringen kannst. Angular CLI erstellt dann ein dist-Verzeichnis, dessen Inhalt dann auf den Webserver kommt. Das sollte anderswo so ähnlich ablaufen.dedlfix.
-
hello,
hab's hinbekommen. In meinem Terminalfenster stand, wie das läuft:
npm run build
... und wie von Geisterhand wurde mir ein Verzeichnis 'build' erstellt, das einige wenige minifizierte (u.A. ein richtiges .js-File!😉) enthielt und sich von MEINEM EIGENEN Webserver aufrufen ließ.
1000 Dank, da fällt mir wieder ein grosser Stein vom Herzen 😉
schönen Abend und
bis zum nächsten Mal, heinetz
-
-
-
-
-
-