[0:01] Herzlich willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:09] In dieser Episode geht es weiter mit dem Buchclub zum Handbuch für Fachinformatiker. Viel Spaß!

[0:20] Hallo und herzlich willkommen zur siebzigsten Episode des Anwendungsentwickler-Podcasts.

[0:26] Mein Name ist Stefan Macke und ich hätte, glaube ich, nicht erwartet, dass ich irgendwann mal bei siebzig Episoden lande.

[0:31] Das ist ja der absolute Wahnsinn. Ich glaube, wenn ich das mal ausrechne, wie viele Stunden man inzwischen meinen Podcast am Stück hören kann

[0:38] und vollgeballert werden kann mit Wissen rund um die Ausbildung, da kommen, glaube ich, schon über 24 Stunden zusammen.

[0:44] Also irgendwie fast zwei Tage oder so kann man schon sich meine Stimme anhören. Wie schön!

[0:49] Ja, gut, dass ich mir die nicht selber immer anhören muss. Das ist schon mal ein Vorteil für mich.

[0:53] Aber heute geht es erstmal weiter mit dem Buchclub. Wir haben noch ein paar Kapitel vor uns.

[0:57] Dann ist das Handbuch für Fachinformatiker von Sascha Kersken dann auch mal durch.

[1:01] Aber dieses über tausendseitige Werk enthält natürlich einiges an Inhalt.

[1:05] Deswegen ist das heute schon die achte Episode zu dem Buch.

[1:09] Ich habe aber schon mir ein paar schöne Bücher ausgesucht, die ich dann bespreche, wenn ich mit dem Handbuch für Fachinformatiker durch bin.

[1:16] Doch bis dahin ist es noch eine kleine Zeit, denn wir haben noch ein paar Kapitel offen.

[1:21] Insbesondere auch die Programmierkapitel und das große Thema Datenbanken. Das liegt auch noch vor uns.

[1:26] Da habe ich gerade schon mit meinen Azubis entsprechende Termine abgesprochen, wann wir die Kapitel uns gemeinsam anschauen.

[1:31] Und ich werde das natürlich dann hier im Podcast nachziehen.

[1:34] Aber heute geht es erstmal um Kapitel 20 des Handbuchs für Fachinformatiker.

[1:39] Und das hat die Überschrift JavaScript und AJAX.

[1:43] Das heißt, heute geht es mal wieder hardcore um die Webentwicklung.

[1:47] Allerdings nicht um das Backend, wie es in den letzten 10 Episoden oder der letzten Episode war.

[1:53] Da haben wir über PHP zum Beispiel gesprochen.

[1:55] Nein, heute geht es ums Frontend, nämlich um JavaScript.

[1:58] Also den Part der Web App, der quasi im Frontend läuft, im Browser auf dem Client.

[2:04] Und ein wichtiges Thema, was auch für die Prüfung immer relevant ist, ist AJAX.

[2:09] Das ist auch in dem Kapitel untergebracht.

[2:11] Von daher heute ein paar prüfungsrelevante Inhalte drin.

[2:14] Auch ein paar, die nicht ganz so relevant sind.

[2:16] Aber deswegen machen wir das ja hier, damit ich das mal einmal durchgehe und erzähle,

[2:20] wovon ich glaube, was relevant ist für die Prüfung und für die Praxis und was nicht.

[2:24] Dann würde ich sagen, steigen wir doch direkt ein mit dem Kapitel zum Thema JavaScript.

[2:29] Und da sei es mir vielleicht kurz erlaubt, bevor wir mit den Inhalten einsteigen,

[2:33] einmal grob was zu JavaScript und zur Relevanz für die Prüfung zu erzählen.

[2:38] JavaScript ist halt heute die einzige Möglichkeit, wie ich im Browser Logik hinterlegen kann.

[2:44] Es gibt eigentlich nur die eine Sprache, die im Browser wirklich überall läuft und akzeptiert ist.

[2:50] Und deswegen muss ich eigentlich, wenn ich irgendwas im Bereich Webentwicklung mache,

[2:54] mich als Entwickler damit auseinandersetzen.

[2:57] Und das heißt dann auch entsprechend für die Prüfung mich damit auskennen.

[3:01] Ich hatte jetzt schon öfter auch im Kapitel zu PHP gesagt,

[3:04] dass in der Prüfung, weder in der schriftlichen noch in der mündlichen Prüfung,

[3:08] eigentlich was programmiersprachenspezifisches abgefragt werden wird.

[3:15] Also ich kann mir nicht vorstellen, dass irgendwann mal in der schriftlichen Prüfung so was steht wie

[3:18] wie heißt die Funktion zum Umdrehen von Arrays in PHP oder so.

[3:23] Denn das hieße ja, dass jeder Prüfling PHP programmieren können muss.

[3:26] Und das kann man einfach nicht voraussetzen.

[3:28] Also es gibt so viele verschiedene Programmiersprachen am Markt,

[3:30] da kann ich nicht erwarten, dass einzelne davon, ja, allen Prüflingen irgendwie beigebracht werden.

[3:35] Das ist einfach nicht zu leisten.

[3:36] Deswegen wird es so was in der Prüfung hoffentlich nicht geben.

[3:40] Also ich gehe stark davon aus, in den letzten Jahren war das definitiv nicht der Fall.

[3:43] Es kann aber hin und wieder vielleicht Ausnahmen geben, wo es so um grundsätzliche Funktionalitäten geht,

[3:48] wie zum Beispiel den Ablauf, wenn ich eine Website aufmache und da liegt eine Servergestützte Webanwendung dahinter.

[3:54] Was passiert denn wann und welche Komponente macht was in welcher Reihenfolge,

[3:58] wenn ich ein Request dahin schicke und so weiter.

[4:00] Und da könnte ich mir auch vorstellen, dass mal im Bereich JavaScript vielleicht was gefragt wird,

[4:05] weil es eben die einzige Möglichkeit ist, im Browser irgendwas zu machen.

[4:09] Allerdings ist es halt so, dass auch nicht jeder Anwendungsentwickler irgendwas im Web macht.

[4:13] Web ist natürlich das super Hype-Thema und alle finden Web toll,

[4:16] weil gerade natürlich auch die Startup-Unternehmen heutzutage und auch so große Player wie Google, wie Facebook, wie Netflix,

[4:23] die sind natürlich alle im Web aktiv und deswegen fokussiert sich auch so ein bisschen die Entwicklergemeinde natürlich auf diesen Bereich.

[4:28] Aber ich würde einfach mal behaupten, dass es noch einen riesengroßen anderen Teil an Entwicklern gibt,

[4:33] die überhaupt nichts mit dem Web machen.

[4:35] Die irgendwo Backend-Systeme bauen, die vielleicht sogar noch auf dem Mainframe mit in Anführungszeichen uralten Sprachen entwickeln

[4:41] und die mit JavaScript und AJAX einfach nichts am Hut haben und das ist auch völlig okay.

[4:45] Wenn ich zum Beispiel C-Entwickler bin und irgendwie Embedded Software für Autos programmiere,

[4:49] was soll ich mich da mit JavaScript auseinandersetzen?

[4:51] Das werde ich da niemals einsetzen, weil es einfach nicht sinnvoll ist.

[4:53] Trotzdem, wenn ich im Web-Umfeld mich bewege und ich würde einfach mal behaupten,

[4:58] dass ja von Entwicklern heute erwartet wird, dass sie sich zumindest mit dem Web mal auseinandergesetzt haben,

[5:04] auch wenn sie es nicht in ihrem Tagesjob brauchen, aber so zu so einer Ausbildung gehört das meiner Meinung nach dazu,

[5:09] weil es einfach eine sehr, sehr wichtige Plattform heutzutage ist.

[5:13] Also ich würde, ich könnte mich als Azubi glaube ich nicht darauf berufen zu sagen,

