 Sollen wir dann einfach anfangen? Also wir sind in Stadka. Jetzt bin ich ein bisschen unsicher, denn die English Speakers... Da macht es wahrscheinlich mehr Sinn, wenn ich das auf Deutsch halte. Dann versteht ihr mehr. Ich frage euch beiden nochmal. Are you English Speakers? Okay. So auch. Ja. Only English. Okay, gut. Dann fangen wir an. Ich möchte euch ein bisschen was erzählen über JavaScript Frontends. Also sozusagen als Ersatz für ein Theme. Wie kann ich mit JavaScript WordPress nutzen und da eine Webseite draus bauen oder vielleicht auch andere Webprodukte Anwendungen. Genau, also kurz zu mir. Ich bin Thomas und habe hier in Osnabrück Medien- und Interaction Design studiert. Im Moment arbeite ich bei einem kleinen Webstudio namens Knoe in Orhus, Danemark. Und ich bin auch nebenbei ein bisschen Web-Developer für so ein paar Freizeitprojekte und kleinere Kunden. Und ich habe vor einiger Zeit mal beim WordPress Meetup in Osnabrück so einen kleinen Tor gehalten, darüber wie man Themes am besten erstellt oder wie man da mit anfängt. Und ich habe so ein bisschen dann die Analogie gesucht zum Kochrezept, dass man irgendwie Zutaten braucht für so ein Theme. Und zwar sind die meistens irgendwie HTML, CSS und PHP. Das dürfte ich wahrscheinlich bekannt sein. Und wenn man sich jetzt mal anguckt, wie das dann verbessert werden kann, dafür würde man dann JavaScript verwenden. Wie Wikipedia auch sagt, JavaScript is one of the core technologies of the World Wide Web. JavaScript enables interactive web pages and is an essential part of web applications. Ist vielleicht sogar schon ein bisschen übertrieben, aber ich glaube auch, dass man mit allein den Zutaten HTML, CSS, PHP sehr weit kommt. Aber sozusagen der Nachtisch, also das Eis hinterher, das ist vielleicht dann das JavaScript. Und jetzt kann man natürlich auch sagen, und darüber wollen wir eigentlich heute sprechen, wieso machen wir nicht einfach ein einfacheres Rezept, wo nur JavaScript vorkommt. Das ist vielleicht eine mutige Idee, aber kann man ja mal versuchen. Und ich würde ganz gerne euch so ein bisschen beeinbinden. Also ich würde das gerne mal versuchen, so eine kleine Umfrage zu starten. Mal gucken, ob das technisch funktioniert, damit ich das so ein bisschen einschätzen kann. Ich habe jetzt so eine Umfrage vorbereitet. Wenn ihr auf eurem Telefon das Aufruf, dann müsstet ihr eigentlich abstimmen können. Und da können wir so ein bisschen sehen, kann ich so ein bisschen sehen, wie euer Kenntnisstand ist. Und vielleicht können wir am Ende dann auch nochmal überprüfen, ob sich das verändert hat. Also meine erste Frage ist, ob ihr überhaupt JavaScript kennt und das gegebenenfalls schon mal benutzt habt. Wir sehen jetzt ja schon das Live-Ergebnis sozusagen und sieht ja eigentlich ganz gut aus. Also jedenfalls alle kennen JavaScript und die meisten haben es auch schon mal benutzt. Ja, da gehe ich ja auch stark voraus. Dann würde ich euch gerne noch eine zweite Frage stellen und zwar, ob ihr React kennt. Was ist ein JavaScript-Framework? Also Entwickler, ja. Danke für die Frage. Genau, guter Hinweis. Ich wollte ja nur so einen groben Überblick bekommen. Das ist ja schon mal ganz interessant. Ich meine, dann habt ihr ja auch so ein kleines Bild, wie ist der Kenntnisstand. Und ich glaube, das passt vielleicht auch sogar ganz gut mit der WordPress-Community, wie das so aufgeteilt ist. Viele haben das irgendwie schon gehört, aber noch nie benutzt. Und ich will so ein bisschen dafür Werbung machen, das zu benutzen, aber gleichzeitig auch versuchen zu erklären, wo die Faltstrecke sind und worauf man achten sollte und wenn es vielleicht auch einfach keinen Sinn macht, ja, nur auf JavaScript zu setzen. Genau, und ich weiß nicht, ob ich euer Geduld jetzt hier überstrapaziere, aber ich hätte noch eine Frage für euch. Ja, das ist wahr. Ich probiere das auch zum ersten Mal tatsächlich jetzt aus. Deswegen, ja. Und ich würde gerne von euch noch wissen und das würde ich euch, die gleiche Frage, würde ich euch am Ende gerne noch mal stellen, ob ihr Lust hättet, also eine Webseite mit WordPress als Backends sozusagen und JavaScript als Motor, der das Frontends zu erstellen. Ich sehe schon eine große Motivation bisher. Aber ich will auch nicht das Ergebnis beeinflussen. Sieht gut aus. Kann ich ja ein paar Leute überzeugen, dass sie dann am Ende nach oben kommen, auch in die linke Ecke. Genau, ich gehe mal wieder zurück zur Präsentation. Das waren jetzt alle Umfragen. Genau, am Ende stelle ich euch noch eine Frage. Genau, die kommt dann zum Schluss. Also gerne den Tap offen lassen, wenn das geht. Ja, aber schön, dass euch das erzählt. Das wusste ich gar nicht. Wenn ihr das Slight angelegt habt, dann steht das da. Okay, super. Ja, ihr seid ein bisschen Testkaninchen jetzt. Jetzt weiß ich auch, wie es funktioniert. Genau. Also es gibt ja so ein paar Unterschiede, wenn man jetzt Webseiten mit nur JavaScript baut oder wenn man Webseiten auf PHP basiert. Und zwar ist der größte Unterschied sozusagen, dass es ein Bewusstsein sollte, dass in der realen Welt PHP es nur in der Lage dazu auf dem Server irgendwas zu erstellen. Also es baut ja dann aus dem Code, den ihr geschrieben habt und dem HTML, das ihr geschrieben habt, nachher die Webseite zusammen, die dann an dem Browser ausgeliefert wird. Und das kann man landläufig Server-Site-Rendering nennen, weil dieser Zusammenbau eben auf dem Server stattfindet. Und jetzt ist häufig das Problem, dass wenn man JavaScript-Anwendungen baut, auf genau das Gegenteil gesetzt wird, nämlich Klein-Site-Rendering. Das heißt, dieses Zusammenbau in der Webseite, das findet dann im Browser statt. Und wie man hier sieht, so ganz klein in der Ecke, ist dann häufig für Entwickler in dieser Punkt Server-Site-Rendering auch bei JavaScript. Aber das ist mehr so, ja, wenn dann noch eine Stunde Zeit ist, dann guckt man sich das nochmal an und aber dann ist es auch nicht so trivial und deswegen lässt man es dann vielleicht einfach sein. Und das ist vielleicht ein Problem, weil ich weiß nicht, ob ihr diese Analogie vielleicht kennt, aber links sehen wir halt einen Aufzug und rechts sehen wir Rolltreppen und das beschreibt ganz gut so dieses fundamentale Problem mit JavaScript im Web, denn das Web ist ja eigentlich basierend auf HTML, also strukturierten Inhalten und CSS und die sind ziemlich solide. Die lassen sich nicht so leicht beirren, also wenn der Browser irgendwas im HTML nicht versteht, dann sieht man trotzdem den Text. Wenn der Browser irgendwas im JavaScript nicht versteht, dann sieht man gar nichts. Und vielleicht wird jetzt schon klar, wo diese Analogie hingeht. Wenn ich den Lift benutzen möchte, aber der Strom ausfällt, das geht nicht. Genau, wenn ich aber hier so eine Rolltreppe habe, dann kann ich die einfach als Treppe benutzen. Die hat nämlich einen eingebauten Fallback und so was, das wollen wir eigentlich auch im Web haben. Das Seiten für alle Leute herreichbar sind, selbst wenn sie das auf einem Urengerät aufrufen oder selbst wenn sie eine schlechte Verbindung haben. Und ich höre oft dann so was wie, ja, aber es hat ja kaum jemand JavaScript deaktiviert. Also das funktioniert ja fast immer. Und das stimmt wahrscheinlich. Also die Leute, die bewusst JavaScript ausschalten, das ist wahrscheinlich nicht so die große Menge. Ich habe jetzt keine Zahlen. Aber der Punkt ist, dass es halt auch ganz viele andere Gründe gibt, warum JavaScripts nicht funktioniert manchmal. Und das kann einfach sein, dass das Netzwerk nicht so gut funktioniert. Und so JavaScript Dateien sind möglicherweise groß. Die muss ich erst mal runterladen. Weil so Konferenzen hat man ja häufig mal, dass das W-Lan streikt. Und dann kann ich eventuell gar nicht sehen. Während ich, wenn ich HTML ausliefern würde, zumindest schon mal den Text vielleicht sehen könnte. Es kann auch sein, dass ich meinen Fehler mache, meinem JavaScript. Selbst wenn man Testing hat und so weiter, kann das tatsächlich passieren. Habe ich schon selbst erlebt, dass JavaScript irgendwelche Fehler hat und das eben nicht funktioniert dann. Es kann aber auch sein, dass meine Nutzer Geräte benutzen, die nicht, also die älter als zwei Jahre sind, oder die sogar noch älter sind, die einfach wenig Speicher haben. Und ich belaste diese Geräte und natürlich auch die Batterien dieser Nutzer damit, dass sie ganz viel Arbeit machen müssen, weil das JavaScript ja eben Browser läuft. Und es kann auch einfach sein, dass ich die Webseite auf irgendwie einem eingebauten Touchscreen im Kühlschrank aufrufe und da einfach der Browser, der das gar nicht unterstützt. Es gibt also, wie man sieht, recht viele Gründe, warum man sich vielleicht nicht darauf verlassen sollte, dass JavaScript funktioniert und warum man vielleicht stattdessen eben diese Rolltreppe bevorzugen sollte. Also ich brauche irgendwie mehrere Schichten und dafür gibt es eigentlich schon seit längerer Zeit eine Lösung wie es eben auch mit JavaScript Server-Site-Rendring zu betreiben. Klingt komisch, aber man kann ja JavaScript auch auf dem Server ausführen, also namens Node.js, das ist eben das Programm, das dann auf dem Rechner läuft, der die Webseite ausliefert. Und der Vorteil ist, dass ich da auf beiden Seiten quasi die gleiche Sprache gesprochen wird, nämlich JavaScript, den Code nur einmal schreiben muss, wenn alles gut läuft. Und ich hatte hier noch so ein paar Beispiele, aber ich glaube, die brauchst jetzt gar nicht, weil ihr das schon gut verstanden habt, warum das vielleicht nicht so gut funktioniert mit dem JavaScript und das geht so ein bisschen in das Gutenberg, Bashing noch mal rein, aber ich finde das einfach wichtig, weil ich das gerade neu gelernt habe. Ich fand das so sympathisch. Und er hat gesagt, ja, man muss neue Sachen lernen und ich finde das auch total wichtig. Aber ich habe gedacht, Moment, das WordPress-Backend, das war eigentlich immer dafür bekannt, dass es sehr robust ist, dass es auch funktioniert, wenn man nicht so eine gute Verbindung hat. Und ich finde das so sympathisch. Es funktioniert, wenn man nicht so eine gute Verbindung hat, dass es auch funktioniert, wenn das Skript eben kaputt ist. Und auf der rechten Seite sehen wir halt, was bei Gutenberg passiert, wenn man den mal im ECE-W-Laden lädt. Da sieht man nämlich erstmal eine weiße Seite, weil da erstmal das Skript laden muss. Und das ist vielleicht schwierig, wenn ich nicht so eine gute Internetverbindung habe, aber meine WordPress-Seite verändern möchte. Und so dieses Problem wurde jetzt in Gutenberg behoben. Das ist der Fix. Man kriegt jetzt eine Fehlabmeldung. Viele andere Seiten machen das auch so. Die haben irgendwie auch nicht so Lust darauf. Aber ich bin trotzdem der festen Überzeugung, dass das eine gute Idee ist, weil man damit einfach mehr Leute erreicht. Und es gibt dafür ja auch eine Lösung, die ich noch nicht habe und das ist in der Regel eine Kombination aus Progressive Enhancement, was so in diese Rolltreppen-Analogie geht. Also ich habe das HTML und CSS, was vom Server ausgeliefert wird. Ich kriege eine Basisvariante dieser Seite und ich kann meine Inhalte lesen. Und alles, was dann als spannender Nutzerinteraktion noch hinzukommt, ist ein Enhancement, was ich dann mit JavaScript umsetze. Und was die Erwartungen betrifft, daran jetzt hinzugehen und zu sagen, okay, das hört sich so cool an, JavaScript, und ist es auch. Ich möchte das mal ausprobieren. Dann möchte ich trotzdem hinzufügen, dass, wenn man eben eine richtige Webseite für einen Produktivbetrieb in JavaScript erstellen möchte, das ist ganz schön viel Arbeit. Und es ist auch nicht schlimm, weiterhin PHP Teams zu schreiben. Das ist total okay, das funktioniert richtig gut. Und da kann man richtig solide Webseiten mitbauen. Aber, und das ist der spannende Punkt, es kann auch richtig schnelle Erfolge geben, wenn ich halt mal anfange und einfach schnell was aufsetze mit JavaScript und WordPress benutze, um ja, vielleicht einmal reinzuschnuppern und in meiner altgewohnten Umgebung die Inhalte zu bearbeiten, aber gleichzeitig im Frontend eine neue Technologie auszuprobieren und vielleicht ja, damit mal so ein bisschen zu spielen. Es muss ja nicht gleich eine solide Produktivseite dabei rauskommen. Und so ein paar Use Cases, die ich gesammelt habe oder wo ich glaube, das wirklich machen kann, also hingehen und sagen, ich mache einen Frontend, das nur aus JavaScript besteht. Das fand ich bei einer einfachen OnePage Webseite, da habe ich das ausprobiert. Das hat ziemlich gut funktioniert. Oder zum Beispiel bei einer UI für einen öffentlichen Informationsscreen. Das macht total Sinn, Inhalte in WordPress zu bearbeiten und sie dann über die REST-API einen Screen darzustellen und dann eben das Frontend in JavaScript zu entwickeln. Da muss ich dann auch nicht auf verschiedene Browser achten oder so was, weil das läuft ja dann startisch da in diesem System. Oder ich kann vielleicht auch und das war ja auch ein Punkt von Matt, dann damals, ich kann ja auch eine ganz andere UI machen für WordPress, auch für das Backend zum Beispiel. Das ist jetzt kein Frontend-Example, aber gut. Und das ist eigentlich auch schon alles, was ich bisher so an Erfahrung gemacht habe, was gute Use Cases sind für JavaScript in Verbindung mit WordPress. Weil auch wenn das in aller Munde ist und ViewJS und React, heißt das nicht unbedingt, dass ich das machen muss. Man muss immer gucken, das ist das richtige Tool für mein Ziel. Und wofür fühle ich mich auch wohl? Also das ist ja auch ein wichtiger Punkt. Und hier ist jetzt nicht so ein super gutes Foto, aber so sieht zum Beispiel ein Public UI-Screen aus, den ich mal schnell gebaut habe für die Kirchengemeinde in meinem Heimatort, die eine WordPress-Webseite haben und das zieht sich einfach die Informationen von der REST-API und das kann man sehr schnell aufsetzen, so was. Und damit ihr so ein bisschen mit vielleicht ein, zwei Stichpunkten rausgehen könnt, um das selber anzufangen, habe ich gedacht, machen wir so eine kurze Hands-on-Session. Wenn ihr ein Laptop habt, könnt ihr vielleicht versuchen mitzumachen, aber wahrscheinlich wird das eher schwierig, weil man dafür schon mal Node.js installiert haben sollte. Deswegen, ich zeige es mal und dann könnt ihr vielleicht im Bruch nochmal gucken, wie könnt ihr es zu Hause nochmal nach oder ausprobieren und könnt ihr euch vielleicht das Video nochmal angucken. Aber ich würde gerne sozusagen den Punkt machen, dass es gar nicht so schwer sein muss, damit anzufangen und einfach auf die API von WordPress zuzugreifen und eine Seite zu machen. Und dafür habe ich mir überlegt, wie finden wir überhaupt die REST-API? Also, wie kriege ich denn raus, wo überhaupt die Inhalte jetzt zugänglich sind von meiner Seite? Dann würde ich gern ein Beispielprojekt mit Next.js, das auf React basiert, aufsetzen. Und dann benutzen wir einfach die Inhalte von der REST-API. Und wir können uns ja zum Beispiel als Beispiel mal die WordCamp-Seite von unserem WordCamp angucken. Und da schaue ich dann einfach in den Quelltext. Und irgendwo hier im Hat-Bereich gibt es dann häufig eine Referenz auf die REST-API. Und zwar... Ich suche einfach mal danach, weil ich ja ungefähr weiß, wie die heißt. Genau, hier finde ich sie. Und wenn ich es da draufklicken, dann kann ich mir eben Inhalte von dieser Seite sofern das nicht blockiert ist, ihr könnt das mit Hilfe eines Plugins blockieren, in JSON sehen und die dann verarbeiten. Und wenn ich zum Beispiel die Posts sehen möchte, dann ist es diese URL und dann kriege ich eine Liste mit den zehn letzten Posts und kann das dann natürlich über die URL-Parameter hier oben ein bisschen anpassen. Es gibt ja auch eine sehr gute Dokumentation von WordPress dazu, wie diese API zu benutzen ist. Ich glaube, es hat developer.wordpress.org. Und diese URL, die wird jetzt gleich wichtig sein, wenn wir halt unser JavaScript dann schreiben. Und ich weiß, dass eine große Hürde immer ist. Wie fange ich überhaupt an? Ich habe so viele Abhängigkeiten, die ich irgendwie installieren muss. Und was ganz spannend ist, ist, dass es inzwischen so ganz gute Pakete gibt, die man einfach installieren kann und wo dann einfach alles schon mit einer Best Practice-Konfiguration drin ist und man einfach mal anfangen kann, mal was ausprobieren kann und dann vielleicht Stück für Stück verstehen kann, wie das auch funktioniert und es dann vielleicht irgendwann mal selbst aufsetzen kann. Aber das auch gar nicht unbedingt muss, weil man so eigentlich schon zum Ziel kommt und schon so ein Erfolgserlebnis hat. Und nicht erschrecken, das passiert dann teilweise im Terminal. Ich weiß nicht, ob wir das lesen können. Ja. Und zwar würde ich jetzt eigentlich jemals in meinen sitesordner, wo ich so Projekte sammle und dann gibt es, wenn ich jetzt Node.js installiert habe und NPM installiert habe, dann kann ich mithilfe des Kommandos NPX mir ein Beispiel installieren und das heißt Create Next App. Next.js, das ist das Framework, was wir verwenden werden. Ich mache mal eine Suche. Dafür habe ich jetzt leider kein Slides vorbereitet, weil das ein bisschen spontan ist. Aber ihr versteht es vielleicht trotzdem. Also Next.js ist ein Framework, ein JavaScript Framework, was auf React aufsetzt. Das heißt, es ist quasi noch mal eine Lage oben drauf und es vereinfacht gewisse Sachen unter anderem server-side rendering. Wenn ich also meine Webseite so machen möchte, dass sie auch funktioniert, wenn das JavaScript nicht funktioniert, dann kommt man ganz gut in die Gänge, wenn man Next.js verwendet. Dann kann man ihn sehr gut starten. Und dieses Kommando, das wird jetzt, ich suche mir jetzt noch einen Ordnernamen aus, ich sage jetzt einfach mal WordPress, Rest API und dann sorgt jetzt dieses Kommando dafür, dass alle Abhängigkeiten installiert werden und dass schon so eine Basiskonfiguration des Projekts einfach da ist. Und man kann sich auch verschiedene andere Beispiele installieren, die vielleicht schon so gewisse andere Module beinhalten, die man noch braucht, wenn man zum Beispiel ganz absurd CSS in JavaScript schreiben möchte. Das geht auch. Oder wenn man mit TypeScript arbeiten möchte, wenn man die Variante von JavaScript ist, die von Microsoft entwickelt wird, also Typen kennt, so wie man das vielleicht aus anderen Programmiersprachen kennt, dann gibt es dafür auch solche Beispiele, die man einfach installieren kann. Jetzt wechsel ich in den Ordner und hier steht jetzt so eine kleine Anleitung, was ich halt machen kann und das, was wir jetzt machen wollen, die Entwicklung starten. Da gebe ich einfach dieses Kommando hier mal blind ein, was da steht. Und dann gucken wir mal, was passiert. Und jetzt sehen wir, dass der Server gestartet wurde. Das versuche ich, den mal aufzurufen. Und jetzt sehe ich hier meine Beispielseite, die quasi schon fertig ist. Und jetzt wollen wir uns natürlich den Code auch mal angucken. Öffne ich ein Editor. Moment zum Mikrofon. Was du jetzt eingibst, machst du ja mit einer gewissen Selbstverständlichkeit. Ich nehme an, dass dir das nicht in die Wiege gelegt worden ist. Das ist auch dokumentiert tatsächlich. An was hast du dich da orientiert? Das ist ja so ein bisschen auch dann der Austausch wahrscheinlich mit anderen Entwicklern. So erfährt man ja auch was anderen nutzen. Aber es gibt natürlich auch so etwas wie eben Dokumentationsseiten oder Newsletter, die einem helfen zu filtern, was ist wirklich interessant und was nicht. Worauf du vielleicht hinaus willst, es gibt unglaublich viele Möglichkeiten und es ist wirklich schwierig zu filtern, was könnte interessant sein. Da habe ich jetzt leider keine Patentlösung, wie man damit umgeht. Aber man findet so nach einer Zeit so ein bisschen raus, was könnte vielleicht für mich interessant sein, was erfüllt meine Anforderungen und dann versucht man so ein bisschen durch die Buzzword-Werbung der einzelnen Frameworks und Libraries durchzuschauen was können die eigentlich wirklich und wie kann mir das helfen? Beantwortet das die Frage? Das war bisher jetzt auch eigentlich alles, was wir im Terminal machen müssen, denn im Hintergrund läuft jetzt unser Server und immer wenn wir hier irgendwelche Dateien in dem Verzeichnis jetzt ändern, was dieses CreateNextApp-Kommando für uns stellt hat, dann wird automatisch der Server neu gestartet und die Änderungen verarbeitet, sodass ich mich darum gar nicht kümmern muss. Und Next.js funktioniert so, dass wir ein Ordner haben, der heißt Pages und so funktioniert eben auch das Routing oder wie ich festlege, was findet man auf welcher Seite. Und hier gibt es jetzt eben nur diese Indexseite, das ist quasi diese, die wir jetzt hier sehen. Und jetzt wollen wir mal nur eine zweite Seite anlegen. Die nenne ich jetzt einfach WordCamp und das wird dann auch eben der Name der Seite sein. Und hier steht jetzt schon eine ganze Menge drin, das kann jetzt auch relativ erschlagend wirken, wenn man das zum ersten Mal sieht. Das ist der Beispiel-Inhalt, den wir hier sehen. Man muss das nicht unbedingt so machen, wie die das gemacht haben. Es gibt ganz viele verschiedene Wege, wie man JavaScript schreiben kann. Und ich möchte einen zeigen, der euch vielleicht ein bisschen bekannter vorkommt, wo nicht so fat arrow Functions und so was dran vorkommt. Also als erstes, ich kopiere das einfach mal von hier, muss ich React importieren, weil das eben die Library ist, auf der alles aufbaut. Und dann kann ich eine Klasse erstellen. Und die Syntax ist fast wie bei anderen Programmiersprachen auch. Ich sage einfach Class. Und dann sage ich WordCamp, Page. Und dann sage ich Extens, React, Komponent. Und so erstelle ich mir eben eine Klasse, die aufbaut auf einer leeren React Komponente sozusagen. Und dann gibt es in jeder React Komponente diese Funktion, die heißt Render. Und die macht eben das, die gibt dann zurück, was soll jetzt in dieser Komponente angezeigt werden. Und hier würde ich jetzt einfach mal eine H1 zurückgeben mit Hello World. Das, was wir hier jetzt sehen, ist nicht wirklich HTML. Es ist JSX. Das ist also HTML-ähnliches, ein HTML-ähnliches Konstrukt in JavaScript, was auf den ersten Blick ein bisschen Angst machen kann, vielleicht, wenn man sich denkt, was ist das? Genau, im Endeffekt kommt man dann auch immer wieder auf, hat der ML zurück. Aber ich kann eben auch Custom Komponenten machen. Also zum Beispiel hier in dieser Index-Datei haben wir hier so eine NAV-Komponente. Das ist ja jetzt kein HTML-Tag. Und das ist eben eine Navigation, die jetzt schon in diesem Beispiel-Inhalt drin war. Wir sehen hier ist dieser Home-Button. Und das ist eben auch, wenn ich jetzt hier auf NAV draufklick, um da mal hinzugehen, wo das definiert ist, dann sehe ich, dass hier auch dieser Home-Link drin ist. Und wir können jetzt natürlich auch hingehen und diese NAV auch in unserer WordCamp-Seite verwenden. Wir können jetzt hier diese NAV-Komponente auch einbauen. Und jetzt ist es so, hier sieht man dann schon den Unterschied zu HTML. Bei JSX ist es so, ich sehe jetzt hier so eine Unterschlängelung. Ich muss immer meine Komponenten in eine Eltern-Komponente einpacken sozusagen. Also ich muss immer was drumherum haben. Und schönerweise gibt es jetzt dieses React-Fragment. Das ist dann quasi so eine Art Pseudokomponente, die dann einfach entfernt wird. Wenn man später sich das HTML anguckt, sieht man nur der Inhalt, der eben in dieser Navigationskomponente drin ist, und meine H1. Was man früher machen musste, ist, dass man immer so ein Diff da drum hat. Und da hat man ganz viel überflüssiges Markup. Das will man nicht so gerne. Und jetzt gucken wir uns das mal an, ob das funktioniert. Beziehungsweise hier sehen wir jetzt, dass es so grau hinterlegt. Das sagt mir jetzt, WordCamp-Pages declared but never used. Ich muss das nämlich noch exportieren. Und wenn jetzt alles richtig läuft, dann hat Next.js das schon registriert im Hintergrund. Und ich kann einfach jetzt diese WordCamp-Seite aufrufen. Und dann haben wir direkt mal einen Fehler. Gucken wir mal, was das Problem ist. Nerv is not defined. Genau, das ist ein guter Punkt. Ich habe das nämlich nicht importiert. Aber da kann mir mein Editor helfen. Genau, jetzt habe ich auch den Import dafür ergänzt. Und jetzt sehen wir, dass hier diese Hello World zu sehen ist. Und wenn ich mir den Seitenquelltext angucke, dann ist er komprimiert leider. Aber wenn man ganz genau hinguckt, dann sieht man, dass hier eben jetzt auch unsere H1s drin ist. Und daran merken wir jetzt auch, dass diese Seite eben sogar Server ist. Also auf dem Server gerendet ist. Das heißt, in dem HTML, was ausgeliefert wird, sehe ich schon meine H1s. Und jetzt habe ich noch 10 Minuten. Das heißt, ich muss mich vielleicht ein bisschen beeilen, falls ich noch eure Fragen beantworten möchte. Wir wollen ja noch dazu kommen, von der WordPress-Rest-API das jetzt zu laden. Und dafür gibt es jetzt zwei Funktionen, die wir ausfüllen müssen in dieser Komponente. Und zwar ist das einmal eine statische Funktion, die von Next.js vorgegeben wird. Und die heißt Get Initial Props. Das sagt euch jetzt wahrscheinlich wenig, weil ich nicht erklärt habe, wie React-Komponenten überhaupt funktionieren. Aber da, also grob gesagt, erreiche ich damit, dass ich auf dem Server Daten laden kann und verarbeiten kann. Und die dann später schon in meiner Komponente drin sind, wenn sie halt als HTML ausgeliefert wird. Und dann gibt es eben diese Methode, die heißt Component Did Mount. Das ist auch eine Standard React Methode, die in jeder Komponente vorhanden ist. Und die wird immer ausgeführt, wenn im Browser, jetzt kleinseitig, da schon die Komponente verarbeitet wurde und dann quasi in HTML übersetzt wurde. Das heißt, das sind quasi diese beiden Punkte, an denen wir Daten laden möchten. Also einmal auf dem Server, wenn unsere Seite angefordert wird vom Server, aber auch im Browser, wenn ich zum Beispiel von einer, von der Homepage auf diese Seite jetzt navigiere, dann muss sie ja nicht zwangsläufig vom Server neu geladen werden, sondern dann kann ich ja im Browser, kleinseitig sozusagen, einfach zu dieser Seite wechseln und dann da eben die Daten laden. Und ich aufgrund der Zeit implementiere ich jetzt mal hier nur diese GetInitialProps Methode. Und zwar brauchen wir jetzt eben unsere REST API URL. Wo habe ich sie? Hier. Denn jetzt holen wir uns davon einfach die Posts mal ab und zeigen die dann in der Liste einfach an. Also zeigen wir einfach die Titel an zum Beispiel. Und dafür benutze ich ein Modul, das heißt Fetch. Das kann einfach dann diese URL quasi abrufen und dann sage ich, dann gibt es auf diesem ResponseObjekt das Fetch uns gibt, gibt es dann eine Methode, die heißt JSON, dann kann ich nämlich diese rohe Antwort, die ich vom Server bekommen, auch direkt als JSON in JavaScript verwenden, als JavaScript Objekt verwenden. Und das sind Asynchroneprozesse, die da ablaufen. Das heißt, der Browser wird nicht blockiert, während das läuft. Und deswegen benutze ich dann hier ein await und mache das zu einer Asynchronemethode. Das sind Features, die gibt es nicht in dem JavaScript, das im Browser läuft. Dass wir sowas benutzen können, ist darauf zurückzuführen, dass eben diese App mit Next.js initialisiert wurde und diese ganzen Abhängigkeiten schon installiert wurden und dieses moderne JavaScript eben zu dem Browser JavaScript irritiert wird später. Ja, Mikrofon, Entschuldigung. Wir nutzen müssen doch auch in dem Fall, weil sonst läuft der Code hier einfach weiter. Ja, das stimmt so. Ja, also wenn ich die Asynchronität nicht ausnutze, dann blockiere ich den Browser, also dann kann ich nicht scrollen oder auf irgendein Button klicken auf der Webseite und das will man natürlich nicht, weil dann quasi alles in diesem einen Strang läuft. Aber es gibt auch andere Möglichkeiten, also die Asynchronität in JavaScript auszudrücken, nur das mit zwei Zeilen ist eigentlich relativ einfach und einigermaßen verständlich, würde ich mal behaupten. Und jetzt ist es so, dass ich von dieser Methode hier einfach was zurückgeben kann, zum Beispiel diese Posts, das gebe ich jetzt einfach in so einem Objekt zurück und dann kann ich das hier in meiner Render-Methode verwenden. Hier kann ich jetzt zum Beispiel eine Liste machen, eine UL, das kennen wir alle und dann benutze ich hier so eine Map-Funktion. Dann sage ich, das hat mein Editor jetzt ergänzt, das wollen wir nicht, this.props.posts. Wir machen hier getInitialProps und dann haben wir das später in diesem Klassenattribut drin und dann benutzen wir die Map-Funktion und gehen einfach drüber über alle Posts und dann haben wir immer einen Post, den wir in unserer Funktion dann ausgeben können. Und dann geben wir einfach hier das li-Element zurück mit dem Post-Titel und ich glaube, das heißt rendered, dann rendered. Wenn wir jetzt das hier mal angucken, genau, die Struktur von dieser Response ist halt, das ist ein Post, dann gibt es hier ein Title und da gibt es dann noch ein Attribut rendered. Warum das so aufgebaut ist, weiß ich nicht, da müsste man die Macher der WordPress Rest API mal fragen. Ja, danke. Wenn wir Glück haben, können wir jetzt schon was sehen. Okay, funktioniert nicht, genau, weil ich das Fetch-Modul nicht importiert habe. Das ist nicht standardmäßig in Node.js enthalten und da das Ganze ja hier auf dem Server ausgeführt wird, muss es halt in Node.js enthalten sein. Fetch gibt es nur im Browser, also in modernen Browsern ist das schon implementiert. Aber ich kann halt das auch einfach importieren und dann nehme ich mal dieses Modul, das muss ich dann allerdings kurz installieren. Ups, hier sehen wir die ganzen Fehlermeldungen. Ja, ja, ich merke das schon. Das ist natürlich auch fatal, weil wenn man das häufiger macht, dann kommt einem das alles sehr einfach vor. Aber natürlich ist das schwierig, wenn man einsteigt. Also gar keine Frage. Und da werden Fehlermeldungen kommen, wo man sich die Hände über dem Kopf zusammenschlägt. Ja, genau. Wobei man natürlich hier so ein bisschen dann schon daraus lesen kann und das merkt man dann irgendwann, das ist halt nicht definiert, also wie in jeder anderen Programmiersprache bekomme ich jetzt quasi und das ist eigentlich der große Vorteil, wenn man so ein Build-Tool hat, bekomme ich halt auch Fehlermeldungen. Also wenn ich nur JavaScript direkt im Browser schreibe, dann weiß ich manchmal gar nicht so genau, was ist jetzt eigentlich falsch. Auch was falsch ist. Jetzt wurde es installiert. Ich speichere das Ganze mal und jetzt sehen wir hier die Liste unserer Post-Titel. Also so einfach kann es eigentlich sein, Inhalte aus WordPress rauszuholen und die dann mit JavaScript auf einer Seite anzuzeigen. Und jetzt läuft mir die Zeit davon, aber was man natürlich beachten muss, ist jetzt habe ich immer noch keinen Head, der in WordPress ja standardmäßig drin ist. Also ich habe keinen vernünftigen Titel oben. Seeo Tags wählen mir auch. Ich habe auch noch keinen Caching. Ich muss mir irgendwie Gedanken machen über Routen. Ich habe keine Vorschau, wenn ich in WordPress auf Vorschau klicke. Also das meine ich mit, das ist viel Arbeit, wenn man ein richtig produktives JavaScript-Fronten haben möchte. Aber es macht auch Spaß und es gibt auch Tools, die das erleichtern, zum Beispiel ACF, also Advanced Custom Fields. Also dafür gibt es noch ein weiteres Plugin, was einem die Inhalte dann direkt in der REST API ausgibt. Und Yoast hat auch eine Möglichkeit, über die REST API ein paar Seeo-Informationen zu bekommen. Also das hilft schon ungemein. Jetzt kommen wir leider nicht zu der abschließenden Umfrage. Aber ja, weiß ich jetzt auch nicht, wie ich damit umgehen soll. Aber vielleicht, wenn wir die letzte Minute dafür nutzen, können wir das gerne nochmal machen. Ich würde nämlich das echt interessieren, wie das jetzt bei euch aussieht. Vielleicht weniger, vielleicht mehr. Ja, vielleicht können wir schon mal fragen, beantworten gerne. Okay. Hast du selber schon ein fertiges Seam fertig auf REST API Basis? Nein, also kein Seam in dem Sinne. Aber kannst du eins empfehlen, als ich habe gehört, es gibt mittlerweile welche, welche im Seam Verzeichnis, hast du da Erfahrung? Hab ich leider keine Erfahrung mit. Ich weiß nur, dass es tatsächlich welche gibt. Ja. Und immer mehr Themes verwenden auch REST API Funktionalitäten. Ja. Ich habe mir jemand eins ausprobiert, das empfehlen. Okay, danke. Tut mir leid. Vielleicht blöde Frage, aber was kriegt man denn aus der REST API raus? Also ich bin jetzt recht beeindruckt, dass man sozusagen einfach Informationen so leicht aus der REST API sich ziehen kann. Hätte ich nicht gedacht, also was für Informationen kann man sich ziehen? Ja, man kann sich auf, man kann fast alle Informationen daraus bekommen aus einer WordPress Installation, die ich eben, also das sind jetzt keine geheimen Sachen. Die sind alle schon auch da. Wenn du ein fully featured Theme hast, dann kannst du ja die OLs aufrufen wie Autorenarchive und Kategoriearchive und so weiter. Und diese Möglichkeiten hast du mit der REST API auch. Du kannst auch filtern. Genau. Du kannst dir auch abstellen. Was ich auch teilweise empfehle. Also wenn du es nicht benutzt, kannst du sie abstellen. Also mache ich gleich zwei Anmerkungen. Die erste ist nicht die REST API abschalten, sondern es gibt Plugins, die das enforzen, dass man autorisiert sein muss. Ja, ganz genau. Weil sonst brechen euch zum Beispiel auch Gutenberg oder auch Yoast mittlerweile, geht kaputt, wenn ihr die REST API abschaltet. Also es gibt Plugins, ich weiß die Namen jetzt nicht. Ich glaube es heißt Disable REST API tatsächlich. Der Name ist ein bisschen irreführend, aber es liegt nur Authentifizierung drauf. Okay, dann haben Sie das Verhalten geändert, weil als es rauskam, hat es wirklich abgeschaltet und allen Leuten sind die Seiten um die Ohren geflogen. Also nicht abschalten, sondern authentifizieren, dass man halt nur mit mindestens Autorenrechte oder sowas die REST API nutzen kann. Und das Nächste ist, du sprichst halt von Frontends und ich glaube, man muss ganz deutlich unterscheiden zwischen Webseiten und Webanwendungen. Von Frontend für einen Block in JavaScript zu bauen, halte ich für kompletten Umfug. Wenn ich aber eine Web-Anwendung baue, wie ein Gmail oder was auch immer, eine tatsächliche Anwendung, dafür ist es sicherlich eine interessante Geschichte. Da bin ich aber auch bereit dazu zu warten, bis die Anwendung geladen ist und so weiter und so fort. Wie zum Beispiel sind ein Start-up, was in Indonesien agiert. Wir haben sehr, sehr instabile Netzwerke. Wir haben sehr, sehr alte Geräte und so weiter und so fort. Wenn ich anfangen würde, da irgendwie Frontends in JavaScript zu bauen, wir würden keinen Umsatz mehr machen. Genau, das ist genau mein Punkt. Man muss da sehr genau unterscheiden zwischen deswegen so eine Frage nach so einem Theme für einen Block auf JavaScript-Basis halte ich für sehr, sehr gefährlich. Es gibt vielleicht nette Features, einzelne Widgets, einzelne Komponenten, die man interaktiv machen kann, wie eine interaktive Tech-Cloud, in der man vielleicht Kind-Elemente ausklappen kann oder sowas. Ja, was gibt arbeiten, aber eine ganze Webseite, gerade die eigentlich nur zum Konsum da ist, macht keinen Sinn, so was dazu machen. Also, wenn du zeitbasierte Geschichten hast, wie News-Updates oder so was, dann macht es vielleicht Sinn, aber auch nur Teile der Webseite darin zu lösen und nicht das komplette Frontend. Ja, das stimme ich total zu. Ich denke, dass es auch einfach eine Frage der Entwicklung ist. Also, es ist ja etwas, dass die WordPress-Umfeld erst beginnt. Und wenn wir in fünf Jahren hier sind, dann wird ja was grifft wahrscheinlich mit der meisten Leistung der Geräte. Guckt man da ganz anders drauf. Man muss sich, glaube ich, dem öffnen, weil es eine Frage der Zukunft einfach ist. Ja, das stimmt. Aber ich, was ich auch wichtig finde, ist eben der Punkt, den Ralph gebracht hat, dass es eben Zielgruppen gibt. Und ich glaube, die wird es auch in ein paar Jahren noch geben, aber auch darauf angewiesen sind, dass die Basisfunktionalitäten funktionieren. Und was ich eben das Spannende finde, ist, dass man auch das mit JavaScript machen kann. Denn wenn ich Entwickler bin, der richtig begeistert ist von JavaScript, warum nicht auch auf serverseitig sozusagen mit JavaScript arbeiten, dann hat man eben nur Beruchungspunkte mit dieser einen Sprache. Das ist einem vielleicht einschränkt, aber was vielleicht auch spannend sein kann. Erst mal vielen Dank für deinen schönen Vortrag. Ich sehe das halt auch so, dass das eben sehr zielgruppenabhängig ist, auch irgendwo auf die Anforderungen natürlich zutreffen muss. Wir machen nur was Ähnliches, was du hier vorgestellt hast, aber mehr auf Basis von Angular. Da geht es quasi darum, dass du natürlich auf WordPress als Community-Plattform benutzen kannst. Dort gibt es dann eben Pluckins wie BodyPress, das ist wirklich in der Benutzung nicht mehr irgendwie aktuell. Also die Leute erwarten eine andere Sache. Wenn ich für jede Aktualisierung erst einen Roundtrip irgendwie zum Server machen muss, um mir die neuen Notifications anzuschauen, ist halt ein modularisiertes Webpack-Framewerk wie Angular oder React wesentlich effektiver. Und die Leute kennen es halt eben auch von anderen Plattformen. Also BodyBoss ist für mich, wir arbeiten damit klar, aber es ist total outdated quasi in der eigentlichen Benutzung. Ich bin halt diesen Weg sehr, sehr interessant auch. Noch eine Sache zur REST-API, wenn man damit in Berührung kommt, Tipp von mir, sollte man sich mal Swagger anschauen. Das ist eine deklarative Möglichkeit, die REST-API quasi zu erweitern. Mich wird noch interessieren, ob du Projekte kennst, wo das WordPress Backend sozusagen dann mit JavaScript irgendwie neu gebaut wurde. Nein, kann ich bisher nicht, aber finde ich eine interessante Idee, weil man manchmal vielleicht nur ... HappyTables hat das Backend quasi für ihre User komplett selten geschrieben, kann nicht das komplette WordPress atmen, aber sie haben für ihre User, die Restaurantbetreiber ein Backend geschrieben, komplett auf JavaScript-Base. Ich weiß nicht, das ist halt schon relativ alt. Das dürfte noch kein React gewesen sein. Und die haben für ihre User einen Backend gebaut, was nur für deren Features ist. Also die selber, ihre Mitarbeiter gehen halt ins WordPress Backend, aber die Anwender gehen in den Ereignis. Genau, man kann dann eben auf Funktionalität einfach entfernen, die nicht relevant ist. Und natürlich, ein großes Beispiel ist ja WordPress.com, die eben Calypso verwendet. Weitere Fragen. Sorry, wenn ich euch so ein bisschen überhäuft habe, jetzt mit dem letzten Teil, der so ein bisschen sehr technisch war. Aber wie ich sehe aus den Ergebnissen, sind hier einige auf jeden Fall in die Yes Maybe Richtung gewandert. Und das war eigentlich mein Ziel insofern. Ja, aber das ist genau richtig. Das ist ja auch genau das, was ich sagen wollte. Es gibt keine richtige Antwort. Es gibt keine richtige Antwort. Genau, ja, dann sage ich vielen Dank.