}).listen(9000); //the server object listens on port 9000
Also verstehe ich das richtig, außer dass ein http-Objekt erzeugt wird:
1) ich rufe eine Methode "createServer" auf. Argument dieser Methode ist
eine Funktion
2) die Funktion hat 2 Argumente req und res (request, response) - wobei
response ja eher ein Rückgabewert einer Funktion ist?
3) der Inhalt der Funktion wird in den {} Klammern gleich vor Ort
definiert
4) wohin gehört das .listen(9000)? zu http oder zu createServer?
Sinnvoll wäre wohl ersteres, also das ein Event-listener an das
http-Objekt gebaut wird
Könnte man diese Punkte auch einzeln / auseinander schreiben? (wie?)
1) Dein Tutorial ist sehr sehr sehr alt.
Faustregel: Wenn Variablen mit "var" statt "let"/"const" definiert
werden, wegwerfen, Neues suchen.
2) Weiter auseinandergedröselt:
1
const http = require('http');
2
3
// Wird für jeden HTTP-Request aufgerufen
4
function requestHandler(req, res) {
5
//...
6
res.end("Hallo Welt");
7
}
8
9
// HTTP-Server anlegen, der "requestHandler" benutzt
10
const server = http.createServer(requestHandler);
11
12
// Server an Port binden, starten:
13
server.listen(9000);
Ist so getrennt, weil man z.B. ein zweites, z.b. "https"-Server Objekt
gleichzeitig offen haben kann, was denselben Requesthandler benutzen
könnte.
ja, so verstehe ich es besser, vielen Dank!
Εrnst B. schrieb:> Dein Tutorial ist sehr sehr sehr alt.
Mein Auto auch, aber es fährt und macht keine Zicken :-)
Aua schrieb:> Mein Auto auch, aber es fährt und macht keine Zicken
Musst die jeweilige Entwicklungsgeschwindigkeit berücksichtigen.
An der Javascript/ECMA-Script-Entwicklungsgeschwindigkeit bemessen ist
der tutorial-Code eher ein Pferdefuhrwerk. Klar, das kann auch auf
heutigen Straßen noch fahren, und es ist durchaus interessant wie man
z.B. die Eisen-Laufflächen auf die Holzräder kriegt, aber wenn du nicht
Historiker sondern KFZ-Mechaniker werden willst, dann fang mit was
zumindest halbwegs aktuellem an.
Εrnst B. schrieb:> An der Javascript/ECMA-Script-Entwicklungsgeschwindigkeit bemessen ist> der tutorial-Code eher ein Pferdefuhrwerk. Klar, das kann auch auf> heutigen Straßen noch fahren, und es ist durchaus interessant wie man> z.B. die Eisen-Laufflächen auf die Holzräder kriegt, aber wenn du nicht> Historiker sondern KFZ-Mechaniker werden willst, dann fang mit was> zumindest halbwegs aktuellem an.
... was in zwei Jahren von den hippen Experten dann auch schon wieder
als völlig veraltet bezeichnet wird ;)
Aua schrieb:> Ich fand es thematisch ganz ok für meinen Bedarf - kannst Du ein Neueres> empfehlen?
Zwar nicht an mich gerichtet, aber da ich beruflich Berührungspunkte
damit habe... die beiden Seiten sind sehr gut, ersteres auch als
Print-Version verfügbar.
https://eloquentjavascript.net/https://javascript.info/
Und ja: es macht durchaus Sinn sich mit der modernen Programmierung
auseinanderzusetzen wenn man mehr will als "irgendwie geht es". Dazu
auch gleich der Verweis auf TypeScript wenn man mehr Typensicherheit
möchte: https://www.typescriptlang.org/
Viele Grüße,
Dennis
Georg A. schrieb:> Εrnst B. schrieb:>> An der Javascript/ECMA-Script-Entwicklungsgeschwindigkeit bemessen ist>> der tutorial-Code eher ein Pferdefuhrwerk. Klar, das kann auch auf>> heutigen Straßen noch fahren, und es ist durchaus interessant wie man>> z.B. die Eisen-Laufflächen auf die Holzräder kriegt, aber wenn du nicht>> Historiker sondern KFZ-Mechaniker werden willst, dann fang mit was>> zumindest halbwegs aktuellem an.>> ... was in zwei Jahren von den hippen Experten dann auch schon wieder> als völlig veraltet bezeichnet wird ;)
Naja, nichts ist so beständig wie die Änderung, aber gerade das macht es
doch Anfängern, aber auch Experten immer schwerer das richtige Werkzeug
für die Richtige Aufgabe zu finden.
Mittlerweile gibt es so viele Frameworks, Liberarys usw... teilweise mit
Abhängigkeiten untereinander.
Es ist aber schon krass, das ein Buch nach 5 Jahren nicht mehr das
Papier wert ist, auf dem es gedruckt wurde.
Der Grund warum wir jedes Jahr neue Frameworks und neue Werkzeuge
bekommen?
Wahrscheinlich liegt das Problem ganz woanders.
Bis 2000 herum war Softwareentwicklung ein Kunsthandwerk. Die
Prozessoren waren zu langsam und der Speicher zu klein. Wir mussten mit
allen Tricks auf Geschwindigkeit und Speicherbedarf optimieren.
Unsere Intuition und die Objektorientierung funktionierten aber nur mit
Megabyte. Seit wir in Gigabyte rechnen, ist die Software einfach zu
umfangreich geworden.
Diese komprimierte Schreibweise, ohne Variablenzuweisung, stammt aus
einer vergangenen Epoche. Eigentlich müssten wir die Vorgehensweise
übernehmen, mit denen Verkehrsflugzeuge oder Atomkraftwerke entwickelt
werden.
Ok, zu flapsig ausgedrückt.
Kunsthandwerk funktionierte mit Kilobyte.
Die Kombination aus Kunsthandwerk und Objektorientierung funktionierte
mit Megabyte.
Heutzutage sind die Programme so umfangreich, dafür brauchen wir eine
Kombination aus Objektorientierung und eine Arbeitsteilung zwischen
Erfindern, Ingenieuren, Facharbeitern und Bürokraten.
Erster Schritt: Die genialen Erfinder nutzen eine Schreibweise, die
jeder Facharbeiter versteht. Nicht so einen genial komprimierten
Einzeiler, den nur andere geniale Entwickler auf Anhieb verstehen.
Sven L. schrieb:> Es ist aber schon krass, das ein Buch nach 5 Jahren nicht mehr das> Papier wert ist, auf dem es gedruckt wurde.
Überhaupt nicht. Das war in der Software-Branche schon immer so. Das
Wissen verdoppelt sich dort etwa alle 13 Monate. Völlig normal. Kenne es
nicht anders.
Schau doch mal an, wie kurzlebig z.B. Windows-Versionen waren/sind:
Windows 95: 3 Jahre
Windows 98: 2 bis 3 Jahre
Windows NT 4: 3 Jahre
Windows 2000: 1 Jahr, haha...
Windows XP: 6 Jahre, lief ewig
Windows Vista: 2 Jahre
Windows 7: 3 Jahre
Windows 8 und 8.1: 3 Jahre
Windows 10: Volle 7 Jahre, wird jetzt endlich durch 11 ersetzt.
Bei den Server-Varianten ist keine länger als 3 Jahre gelaufen.
5 Jahre sind in der IT nun mal eine Ewigkeit.
Na ja, Windows ist nicht so das ideale Beispiel. Besser wäre gewesen,
Microsoft wäre bei XP geblieben, hätte 20 Jahre nur Bugfixes gemacht und
diese ganze Bloatware mit Kacheln und Sharepoint Generve einfach
weggelassen.
Aber auf anderen Gebieten verdoppelt sich das Wissen alle paar Jahre.
Selbstfahrende Autos, autonome Kampfdrohnen, selbstständig lernende
Haustechnik...
Wir haben doch eher den Effekt - Technologien wie Grafischen
Benutzeroberflächen oder Desktop Publishing sind nach 20 Jahren
ausgereift. Danach nerven nur mehr die Marketingabteilungen mit
irgendeinem Krempel, den keiner haben will.
Gleichzeitig kommen aber neue Ideen auf, die 10 mal so viel Wissen und
100 mal so viel Rechenleistung brauchen.
Zurück zum Beispiel: Früher benutze ein Hobbybastler ein paar TTL
Gatter, Taster und Leuchtdioden. Heutzutage nimmt man dafür eine Linux
Platine einen node.js Webserver und ein Smartphone mit Touchscreen. Ein
Webserver mit allen Seiten und Scripten ist heutzutage ein Bauteil wie
ein Taster. Nur leider bracht man dafür 100 mal so viel Wissen.
Wie können wir die Sache so weit vereinfachen, dass wir einen Webserver
genau so einfach benutzen könne, wie einen Taster?
Dennis S. schrieb:> Zwar nicht an mich gerichtet, aber da ich beruflich Berührungspunkte> damit habe... die beiden Seiten sind sehr gut, ersteres auch als> Print-Version verfügbar.>> https://eloquentjavascript.net/>> https://javascript.info/
Hast du auch Tutorials in einer richtigen Sprache? Die sind leider nur
in Englisch.
Luanlord schrieb:> Hast du auch Tutorials in einer richtigen Sprache? Die sind leider nur> in Englisch.
Englisch ist eine richtige Sprache. Und da es keine Einschränkung gab,
habe ich zwei sehr hochqualitative Seiten ausgewählt. Auf deutsch ist
mir nichts bekannt, weil für mich bisher nicht notwendig gewesen.
Übrigens sind die verlinkten Seiten durchaus mehr als Tutorials, sondern
fundierte Lehrwerke.
Und nein, ich kenne die Betreiber nicht und empfehle die Seiten aus
voller Überzeugung. ;-)
Luanlord schrieb:> Hast du auch Tutorials in einer richtigen Sprache? Die sind leider nur> in Englisch.
Ein Metzger arbeitet mit rohem Fleisch. Ein Feuerwehrmann hat mit Feuer
zu tun. Ein Chirurg sieht (und riecht) ständig Blut. Ein Taucher
arbeitet unter Wasser.
Und ein Programmierer ließt und schreibt fast alles in Englisch.