[5:17] ich lehne meinem Unternehmen nur C, ich muss hier nur Autoteile programmieren,

[5:21] lass mich mit dem Webzeug in Ruhe, davon will ich nichts hören.

[5:24] Das kann ich nicht machen.

[5:25] Genauso wenig, wie ich heute als Azubi sagen kann, komm Funktionalprogrammierung, Objektorientierung, das interessiert mich nicht.

[5:30] Ich programmiere seit drei Jahren prozedural und danach will ich abgefragt werden und Objektorientierung interessiert mich nicht.

[5:36] Auch das kann ich nicht sagen.

[5:37] Es gibt so ein bisschen gewisse Grundlagen, die ich als Entwickler einfach kennen muss.

[5:42] Meiner Meinung nach gehört auch das Web-Umfeld und gerade auch ein bisschen JavaScript dazu.

[5:46] Bedeutet nicht, dass jeder Entwickler JavaScript drauf und runter können muss, das nun wieder auch nicht,

[5:51] aber zumindest die groben Eigenschaften der Sprache, ich denke, die sollte man schon beherrschen und einmal erklären können.

[5:59] Also zum Beispiel, wie ist die Sprache typisiert und so weiter.

[6:02] Ich denke, das gehört dazu, weil JavaScript einfach so eine wichtige Programmiersprache heute ist.

[6:07] Das würde ich allerdings auch erwarten von Java oder von C, also von anderen Sprachen,

[6:11] die sehr dominant am Markt sind und immer nachgefragt werden.

[6:15] Da würde ich schon erwarten, dass ich die mal ein bisschen abgrenzen kann.

[6:17] Und dazu kann man halt wunderbar so ein paar allgemeine Eigenschaften der Programmiersprache heranziehen.

[6:22] Und dafür muss man auch nicht drei Monate oder drei Jahre in der Sprache entwickelt haben,

[6:26] sondern das kann man sich einfach mal angucken, ein paar Code-Beispiele anschauen

[6:29] und dann kann man das auch erklären und in der Prüfung glaubhaft rüberbringen, dass man sich damit auskennt.

[6:34] Gehen wir doch mal die Beispiele so ein bisschen durch, die ich da vielleicht kennen sollte.

[6:39] Vielleicht vorab, weil ich das auch schon mal in der Prüfung gehört habe.

[6:41] JavaScript hat rein gar nichts mit Java zu tun.

[6:46] Ich hatte auch mal einen Prüfling, der dann sagte, ja, JavaScript, das ist halt Java im Browser.

[6:50] Und das ist natürlich völliger Schwachsinn.

[6:52] Also gerade jetzt, wenn wir mal gleich die Eigenschaften durchgehen in der Sprache,

[6:55] dann werden wir sehen, dass JavaScript wirklich überhaupt nichts mit Java zu tun hat.

[6:58] Höchstens die vier Buchstaben im Namen.

[7:00] Und wenn ich mich recht entsinne, ich weiß nicht mehr, wo ich es gelesen habe und ob ich die Quelle noch wieder finde,

[7:05] aber die Schöpfer von JavaScript wollten halt irgendwie einen knackigen Namen haben.

[7:09] Und da Java damals gerade so voll der Hype war, kann man sich heute gar nicht mehr vorstellen.

[7:13] Java und Hype, das passt nämlich nicht zusammen.

[7:15] Aber damals war das mal so, als das gerade gestartet ist.

[7:17] Und da haben sie gedacht, Mensch, Java hört sich irgendwie cool an, wird gut akzeptiert.

[7:21] Nennen wir unsere Sprache doch JavaScript und versuchen so ein bisschen was von dem Ruhm abzubekommen.

[7:25] Aber die Sprachkonstrukte, das Paradigma, die Typisierung usw., die sind komplett unterschiedlich.

[7:32] Das heißt, ich kann bis auf so ein bisschen die Syntax, das ist auch eine C-ähnliche Sprache,

[7:36] das heißt, diese schönen geschweiften Klammern gibt es natürlich auch in JavaScript.

[7:39] Aber ansonsten kann ich so gut wie nichts wiederverwenden, was ich vielleicht bei Java gelernt habe.

[7:44] Von daher, bitte nicht durcheinander bringen, die Sprachen.

[7:47] Das sind wirklich völlig unterschiedliche Programmiersprachen und die haben erstmal wirklich nichts miteinander zu tun.

[7:52] Okay, jetzt aber mal zu den Eigenschaften von JavaScript, die ich also als Entwickler durchaus mal aufzählen können sollte.

[7:57] Fangen wir mit dem Wichtigsten an, der Typisierung und dem Paradigma.

[8:01] Typisiert ist JavaScript a. dynamisch und b. schwach.

[8:06] Du kennst vielleicht noch aus der einen oder anderen Podcast-Episode die Unterscheidung in stark und schwach bzw. statisch und dynamisch.

[8:15] Nein, stark und statisch sind nicht dasselbe, wenn du das nicht mehr ganz genau weißt.

[8:20] Nur kurz zur Erinnerung, statische Typisierung bedeutet, dass ich beim Kompilieren schon wissen muss,

[8:26] welchen Datentyp meine Variablen haben.

[8:28] Heißt insbesondere, dass ich in meinem Code auch überall die Typen vor die Variablen schreiben muss.

[8:34] Dynamische Typisierung erlaubt mir, jeden beliebigen Datentyp zu verwenden.

[8:38] Ich muss also meine Variablen nicht auf einen Datentyp festlegen.

[8:41] Und ich kann sogar auch diesen Datentyp zur Laufzeit ändern.

[8:44] Das heißt, ich kann in eine Variable, wo vorher eine Zahl drin stand, jetzt auf einmal auch meinen String reinschreiben.

[8:49] Das ist einfach so möglich.

[8:51] Der Compiler prüft das nicht, insbesondere weil es bei dynamischen Sprachen häufig gar keinen Compiler gibt,

[8:55] weil die häufig auch interpretiert werden.

[8:57] Und der Unterschied zwischen schwach und starke Typisierung.

[9:01] Starke Typisierung bedeutet, dass ich auch nicht zur Laufzeit einfach mal Typen ineinander umwandeln kann.

[9:07] Oder kurz gesagt, schwache Typisierung erlaubt mir eine implizite Typumwandlung und starke Typisierung nicht.

[9:14] Ein schönes Beispiel dafür kommt aus PHP.

[9:17] Da könnte ich ein if-Konstrukt benutzen und anstatt einen Boolchen-Ausdruck in der Klammer anzugeben,

[9:22] gebe ich einfach eine Zahl an.

[9:24] Und PHP würde dann zur Laufzeit gucken, ob diese Zahl zum Beispiel 0 ist.

[9:27] Wenn sie 0 ist, wird das als false ausgewertet.

[9:30] Und wenn sie nicht 0 ist, als true.

[9:32] Das heißt, ich kann quasi einen Integer-Ausdruck zum Beispiel für meinen if-Konstrukt benutzen.

[9:37] Und das wird implizit umgewandelt in einen Bool.

[9:41] Und dann funktioniert das einfach trotzdem.

[9:43] Und dann wundert mich man sich manchmal als Entwickler, hä, warum geht das überhaupt?

[9:46] Aber das kommt daher, weil die Promiesprache einfach mal implizite Typumwandlungen macht.

[9:50] Ohne, dass ich das vielleicht als Entwickler unbedingt haben will.

[9:53] Okay, das war die Typisierung.

[9:55] Dann kommen wir zum Paradigma.

[9:57] Grundlegend ist JavaScript objektorientiert.

[10:00] Man kann aber auch sagen, dass sie Multi-Paradigmen-Sprache ist.

[10:04] Und zwar kann ich eigentlich prozedural, funktional und objektorientiert irgendwie alles gemeinsam in JavaScript entwickeln.

[10:10] Ich kann einfach Funktionen definieren, quasi auf höchster Ebene, ohne dass ich die irgendeinem Objekt unterordnen muss.

[10:16] Das wäre dann quasi prozedural.

[10:18] Ich kann aber auch funktional entwickeln, insbesondere weil Funktionen in JavaScript,

[10:22] sag ich mal, man nennt das häufig in der funktionalen Programmierung ja,

[10:25] First Class Citizens sind.

[10:28] Das heißt, wenn ich Funktionen definiere, kann ich die auch hin und her reichen.

[10:31] Ich kann die in Variablen speichern, ich kann die als Parameter an andere Funktionen übergeben.

[10:35] Und ich kann sie auch als Rückgabewert von anderen Funktionen bekommen.

[10:38] Das sind dann so diese First Class Functions.

[10:41] Und das Ganze kommt ja aus der funktionalen Programmierung.

[10:45] Es geht auch in JavaScript und von daher ist JavaScript also auch in Teilen funktional.

[10:49] Und zuletzt kann ich auch objektorientiert in JavaScript auf jeden Fall entwickeln.

[10:53] Aber, jetzt kommt das wirklich große Aber,

[10:56] das hat eigentlich nichts mit der Objektorientierung zu tun, die wir zum Beispiel aus Java C Sharp oder so kennen.

[11:01] Denn JavaScript ist prototypbasiert und klassenlos.

[11:05] Das heißt, ich kann in JavaScript keine Klasse programmieren.

[11:08] Und das war auch schon eine häufige Prüfungsfrage, die ich immer gestellt habe im Fachgespräch.

[11:13] Und wenn ich dann frage, ist Java objektorientiert, dann ging es schon so ein bisschen los.

[11:17] Ja, ich glaube schon, so nach dem Motto.

[11:20] Und wenn man dann konkret die Frage stellt, ja, kann man denn in JavaScript Klassen definieren,

[11:24] dann sagen ganz viele Prüflinge, ja.

[11:26] Und dann frage ich mich, hä, wie?

[11:28] Und dann geht es dann los mit dem Schwimmen.

[11:30] Und dann, ja, ich kann doch da machen, Function …

[11:32] Und dann ist es klar, das ist leider keine Klasse, sondern das ist halt eine Function, die man da gerade definiert hat.

[11:37] Das ist ja eben nicht dasselbe.

[11:39] Also, JavaScript ist klassenlos. Ich kann dort keine Klassen bauen.

[11:42] Stattdessen arbeite ich mit sogenannten Prototypen.

[11:44] Mit Prototypen erlauben es mir zum Beispiel auch, die Vererbung in JavaScript zu benutzen,

[11:49] indem ich quasi so eine Art, ja, wie soll man das ganz einfach erklären,

[11:52] indem ich einem Objekt quasi seine Basisklasse unterjubel.

[11:56] Ich kann sowas machen wie mein Objekt.prototype gleich und dann ein anderes Objekt.

[12:02] Und das bedeutet, dass dann quasi die, ja, ich sage einfach mal die Basisklasse,

[12:06] obwohl es halt keine Klassen gibt, dass die dann eben auf eine bestimmte andere Klasse gesetzt wird.

[12:11] Und damit habe ich quasi eine Vererbung umgesetzt.

[12:14] Aber am besten in der Prüfung gar nicht das Wort Klasse in den Mund nehmen,

[12:17] denn wie gesagt, JavaScript kennt keine Klassen.

[12:19] Eigentlich kennt JavaScript nur Objekte.

[12:21] Und die Idee des Prototypen ist dann halt, dass ich ein Objekt habe und auf Basis dieses Objekts,

[12:26] das ist quasi mein Prototyp, kann ich dann weitere Objekte erzeugen.

[12:30] Und das macht mir JavaScript dann auch relativ einfach.

[12:32] Ich kann die dann quasi, ja, wie soll man sagen, so eine Art duplizieren

[12:35] und dann zum Beispiel die Eigenschaften verändern.

[12:37] Und dann habe ich halt eben neue Objekte erzeugt,

[12:39] ohne überhaupt irgendwann mal eine Klasse quasi als Bauplan benutzt zu haben.

[12:44] So, nachdem wir das geklärt haben, würde ich sagen, gehen wir mal in die Inhalte des Kapitels rein.

[12:48] Und es geht dann direkt los mit JavaScript und HTML-Dokumenten.

[12:53] Und JavaScript ist natürlich absolut sinnvoll, wenn man irgendwas mit HTML macht, also im Frontend.

[12:59] Denn mit JavaScript kann ich halt meine HTML-Seiten und meine HTML-Formulare insbesondere auch interaktiv gestalten.

[13:06] Das heißt, ich kann so ein bisschen, ja, Interaktion, ja, wie Tadford auch schon sagt, in mein Formular reinbringen.

[13:12] Das heißt, wenn ich irgendwo draufklicke oder wenn ich irgendwas highlighte oder sonst was,

[13:15] dann wird halt irgendein Code wirklich ausgeführt.

[13:17] HTML selbst ist keine Programmiersprache.

[13:20] Ich hoffe, das weißt du inzwischen.

[13:21] Das ist auch meine Standardfrage an Prüflinge, wenn die irgendwie sowas sagen wie,

[13:26] ja, ich habe auch schon seit Jahren programmiert in HTML.

[13:28] Dann frage ich immer, ist HTML eine Programmiersprache?

[13:30] Und dann kannst du hoffentlich inzwischen sagen, nein, HTML ist keine Programmiersprache.

[13:35] Denn inhärente Bestandteile von Programmiersprachen wie zum Beispiel Verzweigung und Wiederholung sind in HTML nicht möglich.

[13:41] Das heißt, ich kann nicht programmieren, ich kann nur Sachen auszeichnen, und zwar Text.

[13:45] Ja, darum geht es in HTML.

[13:47] Und wenn ich jetzt in irgendeiner Form da eine Interaktivität reinbringen will,

[13:50] also irgendein Verhalten, eine Funktionalität umsetzen will, dann brauche ich halt JavaScript.

[13:54] Und damit kann ich dann entsprechend programmieren, wie gesagt, schleifen und weiß der Geier was.

[13:59] Das ist halt eine richtige Programmiersprache, ja.

[14:01] Okay. Und da geht es jetzt im Kapitel auch los mit so ein paar grundsätzlichen Funktionen von JavaScript,

[14:06] was ich damit halt eben so machen kann.

[14:10] Insbesondere geht es hier los mit der ersten Frage, wie kriege ich überhaupt mein JavaScript ins HTML rein?

[14:15] Da gibt es auch verschiedene Möglichkeiten, genau wie es bei CSS der Fall ist.

[14:19] Da gab es drei verschiedene, das hatten wir in einer der letzten Episoden.

[14:22] JavaScript gibt es auch mehrere Möglichkeiten.

[14:24] Ich kann das quasi inline reinbauen in meine HTML-Elemente.

[14:28] Ich kann das in den Head einbauen, der HTML-Datei.

[14:30] Und ich kann es auch, was ich empfehlen würde, sauber in Anführungszeichen in externe Dateien packen,

[14:36] damit ich dann zum Beispiel auch mit einer vernünftigen IDE meinetwegen oder mit einem guten Code-Editor

[14:41] da drin vernünftig arbeiten kann, Kurvevollständigung habe und so weiter.

[14:44] Das geht auch, wenn ich es inline mache.

[14:45] Sicherlich ist es aber nicht so schön, wenn ich meine Logik und meine Darstellung so ein bisschen vermenge.

[14:52] Das haben wir bei CSS ja auch gemacht.

[14:54] Da ziehen wir die Gestaltung und den Inhalt auseinander.

[14:56] Und das sollten wir unbedingt auch bei JavaScript machen.

[14:58] Also HTML soll wirklich nur die Bedeutung des Textes darstellen.

[15:02] Mein Layout packe ich bitte in externes CSS und meine Funktionalität in externes JavaScript.

[15:07] Dann habe ich alles drei wunderbar getrennt und kann alles eventuell unabhängig voneinander anpassen

[15:12] und besser pflegen auf jeden Fall.

[15:15] Gut, dann geht es ja los mit so ein paar grundsätzlichen Beispielen.

[15:18] Wie kann ich mit JavaScript was ins HTML ausgeben und wie greife ich auf die Elemente in meinem HTML-Baum zu und so weiter.

[15:26] Wirklich auch Grundlagen der Programmiersprache wie Vergleiche und Schleifen und so weiter und Arrays.

[15:32] Das wird hier also durchgegangen und auch der Unterschied z.B. zwischen Array und Objekte.

[15:36] Denn das ist nicht unbedingt immer so selbsterkennend in JavaScript.

[15:39] Man kann nämlich z.B. auf Objekte auch zugreifen mit so einer sehr Array-ähnlichen Syntax.

[15:44] Ich könnte z.B. bei meinem Objekt, indem ich einfach Ecke, Klammern dahinter schreibe

[15:49] und dann den Namen eines Attributs z.B. in die Array-Klammern rein.

[15:54] Also quasi wie der Zugriff auf ein assoziatives Array in PHP mit String als Index quasi,

[15:59] könnte ich auch auf die Attribute eines Objekts zugreifen.

[16:02] Das heißt, das verschwimmt so ein bisschen, dieser Unterschied zwischen Array und Objekt.

[16:06] Und das sollte man auch kennen oder verstehen, wenn man sich denn JavaScript-Programme anguckt.

[16:11] Deswegen ist das ganz gut, dass das hier erläutert wird.

[16:13] Außerdem wird natürlich auch noch mal auf die Funktion als solches eingegangen, wie man die definiert

[16:18] und dass quasi Objekte auch nichts anderes sind als Funktionen, die so ein paar Eigenschaften haben.

[16:23] Und da wird jetzt halt auf die Besonderheiten von JavaScript eingegangen und ein paar wichtige Funktionen gezeigt.

[16:28] Sowas wie Substring und IndexOff und solche Sachen wird hier einmal kurz gezeigt.

[16:34] Die ganzen Funktionen sind natürlich für die Praxis unerlässlich.

[16:37] Sowas muss ich wissen, wenn ich mein erstes JavaScript-Programm schreibe.

[16:40] Geht's schon los? Wie definiere ich denn Strings und Zahlen und Funktionsaufrufe usw.?

[16:45] Muss ich alles wissen. Für die Prüfung ist das natürlich wieder eher irrelevant.

[16:49] Das hatte ich aber ja am Eingang schon gesagt.

[16:51] Also wenn wir jetzt die einzelnen Funktionen hier durchgehen, dann ist das gut,

[16:55] wenn ich in der Praxis mit JavaScript was machen will, dass ich weiß, wie es funktioniert.

[16:58] Für die Prüfung würde ich die Dinger niemals auswendig lernen,

[17:01] weil die in jeder Programmiersprache wahrscheinlich irgendwie ein bisschen anders heißen,

[17:04] die Parameter irgendwie anders sind usw.

[17:06] Das wäre verschwendete Zeit, sowas für die Prüfung zu lernen.

[17:10] Die Prinzipien z.B. von einem Substring oder von einem IndexOff, die sollte ich erklären können.

[17:16] Aber die konkrete Syntax einer Programmiersprache, das ist nicht nötig,

[17:20] sowas für die Prüfung zu beherrschen.

[17:22] In der Prüfung geht es sowieso immer nur um Pseudocode,

[17:24] da ist die konkrete Programmiersprache wirklich völlig irrelevant.

[17:27] Die nächsten Unterkapitel des ersten Einstiegskapitels sind dann z.B. Datums- und Uhrzeitfunktionen,

[17:33] wo dann genau gesagt wird, wie ich auf einzelne Bestandteile von Datumsangaben zugreifen kann usw.

[17:39] Dann kommt als nächstes die Manipulation von Bildern.

[17:42] Das finde ich schon sehr speziell, muss ich sagen.

[17:45] Also bis man sowas tatsächlich in der Praxis mal braucht,

[17:48] also für die Prüfung z.B. finde ich das völlig irrelevant, muss ich ehrlich sagen.

[17:53] Ist eine nette Sache, wenn ich wirklich ein bisschen tiefer in JavaScript einsteigen will,

[17:57] dann brauche ich das vielleicht mal irgendwann, aber für die Prüfung und ganz ehrlich gesagt,

[18:01] meiner Meinung nach auch für die Praxis ist das glaube ich nicht ganz so sinnvoll,

[18:04] wenn man sich das im Detail anguckt.

[18:06] Aber es sind auch nur ein paar Seiten, von daher kann man mal drüber lesen.

[18:09] Der nächste Unterkapitel, das sind die Browser- und Fensteroptionen.

[18:12] Das ist dann schon wieder interessanter, denn damit kann ich natürlich meinen Browser steuern

[18:16] und das wirkt sich natürlich auch direkt auf das sichtbare Verhalten für den Anwender aus.

[18:20] Und da sollte ich schon ein bisschen darüber Bescheid wissen, was ich da tun kann.

[18:24] Und vor allem sind da auch die neuen HTML5-Funktionen drin,

[18:27] wie z.B. dass ich die Browser-History manipulieren kann,

[18:32] bzw. auch z.B. diesen Vor- und Zurück-Button im Browser nachbilden kann.

[18:37] Und wenn ich also z.B. innerhalb meiner Seite, wenn ich diese berühmten Single-Page-Apps habe,

[18:41] wo heutzutage alles nur noch in JavaScript im Frontend quasi in einer einzigen HTML-Seite abläuft,

[18:46] da kann ich dann z.B. die Back- und Forward-Buttons nachbauen

[18:51] und dann auch innerhalb einer einzigen Seite vor und zurück korrekt implementieren,

[18:57] sodass es sich für den Benutzer so anfühlt, als wäre er auf einer ganz normalen Website,

[19:02] obwohl er eigentlich gerade alles lokal bei sich im Browser ablaufen lässt.

[19:08] Was ich schön finde auch hier im Kapitel ist, dass Herr Kerstin auch durchaus sagt,

[19:11] dass man gewisse Sachen zwar machen kann, sie aber nicht machen sollte,

[19:14] wie z.B. ständig neue Pop-Up-Fenster öffnen usw.

[19:17] Das geht natürlich den Benutzern extrem auf die Nerven,

[19:20] und da sollte man schon vorsichtig sein, wenn man sowas machen möchte.

[19:23] Das ist also heutzutage eigentlich völlig verpönt,

[19:26] wenn da ständig, wenn ich eine Website aufmache, irgendwie 57 Pop-Ups aufgehen.

[19:29] Natürlich am besten noch mit irgendeiner nervigen Werbung oder mit irgendwelchen sehr fragwürdigen Inhalten.

[19:34] Wenn dann mal der Chef über die Schulter schaut, wenn gerade so ein Fenster auf ist,

[19:37] das kommt dann immer nicht ganz so gut.

[19:39] Von daher bitte nicht in der eigenen Anwendung sowas Seltsames bauen.

[19:43] Dafür gibt es heute bessere Möglichkeiten, bzw. man lässt diese Pop-Ups am besten einfach weg.

[19:47] Man kann auch anders die Inhalte dem Benutzer präsentieren, sodass sie ihm auffallen.

[19:51] Ich brauche da also nicht irgendwie am besten noch modale Fenster,

[19:54] die ich nicht wieder oder wo ich nicht in anderen Fenstern weiterarbeiten kann,

[19:57] bevor ich das Fenster zugemacht habe usw.

[19:59] Also ganz, ganz schrecklich. Bitte nicht benutzen.

[20:01] Aber das wird hier auch gut beschrieben.

[20:03] Und das finde ich auch wichtig, dass man so ein bisschen Tipps auch für die Praxis mitgibt, auch für vernünftige Softwareentwicklung und nicht einfach

[20:10] ja, so machen sie drei neue Fenster auf einmal auf und feuerfrei, so nach dem Motto. Also von daher finde ich gut.

[20:17] Und wenn wir dann mal mit diesen Standardfunktionen durch sind, sage ich mal, dann geht es mit dem nächsten Kapitel weiter und das heißt

[20:24] DHTML und DOM. Und das DOM, das Document Object Model, wenn du das noch nicht kennst, dann solltest du dir das dringend anschauen.

[20:31] Das ist was, wo ich sagen würde, das sollte jeder Anwendungsentwickler kennen.

[20:35] HTML und auch XML, da werden wir in einer der nächsten Episoden darauf eingehen, arbeiten eben mit diesem Document Object Model. Das ist quasi die

[20:43] Repräsentation des Dokuments im Speicher und das kann man sich vorstellen einfach wie einen Baum. Jedes XML-Dokument und HTML zählt ja zu

[20:51] XML-Dokumenten, beginnt mit einem Wurzelelement und mit einem einzigen Wurzelelement, das ist das Wichtige, und darunter ordnen sich dann die

[20:58] untergeordneten Elemente eben wie in einem Baum in Form von Zweigen und Blättern an. Und über dieses DOM, das ist eigentlich eine

[21:05] Programmier-Schnittstelle, kann ich jetzt auf dieses

[21:08] auf dieses Baum-Modell zugreifen und mir dann zum Beispiel einzelne Attribute rausholen oder auf einzelne Elemente zugreifen. Ich kann Elemente hinzufügen,

[21:17] manipulieren und so weiter. Das heißt, das ist eigentlich meine Schnittstelle, um dieses HTML-Dokument zu

[21:22] manipulieren, sage ich einfach mal, um Sachen rauszulesen, aber auch eben Sachen wieder reinzuschreiben.

[21:26] Und das ist eigentlich ein wichtiges Konzept, was ich sowohl für XML als auch für HTML benutzen kann. Und von daher würde ich mich da als

[21:33] Anwendungsentwickler unbedingt mit auseinandersetzen. Könnte ich mir auch gut vorstellen, dass sowas mal in der Prüfung

[21:38] drankommt. Wenn du insbesondere ein Web-Projekt als Abschlussprojekt hast, würde ich zum Beispiel in der mündlichen Prüfung

[21:44] definitiv mal zu diesem DOM was fragen, weil das für mich einfach zum Grundwissen in der Web-Anwendung gehört, in der Web-

[21:51] Anwendungsentwicklung gehört.

[21:53] Und in dem entsprechenden Kapitel geht es dann auch mit den Standard-JavaScript-Funktionen los, nämlich sowas wie getElementById

[21:59] oder getElementsByTagName. Das sind dann halt so ein paar, oder in diesem Fall zwei

[22:04] Standardfunktionen, um eben auf einzelne HTML-Elemente

[22:08] zuzugreifen. Und weil das eben so so wichtig ist, quasi das ist das Allererste, was ich mache, wenn ich mein erstes JavaScript-Programm schreibe,

[22:14] brauche ich wahrscheinlich schon irgendwie eine Möglichkeit, um ein Element in meinem Baum zu manipulieren. Sei es nur, um den Text da auszulesen.

[22:20] Meinetwegen, ich habe irgendwo ein kleines Input-Element reingebaut und darunter ein Button, und wenn ich den Button drücke, soll jetzt halt der Text, den

[22:25] ich in das Input-Element eingegeben habe, irgendwie ausgelesen werden und meinetwegen wieder ausgegeben oder irgendwo hingeschickt oder wie auch immer.

[22:31] Allein dafür brauche ich schon eine Möglichkeit, um überhaupt den Text aus dem Element auszulesen. Und das mache ich meinetwegen mit einem getElementById.

[22:40] Übrigens, die Möglichkeiten, um dann darauf zuzugreifen, in diesem Fall getElementById, das bezieht sich auf die

[22:46] HTML-Attribute ID und das Gleiche gibt es auch noch für Class, die auch für CSS benutzt werden. Und bei ID, in der

[22:53] CSS-Folge hatten wir schon darüber gesprochen, dass IDs immer eindeutig sein müssen. Deswegen kann ich die natürlich wunderbar benutzen, wenn ich genau aus einem

[23:00] gezielten Element was auslesen möchte. Ist es halt getElementById und dann den ID-Namen da rein und da kann ich sicher sein, dass ich genau

[23:07] dieses Element direkt im Zugriff habe und kann es halt manipulieren. Von daher, das alles funktioniert immer super, wenn ich sauber

[23:14] strukturiertes

[23:16] und semantisch korrektes HTML benutze. Denn dann kann ich zum Beispiel sicher sein, dass es eben

[23:23] Elemente mit einer ID auch nur einmal gibt. Wenn ich nicht ganz so viel Wert darauf lege, wie ich mein

[23:29] Dokument strukturiere und mich auch nicht unbedingt vielleicht an diese, nicht nur Richtlinien, sondern an diese Regel halte, dass ein ID oder eine ID nur

[23:36] einmal vergeben wird, dann hat JavaScript es jetzt sehr, sehr schwer, genau das Element rauszusuchen und dann ist es vielleicht so ein bisschen

[23:42] Glückssache, welches er erwischt, beziehungsweise er wird wahrscheinlich immer das allererste Element finden mit dieser ID, aber vielleicht nicht genau das, was ich

[23:48] eigentlich haben will. Von daher, noch mal hier wiederholt der Tipp, wenn du was mit Webentwicklung machst, achte auf sauber, auf korrektes,

[23:56] auf wohlgeformtes und valides HTML. Das macht es sowohl mit CSS als auch mit JavaScript deutlich

[24:03] einfacher, dagegen zu entwickeln.

[24:05] Ja, im Kapitel wird dann jetzt richtig was aus der Quelltext-Kiste geholt. Hier werden also durchaus hier mit einem großen Switch

[24:13] Case-Statement einzelne Knoten durchgegangen. Es wird das komplette DOM in einem Browser-Fenster ausgegeben und so weiter, also teilweise schon zwei, drei Seiten

[24:21] komplett mit Quelltext voll. Finde ich auch gut, dass man da so ein paar Beispiele mal sieht, ist aber dann auch vielleicht wieder zum Lernen etwas viel.

[24:27] Also, wenn ich jetzt nicht gerade JavaScript

[24:30] einsetzen möchte, dann ist das schon ein bisschen sehr viel Quelltext und für die Prüfung, wie gesagt, ist das eben irrelevant. Von daher,

[24:37] wenn du was mit JavaScript machst, okay, würde ich es auch mal ausprobieren.

[24:40] Einfach nur, um mit JavaScript mal so ein bisschen

[24:43] warm zu werden, was für die Prüfung zu lernen. Dafür ist es dann vielleicht ein bisschen viel.

[24:47] Dann geht es weiter im Kapitel, wie ich jetzt halt konkrete Elemente in meinen DOM rein bekomme.

[24:53] Und das ist dann quasi auch das letzte Kapitel, bevor es losgeht mit AJAX. Denn AJAX ist jetzt genau der Anwendungsfall, wo ich das alles

[24:59] brauche, im Prinzip. Im Standard mache ich ja als Beispiel sowas. Ich klicke auf den Button und dann wird aus einem Input-Element

[25:06] ein Text ausgelesen. Der wird an den Server geschickt und da kriege ich irgendein Ergebnis zurück. Und dieses Ergebnis möchte ich wieder in meinen DOM

[25:13] einbauen. Und da brauche ich jetzt alles das, was vorher beschrieben wurde, nämlich aus dem Element was auslesen und auch in den DOM wieder was

[25:19] einbauen. Von daher ist es schon ein guter Aufbau hier im Buch. Es werden die Grundlagen erst mal gezeigt, wie das überhaupt

[25:25] grundsätzlich funktioniert. Und dann kommt ein konkreter Anwendungsfall eben mit AJAX.

[25:30] AJAX ist absolut prüfungsrelevant, sofern du irgendwas mit Web-Entwicklung machst sowieso. In der mündlichen Prüfung ist es Standardfrage,

[25:37] was ist der Vorteil oder der Nachteil von AJAX gegenüber klassischen Web-Anwendungen. Und auch in der schriftlichen Prüfung kam das schon ein paar Mal dran,

[25:44] nämlich genau auch in diesem Kontext. Was hat eigentlich AJAX für Vor- und Nachteile? Und auf dieser Ebene würde ich mir das auch angucken, wenn

[25:51] du dich für die Prüfung vorbereitest. Genau wie jede andere Technologie ist AJAX jetzt kein Wundermittel, um irgendwelche Webseiten auf einmal total modern und

[25:58] toll und schnell zu machen, sondern man muss immer abwägen, was es für Vor- und Nachteile gibt.

[26:04] Genau das Gleiche gilt auch für AJAX im Vergleich mit klassischen Anwendungen. Aber vielleicht noch mal kurz als Einführung, wenn du AJAX noch nicht mehr

[26:11] gehört hast oder nicht mehr genau weißt. AJAX steht für Asynchronous JavaScript and XML.

[26:17] Das ist also eine schöne Abkürzung, ein schönes Akronym. Das kann man auch mal auswendig lernen.

[26:21] Das erwarte ich auch, dass die Leute das dann können. Und vor allem, wenn man dieses Akronym beherrscht, dann weiß man auch, was dahinter steckt.

[26:28] Asynchronous JavaScript and XML.

[26:32] Asynchronous steckt da schon drin, weil es so wichtig ist. Das bedeutet nämlich, dass ich eine asynchrone Anfrage an meinen Server schicke. Und

[26:39] asynchron bedeutet, dass mein Hauptausführungs-Thread nicht blockiert. Das heißt, wenn mein Browser die Webseite aufmacht und ich würde einen

[26:47] synchronen,

[26:49] eine synchrone Anfrage an den Server schicken, dann würde der Browser so lange warten, bis dieser Request zurückkommt. Und in dieser Zeit kann ich

[26:56] nichts machen. Das heißt, mein Browser würde im Prinzip einfrieren, bis ich dann meine Antwort kriege. Und Asynchronous bedeutet, also

[27:03] asynchron, ich schicke irgendwas in einem anderen Thread zum Beispiel an den Server. Und wenn da dann was zurückkommt, dann

[27:10] kriege ich das mit. Ich kriege automatisch, ich werde quasi zurückgerufen.

[27:14] Und sobald das der Fall ist, kann ich dann weitermachen. Aber in der Zeit, wo ich auf diesen Rückruf warte,

[27:19] kann der Rest meiner Anwendung einfach ganz normal weiterlaufen. Das heißt insbesondere, dass mein Browser halt

[27:24] ja, funktional

[27:28] auf deutsch heißt es auch gerne,

[27:30] auf deutsch heutzutage nennt man das auch gerne

[27:33] responsiv bleibt. Ja, im Sinne von responsive. Das heißt, ich kann mit dem Ding weiter arbeiten im Prinzip.

[27:40] Darum geht es eigentlich.

[27:41] Und vor allem werde ich nicht blockiert, wenn nämlich dieser asynchrone Aufruf einfach ewig dauert, weil ich zum Beispiel gerade mit dem Handy unterwegs bin

[27:47] und habe schlechten Empfang oder so. Dann kann es ja sein, dass so ein Aufruf auch mal ein paar Sekunden dauert. Und wenn ich so lange dann

[27:52] nichts mehr machen kann, da wird der Anwender ziemlich schnell sauer. Deswegen ist das Asynchronous ziemlich wichtig bei der ganzen Geschichte.

[27:59] Es funktioniert ausschließlich mit JavaScript. Hatten wir eben schon erklärt. HTML, damit kann ich halt eben alleine nichts programmieren. Ich brauche also eine Programmiersprache,

[28:06] die diesen Aufruf macht an den Server. Und das ist nun mal halt JavaScript. Das AND, ich glaube, da brauchen wir nicht drauf eingehen. Und das XML am Ende

[28:14] ist deswegen so interessant, weil zu Beginn dieser Technologie das

[28:18] Datenaustauschformat zwischen dem Frontend und dem Backend XML war. Das heißt, ich habe mir mit JavaScript eine XML-Struktur

[28:25] zusammengebastelt, zum Beispiel aus den Inhalten, die der Benutzer gerade in irgendein Feld eingegeben hat. Und dieses XML habe ich einem Server geschickt, der hat es

[28:32] auseinandergenommen, hat damit irgendwas gemacht und hat mir auch XML zurückgeschickt. Und dann geht JavaScript her, nimmt dieses XML, was es gerade

[28:40] erhalten hat, auseinander und baut das irgendwie als HTML-Elemente zum Beispiel wieder in den

[28:45] Dokumentenbaum ein. Deswegen heißt es AJAX mit X hinten, weil es halt XML damals war.

[28:52] Heutzutage, sage ich gleich dazu, wird das wahrscheinlich in den wenigsten Fällen noch mit XML gemacht, sondern ausschließlich mit JSON. JSON ist viel, viel einfacher mit

[29:00] JavaScript zu verarbeiten, denn JSON, wie der Name schon sagt, JavaScript Object Notation, das ist quasi eine direkte Notation für

[29:08] JavaScript-Objekte. Die kann ich ganz einfach gesagt mit einer Zeile Code in JavaScript einlesen und erzeugen lassen.

[29:14] Und mit XML ist das deutlich schwieriger. Da brauche ich also einen XML-Parser, der es auseinander nimmt, dann ist es vielleicht nicht valide und

[29:19] bla und blubb. Und das dauert ewig und kostet viel Speicher. Und JSON ist ein Format, das kann ich wirklich mit ganz wenig Aufwand mit

[29:26] JavaScript einlesen und verarbeiten. Und außerdem ist es auch noch geringer vom Datenvolumen, denn bei XML gibt es halt diese ganz vielen

[29:34] wiederholten, öffnen und schließenden Tags. Wenn ich zum Beispiel habe mein toller Tag und dann kommt der Inhalt und dann kommt

[29:40] slash mein toller Tag nochmal. Das heißt, es ist einfach doppelt. Alle Namen sind doppelt. Dazu kommen noch die ganzen Klammern und

[29:47] Anführungszeichen und ich weiß nicht, was da alles noch dazugehört. Und bei JSON ist es halt deutlich kürzer. Da kann ich halt zum Beispiel Arrays

[29:53] definieren, indem ich einfach Klammern aufmache, also eckige Klammern, dann schreibe ich einfach ein paar Objekte da rein und fertig. Ja, das ist also ganz, ganz

[30:00] wenig Zeichen, um quasi das Gleiche auszudrücken, was ich auch mit XML ausdrücken kann.

[30:05] Deswegen wird das heute fast ausschließlich mit JSON gemacht, weil es einfach schneller ist und auch noch weniger Datenvolumen produziert.

[30:11] Aber grundsätzlich sollte man sich die Frage stellen, ob AJAX immer das Richtige ist, denn AJAX hat halt auch ein paar Nachteile. Nummer eins,

[30:18] es geht nur, wenn ich JavaScript aktiviert habe. Wenn ich kein JavaScript habe in meinem Browser, dann wird einfach nichts passieren, wenn ich auf

[30:24] einen Button drücke. Ja, das wäre der erste Nachteil. Und der zweite wäre zum Beispiel auch, dass ich zwar weniger Daten an den Server sende,

[30:30] dafür aber mehrere Requests. Denn wenn ich einfach nur die Seite einmal neu lade, muss ich zwar

[30:35] mehr Daten übertragen, habe aber nur ein Request an den Server. Wenn ich zum Beispiel jedes Mal, wenn ich in meinem großen Formular ein

[30:42] Feld verlasse, eine Validierung mache und jedes Feld einzeln validiere, dann habe ich vielleicht bei einem Formular auf einmal 20 Requests, weil jedes Feld

[30:49] individuell gegen den Server validiert wird. Und da muss ich halt schon abwägen. Ist es mir das wert? In den meisten Fällen kann man zum Beispiel,

[30:56] wenn man große Dokumente überträgt, durch eine schöne Kompensation auf Serverseite dafür sorgen, dass trotzdem wenige Daten über die Leitung laufen,

[31:02] ich aber nur ein Request habe. Bei 20 Requests mal zum Beispiel 100 User, die das gleichzeitig machen, da habe ich auf einmal

[31:09] 2.000 Requests, wo ich vorher nur 100 hatte. Und da muss ich schon überlegen,

[31:13] kann ich den Server besser auf Requests skalieren oder auf die übertragene Datenmenge? Von daher kann man nicht einfach sagen,

[31:19] AJAX ist immer besser als das normale Verfahren. Das ist es nicht. Man muss schon genau überlegen, wann man es einsetzt und wann nicht.

[31:27] So, die Prinzipien von AJAX, die werden jetzt in dem Kapitel hier auch schön erklärt. Der Rest des Kapitels ist dann allerdings Code.

[31:33] Das heißt, Frontend und Backend, mit PHP übrigens, wird dann hier tatsächlich programmiert. Ein lauffähiges Beispiel. Die sind also wirklich

[31:41] seitenweise dann auch Code-Beispiele drin tatsächlich. Aber es wird halt auch, wie ich gerade schon gesagt habe, auf den Unterschied zwischen XML und JSON

[31:47] noch mal eingegangen von Nachteile. Und von daher finde ich das Kapitel insgesamt schon sehr schön. Aber wie im Beispiel für den

[31:55] REST-Client, der in PHP entwickelt wurde, ist mir das dann für die Prüfung zu Programmiersprachen spezifisch. Also es ist wirklich dann PHP und

[32:02] JavaScript zusammen. Das ist eine super Mischung für Web-Anwendungen, keine Frage. Für eine Prüfungsvorbereitung wäre es mir zu speziell.

[32:09] Aber ich finde es gut, dass hier mal wirklich ein lauffähiges Beispiel drin ist, dass man sich auch mal vorstellen kann, wie dieses AJAX denn jetzt genau

[32:16] eigentlich funktioniert. Denn das können auch relativ wenige Prüflinge erklären, obwohl es fast in jeder modernen Web-Anwendung benutzt wird. Also bitte, bitte, bitte,

[32:25] insbesondere, wenn du eine Web-Anwendung als Abschlussprojekt machst, setz dich damit auseinander und leg dir eine

[32:31] Musterlösung quasi zurecht, wie du mir erklärst, was AJAX ist. Denn das erwarte ich einfach, wenn du das in deinem Code benutzt hast.

[32:38] Das letzte Unterkapitel im Oberkapitel JavaScript ist jetzt in der neuen Version

[32:43] dazugekommen, in der neuen Auflage. In der Web-Version ist es noch nicht enthalten und das ist jQuery. jQuery ist eigentlich so

[32:51] synonym heutzutage, fast für JavaScript. Das sieht man immer schön, wenn man bei Stack Overflow irgendwas fragt. Wie mache ich XY mit JavaScript?

[32:58] Und dann sind mit die ersten Antworten immer, mach es mit jQuery. Weil jQuery eigentlich heute so eine Art

[33:05] Abstraktionsschicht, so eine allgemeine Abstraktionsschicht inzwischen geworden ist, zwischen JavaScript und den konkreten Browsern dahinter.

[33:12] Gestartet ist es deswegen, weil jeder Browserhersteller JavaScript irgendwie ein bisschen anders interpretiert hat und man ähnlich wie in CSS

[33:19] quasi immer irgendwelche Browserweichen einbauen musste, weil irgendetwas nicht so funktioniert, wie es funktionieren soll. Und dadurch

[33:26] wurde jQuery als Zwischenschicht quasi gebaut,

[33:29] als Abstraktionsschicht, als Sammlung von Funktionen, wo ich zum Beispiel mit noch weniger Code als in JavaScript auf einzelne

[33:36] Elemente meines Doms zugreifen kann, dann mir aber sicher sein kann, dass das in jedem Browser zum Beispiel

[33:41] sauber funktionieren wird. Und das Ding hat sich einfach so etabliert. Es gab eine Zeit lang oder gibt es auch immer noch

[33:47] Alternativen zu jQuery. Ich würde aber sagen, in der Praxis gibt es eigentlich

[33:51] keine Alternative dazu, denn ganz viele Bibliotheken setzen auch auf jQuery auf und benutzen das im Hintergrund

[33:58] mit Bootstrap zum Beispiel, dem Twitter-Framework, kann ich damit arbeiten. Das kann ich eigentlich überall rein basteln,

[34:05] dieses jQuery. Und das ist einfach so

[34:07] dominant im Web, dass es also meiner Meinung nach nicht sinnvoll ist, noch ein anderes Framework einzusetzen, weil jQuery einfach so der

[34:13] Platzierisch ist. Und das Schöne an dem Kapitel ist jetzt, dass auch noch mal ein Beispiel gezeigt wird, wie ich eine AJAX-Anfrage

[34:18] jetzt mit jQuery mache. Und da sieht man jetzt,

[34:20] allein was den Code angeht, das ist natürlich deutlich weniger, als wenn ich das alles nativ in JavaScript drunter programmiere. Das heißt, jQuery nimmt mir

[34:27] da schon echt richtig viel ab.

[34:29] Und das ist trotzdem, wenn man sich ein bisschen mit der Syntax

[34:33] vertraut gemacht hat, besser zu verstehen, als wenn ich das alles selber

[34:36] programmiere. Von daher jQuery, absolute Leseempfehlung. Wenn du irgendwas mit Web machst, unbedingt angucken. Es gibt eigentlich keine

[34:42] Ausrede mehr, heutzutage zu sagen, ich programmiere es lieber selber mit JavaScript.

[34:46] jQuery nimmt uns da einfach die Arbeit ab. Und das ist einfach dumm, zu sagen, ich mache es selber.

[34:50] Außer wenn ich wirklich irgendwie weiß, dass meine Plattform nur dieser eine einzige Browser ist und ich genau dagegen korrekt entwickeln kann, gibt es

[34:56] eigentlich keine… Ja, mir würde nichts anderes einfallen, warum ich auf jQuery verzichten müsste. Außer vielleicht, dass es eine ziemlich große Bibliothek

[35:03] natürlich ist. Es sind natürlich ein paar Kilobyte, die da zusammenkommen bei der jQuery-Datei.

[35:09] Das kann ich natürlich deutlich reduzieren, wenn ich die paar Funktionen, die ich brauche, selber baue.

[35:13] Aber sobald ich irgendwie ein paar nette Effekte in die Website haben will, was weiß ich, einen kleinen Fade-In oder so was,

[35:19] oder einfach so Standard-Funktionalität, die müsste ich mir halt einfach nachprogrammieren. Und die ist in jQuery schon mit drin.

[35:24] Von daher, ich würde auf jeden Fall dazu raten, wenn du was mit Web-Entwicklung machst, schau dir jQuery an.

[35:30] Wahrscheinlich hast du sowieso schon gelernt, weil es einfach eh der Standard ist. Brauche ich wahrscheinlich gar nicht mehr viel zu erzählen.

[35:35] Okay, dann gucke ich mal auf die Uhr. Ich bin schon über der 30 wieder. 35 Minuten inzwischen für diese Episode. Aber so

[35:43] angepeilt hatte ich das ja auch immer, so eine halbe Stunde lang. Und dafür haben wir das Kapitel JavaScript jetzt aber

[35:47] abgehakt. Und ich bin alles losgeworden, was ich wichtig fand. Nochmal kurz zusammengefasst.

[35:53] JavaScript ist eine absolut wichtige Sprache. Ist eigentlich die einzige Sprache, die du im Browser-Frontend heute benutzen kannst. Für die Prüfungen sind

[36:01] Programmiersprachen Details aber irrelevant. Ich würde mich aber trotzdem unbedingt mit JavaScript auseinandersetzen. Einfach, weil ich erwarten würde, dass jeder

[36:07] Anwendungsentwickler heutzutage mal was mit Web gemacht hat. Auch wenn du es in deinem Day-Job quasi nicht brauchst. Aber es ist einfach so eine

[36:15] zentrale Plattform.

[36:16] Das Web, ja, das begegnet uns überall.

[36:20] Egal, ob du darin entwickelst oder nicht. Du selbst benutzt wahrscheinlich jeden Tag mehrere Web-Anwendungen in irgendeiner Form. Und deswegen sollte man sich gerade als

[36:26] Anwendungsentwickler irgendwie mal damit auseinandergesetzt haben. Und AJAX als konkrete Technologie ist auch sehr, sehr wichtig, weil es halt

[36:33] ein Architekturkonzept ist es nicht. Das ist nicht richtig. Aber es ist halt eine grundlegende andere

[36:39] Herangehensweise an die Web-Programmierung, wie es halt früher war. Und gerade bei solchen Technologie-Wechseln

[36:45] bieten sich natürlich die Fragen fürs Fachgespräch an. Warum haben sie es so gemacht? Warum nicht anders? Was sind die Vor- und Nachteile?

[36:52] Erklären sie doch mal, wie das funktioniert. Was heißt denn das? Und so weiter. Also von daher unbedingt

[36:56] anschauen und auch vernünftig lernen. Gerade für die Prüfung, aber auch für die Praxis. Natürlich hochgradig relevant das ganze Zeug hier.

[37:04] Okay, damit wäre ich jetzt durch mit dieser Episode.

[37:08] Ich würde sagen, mit dem Buchclub machen wir dann in zwei Wochen weiter. Nächste Woche mache ich mal ein ganz anderes Thema.

[37:13] Ich weiß noch nicht genau, was. Aber das wirst du dann am nächsten Montag hören. Würde mich freuen, wenn du wieder reinhörst.

[37:19] Bis dahin, falls du in die Shownotes reinschauen willst, da habe ich noch mal ein paar Links verlinkt. Nein, ein paar Webseiten verlinkt, wo

[37:26] was zu JavaScript erklärt wird und auch noch mal zur Typisierung. Das ist ja durchaus was, was man auf jeden Fall beherrschen können muss als

[37:34] Anwendungsentwickler. Und auch noch zwei Literatur-Empfehlungen. Selbstverständlich wie immer das Handbuch für Fachinformatiker. Ich glaube, ich brauche es nicht nochmal erwähnen. Darum geht es ja hier.

[37:40] Aber natürlich auch die JavaScript-Bibel von Douglas Crockford.

[37:45] JavaScript, the Good Parts. Das ist eigentlich so das zentrale Buch, was man unbedingt gelesen haben muss, wenn man irgendwas mit JavaScript macht.

[37:51] Zumindest wird mir das immer gesagt, beziehungsweise ich lese das auch ganz häufig, dass das so ein bisschen so die Referenzliteratur ist, wenn man

[37:58] vernünftig mit JavaScript entwickeln will. Denn mit JavaScript kann man ziemlich viel komischen Kram bauen.

[38:04] Gerade was diese ganzen Funktionen, die Funktionen aufrufen, die Funktionen zurückgeben und hin und her. Und diese ganzen Callback-Funktionen.

[38:11] Da gibt es ja sogar das geflügelte Wort

[38:14] Callback-Hell. Genau wie es bei Java sowas wie die Jahölle gibt, diese ganzen Abhängigkeiten, gibt es dann bei JavaScript quasi die Callback-Hölle,

[38:21] wo die Funktion eine andere Funktion wieder aufruft, die wieder eine andere zurückliefert und hin und her. Und das wird sehr schnell sehr

[38:26] unübersichtlich. Und es gibt aber auch die Möglichkeit, mit JavaScript vernünftig zu programmieren.

[38:31] Und viele gute Tipps dafür stehen in JavaScript The Good Parts. Also, falls du irgendwas mit Webentwicklung machst, kann ich absolut empfehlen,

[38:37] dir das Buch mal anzuschauen. Vom Erfinder von JSON übrigens. Ja, also Douglas Crockford hat dieses JSON-Format

[38:45] quasi berühmt gemacht. Von daher, der hat ein bisschen Ahnung von JavaScript tatsächlich.

[38:51] Ja, wenn du schon dabei bist in den Show Notes, ich habe ja gar nicht gesagt, wo du die findest, natürlich unter

[38:55] anwendungsentwicklerpodcast.de

[38:57] Slash 7 0 für die 70. Episode heute. Und im Blog habe ich letzte Woche noch was Interessantes veröffentlicht. Da kannst du ja gleich mal reinschauen bei der Gelegenheit.

[39:04] Und zwar habe ich die Frage beantwortet, ob es denn sinnvoll wäre, als Abschlussprojekt, als Anwendungsentwickler, ein

[39:11] Pflichtenheft zu schreiben. Oder ob man nicht doch besser was

[39:13] Richtiges programmieren sollte. Ich habe dazu mal ein bisschen was aufgeschrieben und ein paar Tipps zusammengestellt.

[39:19] Von meiner Seite aus ist das kein Problem. Du kannst auf jeden Fall ein Pflichtenheft als Projekt machen,

[39:23] solltest nur auf bestimmte Sachen achten. Zum Beispiel

[39:26] möglichst viele Artefakte unterbringen, weil du einige Sachen, die du bei einem

[39:31] richtigen Programmierprojekt nicht hast, eben, sage ich mal, so ein bisschen kompensieren musst in der Doku. Und dazu habe ich ein bisschen was aufgeschrieben.

[39:39] Netten Link der Woche hatte ich letztes Mal auch. Und zwar eine

[39:42] War Story, kann man das so sagen? Also so ein bisschen die Geschichte eines Entwicklers, der auch bei vielen Einstellungsprozessen

[39:49] in bekannten Firmen dabei war. Und er hat mir aufgeschrieben, wie sich das so ein bisschen bei ihm

[39:53] entwickelt hat. Wie er ganz am Anfang Leute eingestellt hat und wie er es inzwischen macht. Und aktuell ist er dabei gelandet, dass den Entwicklern vor den

[40:01] Vorstellungsterminen tatsächlich eine Aufgabe gestellt wird, die sie dann zu Hause in Ruhe runter programmieren können, um dann quasi ein Beispiel ihrer Arbeit

[40:10] abzuliefern, sodass man sie also auch ein bisschen besser einschätzen kann. Und das fand ich eigentlich sehr, sehr interessant und sehr spannend. Und er hat auch so

[40:16] verschiedene Evolutionsstufen

[40:17] beschrieben. Und ich sehe das bei uns im Unternehmen sogar auch so ein bisschen ähnlich, dass wir auf einem ähnlichen Entwicklungspfad sind. Von daher fand ich den

[40:24] Artikel absolut lesenswert. Kannst ja mal reinschauen, ist ja auch für dich interessant. So, damit mache ich jetzt Schluss für heute. Ich sage vielen, vielen Dank

[40:31] fürs Zuhören und bis zum nächsten Mal. Tschüss!