Bevor Sie da hin dürfen, müssen Sie sich aber noch einen sehr interessanten Vortrag anhören, und zwar von Christian Mayer und Marc Jansen, adult.js, und mal gucken, wie erwachsen JavaScript geworden ist. Von daher viel Spaß und viel gutes Gelingen.

Herzlich willkommen an alle, die neu dazugekommen sind. Ich darf Sie begrüßen zu unserem Vortrag im Namen von uns beiden. Ich weiß nicht, ob Sie es wissen, aber JavaScript wird dieses Jahr 23 Jahre alt. Und eine meiner Lieblingsbands hat in den späten 90ern bereits gesagt,

Nobody likes you when you're 23. Also niemand mag dich, wenn du 23 bist. Und wir werden jetzt mal schauen in unserem Talk, ob das wirklich so ist, ob niemand JavaScript mag. Hier kurz die Gliederung, da springe ich jetzt drüber, um ein bisschen Zeit zu sparen. Ich stelle mich kurz vor, mein Name ist Christian Mayer, ich bin von der Ausbildung der Geoinformatiker, arbeite als Softwareentwickler und Architekt,

bin Open-Source-Enthusiast, arbeite intensiv am GeoEx-Projekt mit, bin dort auch Kernentwickler und Project Steering Committee-Mitglied und außerdem OSGEO Foundation Charter Member. Berufsisch gesehen bin ich als Geschäftsführer der Firma Maximum hier. Wir bieten Dienstleistungen im Bereich Open-Source GISS an,

mit dem Schwerpunkt Webmapping und Geo-Infrastrukturen, bieten maßgeschneiderte Softwarekonzepte und Entwicklungen an, außerdem Beratung und Schulung. Mein Name ist Marc Jansen, ich bin Geschäftsführer der Firma Terrestris, eine der drei Goldsponsoren der diesjährigen FOSCIS. Ich bin Kernentwickler auch in einigen Open-Source-Projekten,

die Sie vielleicht schon gehört haben, unter anderem bei dem Open-Layers-Projekt, auch von GeoEx. Und wie der Numa Gremling, einer meiner Vorredner heute, habe auch ich mal ein Buch geschrieben. Ich glaube, er ist noch mit dran, ein Buch zu schreiben. Ich hoffe, das Mikro hält durch. Wenn Sie also das nicht mehr kaufen können als Top-Weihnachtsgeschenk,

dann können Sie noch meins kaufen. Zu Open-Layers ist ein bisschen veraltet, aber die Konzepte sind nach wie vor hervorragend. Ja, und ich spreche gerne und unterrichte Menschen auf Konferenzen wie dieser oder auch der internationalen Variante. Und das darf ich machen für die Firma Terrestris. Wir bieten Open-Source GISS aus Bonn an. Wir machen dabei alles, Entwicklungen, Projekte, Support, Gewährleistungen, was auch immer Sie wollen.

Und wir beraten Sie, planen Sie. Wir helfen Ihnen von der Idee bis zur Fertigstellung, quasi schlüsselfertiges GISS, wie Sie das eben so brauchen. Motivation und Ziel. Also warum stehen wir zwei jetzt hier und sprechen mit Ihnen über AdultJS, eine Bibliothek, die es nicht gibt.

Brauchen Sie gar nicht zu gucken. Können Sie aber vielleicht noch registrieren lassen. Vielleicht ist das irgendwie mal ein interessanter Name für ein Paket bei NPM oder so. Nee, was wollen wir eigentlich hier machen? Wir zwei sind, wenn man es uns auch nicht ansieht, alte Hasen in diesem Zirkus. Wir beschäftigen uns schon seit vielen Jahren mit JavaScript und haben natürlich dabei festgestellt, dass wir,

und wir haben das schon in dieser Session gesehen, wir haben eben gesehen, was man mit TurfJS machen kann. Und so wie TurfJS gibt es noch viele andere Bibliotheken. Wir können auch unglaublich komplexe Sachen mittlerweile erledigen mit JavaScript. Es ist eine absolut vollwertige Programmiersprache.

Gleichzeitig werden die Applikationen, die wir damit machen, zunehmend komplexer. Das heißt, es sind eigentlich keine vier, fünf Zeile mehr, die wir so schreiben klassischerweise, sondern oft sind da sehr, sehr viele Dateien irgendwie beteiligt und irgendwie muss man das Ganze managen. Und eigentlich wollen wir nur klar machen, dass diese Zeiten der Spielsprache von JavaScript, dass sie manchmal immer noch von einigen Leuten gesehen wird, lange vorbei sind.

Und wir wollen mal so zeigen, wie professionell eigentlich JavaScriptentwicklung heutzutage so sein kann. Aber um das hinzukriegen, müssen wir uns zuerst KiddyJS angucken, quasi die dunklen Zeiten, als JavaScript irgendwann mal angefangen hat zu existieren. Das ist Brandon Eich. Dieser Mann hat mehr oder minder im Alleingang und wie die Mythen es so sagen,

innerhalb von unter irgendwie einer Woche JavaScript in der ersten Version quasi aus dem Boden gestampft. Und einige seiner zentralsten Konzepte, die er dabei drin hatte, prototypische Vererbung und so weiter, sind bis heute eigentlich noch immer da. Der hat damals für Netscape gearbeitet, der Name, über den Name ist viel diskutiert worden.

Es hatte zuerst einen, ich würde mal sagen etwas holprigen Start, aber mittlerweile, und diente auch eigentlich nur dazu, irgendwie so formulare Validierungen zum Beispiel zu erleichtern und um solche Sachen zu machen wie Elemente, die der Maus quasi vor der Maus flüchten. Das haben Sie sicherlich alle auch schon mal gesehen. Also so Spielkram halt.

Es hatte auch mal so eine kurzzeitige Serverseitige Unterstützung in sowas wie dem Netscape-Webserver. Das gibt es alles nicht mehr. Oder vielleicht gibt es das noch, aber so sah ja das Skript aus, was man damals gemacht hat. Sie sehen hier eine vollständige Applikation, über die man in 11 Zeilen, ist ein bisschen HTML, es wird eine Datei eingeladen, dann wird ein bisschen was instanziert

und im Grunde ist das eine vollständige GISS-Applikation gewesen. Wenn man das gleichwertige, wir haben den entsprechenden Code jetzt nicht dabei, jetzt machen würde, würde man wahrscheinlich drei, vier Bibliotheken zusätzlich hinzuladen. Man würde auch nicht OpenLayers.js einfach so hinzufügen, sondern nur das von OpenLayers, was man wirklich will. Sprich, das ist durchaus ein bisschen komplizierter geworden, sowas zu machen.

Man hatte zu dieser Zeit häufig einfache kleine Programme des Entwicklers. Also unser beider Lieblingstool war Steuerung U, wie unter die Haube schauen. Damit konnte man sich den Quelltext einer Webseite anschauen, das kann man bis heute noch. Nur bringt es halt heutzutage nicht mehr so viel, weil das, was man dort sieht, auch halt meistens so kompiliert ist, wie auch immer, und man kann es eigentlich gar nicht mehr verstehen.

Editieren fand damals häufig genug mit einem kleinen Editor direkt auf dem Server statt, weil es war ja eh nur kleine Sachen, die man machen musste, und man hatte eigentlich noch serverseitigen Code in Java oder wie auch immer, um halt überhaupt noch richtig Funktionität reinzubringen. Aber die Anwendungen wurden halt auch zunehmend komplexer, und das führte dazu, dass wir eigentlich schon Probleme hatten, unsere Dateien zu organisieren.

Das heißt, es gab dann sehr oft sehr, sehr lange Dateien oder Dateien, die irgendwie init.js hießen, aber dass die wirklich aufgerufen wurden oder eingebunden wurden in der richtigen Reihenfolge, dafür musste man sich selber kümmern. Das heißt, es gab nichts, was einem da irgendwie Unterstützung gegeben hat, sondern rein musste sich der Entwickler selber daran halten. Und Sie glauben gar nicht, wie oft er meinen Code überschrieben hat,

wenn wir beide gleichzeitig mal wieder irgendwo rumgevorwärkt haben, und umgekehrt natürlich genauso, weil wir überhaupt keine Projektstruktur, wie wir sie heute haben, mit hohem Professionalisierungsgrad, waren damals einfach nicht gegeben. Jetzt sehen wir hier so eine kleine Diskussion, und im Grunde übernehmen da zwei Menschen verschiedene Sichtweisen, und der eine sagt so, ja, hör mal, lieber Christian, also View Source, also Steuerung U,

das ist doch genau das, so haben wir es doch auch gelernt, so sollten es doch eigentlich alle anderen auch lernen, wie man eigentlich ja was programmiert, wie man so eine Applikation macht, und es ist irgendwie weg, diese Magie, das kann man jetzt alles nicht mehr machen, wenn ich irgendwie so eine Website irgendwo sehe, da ist es super schwierig, eigentlich für mich rauszukriegen, was da los ist. Ja Mark, wir haben halt 2018, und wir haben einfach einen unfassbaren Schatz an Ressourcen mittlerweile,

von Open Source Projekten, wo der Code einfach offen liegt, von Dokumentationen, von Tutorials, YouTube Videos, die es damals einfach in der Fülle gar nicht gab, und wir uns quasi mit View Source einfach nur ein Hilfsmittel gesucht haben, das heißt, das ist alles schon so okay, wie es jetzt ist, also wir können das echt lassen mit dem Steuerung U,

da brauchen wir nicht melancholisch in alten Zeiten irgendwie nach trauern. Ja, was können wir denn sonst heute machen? Ja, wir können super viel mit JavaScript heute machen, das ist auch ein bisschen Fluch und Segen, das haben wir auch gestern im Open Layers Workshop gemerkt, die Ramp-Up-Time, also bis man an das eigentliche Problem lösen kommt,

dauert immer ein bisschen länger, aber dann sind wir halt in der Lage wirklich auf höchster Ebene professionell mit JavaScript, wie wir es früher mit Java, C++ und C Sharp gemacht haben. Everything and Nothing JS, was wollte ich eigentlich damit sagen? Naja, wie ich eben gesagt habe, wir haben einen Riesenschatz an Open Source Bibliotheken, die wir super einfach über NPM, sagen wir mal den Node Package Manager,

mit ein paar Kommandozahlenbefehlen einbinden können, das heißt, das wilde Suchen von irgendwelchen Bibliotheken und selbst runterladen und irgendwie einhängen ist vorbei. Warum Nothing? Na ja, wohl ist es auch Shappen, wir haben am Montag auf dem Cold Sprint, haben wir so ein bisschen mal wieder ein bisschen JavaScript programmiert und haben an so einem Kurven-Algorithmus gearbeitet

und haben dazu eine Bibliothek eingebunden, die wiederum dieses Paket weg zwei Copy eingebunden hat. Dann haben wir mal in den Code geschaut, was die Bibliothek eigentlich macht und im Prinzip ist das quasi ein eigenständiges Modul, was veröffentlicht ist, was einfach nur zwei Werte aus dem Array kopiert.

Und das sind dann Formen der Modularisierung, wo ich dann irgendwann wieder sage, naja, da kippt es dann irgendwann wieder über, was man eigentlich machen könnte. Es ist jetzt ein zufälliges Beispiel, es hat uns nicht lange gedauert, um dieses Beispiel zu finden und dieser Autor dieser Bibliothek soll jetzt nicht böse sein oder so. Es ist einfach nur ein Beispiel dafür, wie man es manchmal vielleicht einfach zu weit treiben kann. Vor allem, weil man das, um den Originalcode zu verstehen,

muss ich mir letztlich, also um wirklich dieses View Source zu machen, muss ich mir letztlich auch das anschauen, weil ich weiß ja nicht, was der da macht bei weg zwei Copy. Wir teilen es uns, ne? Okay, also sind wir beim Heute angekommen. Wir haben allein in dieser Session schon wieder eine neue Bibliothek kennengelernt, VEGU, von Herrn Meier vor allem.

Es gibt aber solche Bibliotheken tatsächlich en masse, auch das hat er erwähnt. Es gibt Frameworks We React, Angular, Ember, was auch immer Sie da nennen wollen. Da gibt es wirklich reichliche Auswahl. Genauso viele Tools und Paradigmen gibt es letztlich, also ob ich Model View View Model mache oder Model View Model,

oder wie man das auch immer nennt, ob es bidirektional ist oder lieber doch nur unidirektional. Es gibt eine ganze Menge an Boilerplates und Generatoren, also Hilfscripten letztlich, die man mit einem Kommandozahlenaufruf benutzt, um halt alles schon einfach ein bisschen einfacher zu machen, damit so ein Setup ein bisschen schneller geht. Außerdem gibt es auch nicht mehr nur JavaScript oder ECMAScript,

die standardisierte Variante. Es gibt auch TypeScript, von Microsoft erfunden, letztlich ein super Set von JavaScript, was also noch so was wie Interfaces mitbringt, ganz plakativ, und wovor auch so super viele Leute drauf sehr abfahren. Dazu gibt es jedes Jahr jetzt ein neues ECMAScript, das heißt, die Zeiten, wo man lange auf irgendwie einer Version von ECMAScript mit irgendwelchen Features festgefahren ist, die sind eigentlich auch vorbei.

Das heißt, eigentlich ist jedes Jahr eine neue Version aktuell. Davon abgesehen ist JavaScript mittlerweile überall. Das sollte schon der Normalfall sein eigentlich. Also es dient jetzt nicht nur hierzu, diese Präsentation von links nach rechts zu bewegen, sondern es läuft auch auf dem Server und löst da Probleme. Hashtag turf.js, wie wir es eben gesehen haben, kann man wunderbar dafür benutzen. Und erinnert sich nach irgendjemand an die Zeiten,

als man vor vielen Jahren gesagt hat hier, was passiert eigentlich, wenn ich meine Webseite aufrufe und ich habe kein JavaScript an? Also früher war das ja nicht selten der Fall, dass es Menschen gab, die sagten, ich mache JavaScript aus, wenn ich im Internet unterwegs bin, weil ich irgendwie dieser Sache nicht traue oder weil die Leute das auch irgendwie unprofessionell auf eigen gesetzt haben. Also ich habe das lange nicht mehr gesehen, dass jemand JavaScript aus hat.

Versuchen Sie es nicht, wenn ich weit komme. Viele Sachen funktionieren tatsächlich nicht mehr. Und da sind wir eigentlich bei dem Problem. Da unten ist es so ein bisschen hervorgehoben, auch von uns. Das ist eine Aussage von Eric Clemens. Brauchen Sie nicht zu kennen, trotzdem schreibt er tolle Artikel. Und er hat diesen Begriff, dieses JavaScript-Fatigue, also die Ermüdungserscheinungen, die bei JavaScript so ein bisschen erscheinen, auch mitgeprägt. Bis das man wirklich an den Punkt kommt,

wenn man wirklich was Neues schafft, also von mir aus ein Algorithmus, der eine Kurvenklettung macht, hat man so eine Ramp-up-Time und so viel drum herum, was einem viel hilft für Professionalisierung, dass einem das schon manchmal den Spaß ein bisschen nehmen kann, eigentlich an der Entwicklung. Aber man darf halt auch nicht vergessen, dass man diese Professionalität, die wir halt mittlerweile in dieser JavaScript-Welt haben, die bekommt man nicht umsonst.

Und man ist da gerade ganz aktuell dran, einfach diese Ramp-up-Time wieder geringer zu machen, um Menschen, die halt gerne was erzeugen wollen mit JavaScript, das Leben leichter zu machen. Damit sind wir bei Best Practices. Das ist dann das Fazit, was wir daraus machen. Es ist jetzt einfach die Zustandsbeschreibung, ist wie es ist. Was bedeutet das für uns?

Genau. Hier haben wir kurz aufgelistet, das Node.js ist JavaScript auf dem Server. Ein ziemlich mächtiges Tool, auch sehr cool. Falls Sie es nicht kennen, sollte es unbedingt mal ausprobieren. Es kann sehr große Datenmengen durch ein nicht blockierendes IOS-System verarbeiten, ist wie das JavaScript im Browser eventbasiert.

Und somit ideal für Web-Anwendungen, gerade auch im GISS-Bereich, wo man mal vielleicht größere Daten hat, die man durch die Pipeline schicken muss. Node.js selbst ist auch unter MIT-Lizenz, also Open Source, das ist eine klasse Sache. Und wir beide haben das tatsächlich 2015 auf der Vosges in Münster bereits schon mal vorgestellt. Die Slides in Online kann man auch schon mal reingucken, hat sich zwar viel getan, aber die Grundkonzepte

sind auch da noch die gleichen. Und das Schöne oder so ein bisschen Paradoxe, ist, dass Node.js für uns als Frontend-Entwickler super wichtig geworden ist, weil es quasi unsere komplette Environment, also die Entwicklungsumgebung bereitstellt. Weil wir unseren Entwicklungswebserver machen wir mit Node auf. Das ist irgendwie ein Zweizeiler in Node.js.

Beziehungsweise bekommen wir dann wieder über ein MPM-Paket von jemand anderem geschenkt. Unser Abhängigkeitsmanagement, die Build-Tools, die Unit-Tests, sind alles im Prinzip Node-Skripte, sodass wir quasi die serverseitige JavaScript-Lösung nutzen, um unsere kleinzeitigen JavaScript-Projekte auf professioneller Ebene gestemmt zu kriegen.

Klingt erstmal ein bisschen paradox, ist aber ein supercooles Setup, was wir nur jedem empfehlen können. Und jetzt zum dritten Mal, das dauert ein bisschen länger, bis man das am Laufen hat. Früher Text-Editor auf Script-Tag rein. Heute muss man das sich entweder generieren lassen oder einmal selbst zusammenstecken. Aber dann hat man quasi den Benefit, sobald es größere Projekte werden. Und wir reden halt von Entwicklerteams mittlerweile.

Man ist nicht mehr alleine. Man hat Leute dabei, die kollaborieren. Und dann braucht man solche Mechanismen, wie es in anderen Programmiersprachen über Jahre üblich war. Vielleicht noch einmal ganz kurz zurück zur Ergänzung dazu, weil es mir jetzt gerade auch einfällt. Also wir zwei haben uns ja überlegt, was machen wir mit diesem Talk? Und wir sind dann so ein bisschen melanchulisch geworden,

wie man das so macht, wenn man fortgeschrittenen Alters ist. Und wir haben ein bisschen überlegt, ob wir die Folie hier reinnehmen, weil das irgendwie für uns sowieso normal ist. Wir machen das, das gibt es bei WakeU garantiert. Ich habe es mir noch nicht so detailliert angeguckt. Das gibt es da alles. Das hat aber Ewigkeiten gedauert, bis das der Normalfall wurde in JavaScript. Und da kann man letztlich als Community,

also JavaScript-Community und das ist nicht nur die JavaScript-GIS-Community, sehr stolz darauf sein. Das ist so professionell, wie es nur irgendwie sein kann. Und wer das noch nicht für seine aktuellen Projekte einsetzt, der sollte da bitte mal reinschnuppern. Das macht so einen Spaß. Das ist für den Endnutzer am besten das allerbeste, was rauskommt. Die Qualität von dem, was man macht, da steht Unit-Testing. Lange Zeit war das irgendwie noch so der Sonderfall,

dass man irgendwie einen Unit-Test geschrieben hat. Auf GitHub irgendwas zu finden, wo jetzt nur bedingt Unit-Tests sind, da hat man schon gar keine Lust mehr, das zu verwenden, weil man einfach schon so hohe Ansprüche hat. Man sollte es vielleicht auch jetzt in Ruhe machen, bevor man das überrennt. Einfach jetzt schon mal reinschauen, weil zum Beispiel OpenLayers wird in der nächsten Version noch beide Typen von JavaScript,

ECMAScript 5 und 6, unterstützen. Aber ich schätze, in der übernächsten, also in der OpenLayer 6, wird es nur noch die ECMAScript-Module geben. Das heißt, Sie müssen sich damit außen hintersetzen und Sie wissen, wie es ist, besser mal in Ruhe, wenn man noch nicht so viel Druck hat, das Ganze machen. Anstelle, dass man dann aufgrund von irgendwelchen Abhängigkeiten dahin kommen muss. Genau. Dann sind wir bei der Frage, hier hätte man noch

Flow dazuschreiben können, auf so eine weitere, andere, sehr JavaScript-ähnliche Sprache, die es noch einfacher macht, gewisse React-Sachen beispielsweise zu entwickeln. Also, sollen Sie jetzt, wir sind ja bei dem Best-Practice-Teil, sollen Sie jetzt alle umswitchen auf TypeScript? Sollen Sie nur reines ECMAScript nehmen der nächsten Generation und sich das übersetzen lassen mit Babel in ECMAScript 5

von mir aus, damit es auch im letzten IE4 noch läuft? Oder setzen Sie auf Java Script so mit so ein bisschen hin und her, was Sie gar nicht genau wissen? Und unsere Antwort ist ganz klar. Ja, ihr müsst das selber rauskriegen, leider. Wir geben euch da keine klare Kaufentscheidung. Das Wichtige ist, wenn ihr schon Java Script macht, dann müsst ihr da einfach, ja,

weiter auch die anderen Sachen mal ausprobieren. Ich finde es sehr toll, dass wir da mittlerweile so verschiedene Optionen haben, weil die einander auch befruchten. Das heißt, das was jetzt noch TypeScript ist, Interfaces zum Beispiel, das kann auch in einem offenen Prozess irgendwann mal ECMAScript werden. Das heißt, bitte probiert diese Sachen aus, auch da gibt es wunderbare Build-Tools, die einem helfen.

Bitte versucht das alles mal. Und sehen Sie es einfach als Chance, dass es diese verschiedenen Möglichkeiten gibt. Sehen Sie es wie eine Werkbank mit verschiedenen Werkzeugen und suchen sich ihr passendes Werkzeug raus. Man kann auch sagen, ja, jetzt gibt es da wieder verschiedene Sachen und so weiter. Also erstens sind das alles ECMAScript-Dinge, also die auf dem gleichen Standard basieren. Die sind alle ohne Verluste ineinander überführbar. Und letztlich kommt da immer bärenstarkes

Java Script am Ende raus durch diese Compiler, die eins zu eins von ihrem Browser verstanden und verarbeitet werden können. Das heißt, erzählen Sie es einfach als Chance, dass Sie die verschiedenen Werkzeuge haben und nutzen Sie das, was für Ihren persönlichen Need am besten ist. Insgesamt Build-Tools. I don't need macros there to do complicated

and not useful. Aber währenddessen hat man irgendwie Flow mit JSX, mit Babel, mit zwei dutzenden Plugins und eine Webpack-Konfiguration, die so und so lange ist. Auch da gilt, bitte fahren Sie den Weg des geringsten Widerstands, lassen Sie sich solche Sachen generieren, probieren Sie was aus und versuchen Sie nicht, wie das uns beiden auch schon passiert ist, sich in diesen Kleinigkeiten zu verrennen. Sie kriegen relativ zügig

eigentlich eine ganz gute Optimierung hin mit diesen Klassikern. Und dann reicht das vielleicht auch, bis Sie entsprechende neue Anforderungen bekommen, wo Sie sagen, okay, ich muss noch das letzte Quäntchen rausholen. Da ist ein bisschen Augenmaß, glaube ich, ganz hilfreich, wenn man sich diese Tools anschaut. Damit sind wir beim Fazit. Ich hoffe, Sie sind ein bisschen deutlich

geworden, dass die JavaScript-Welt und da reden wir wirklich nicht nur über diese GISS-Welt, obwohl wir auch, wir hatten am Anfang mal eine Folie drin, wo wir JavaScript-GISS-Bibliotheken aufgezählt haben, gibt es reichlich, können wir gleich in den Fragen noch ein paar erwähnen, turf.js beispielsweise zählt dazu, aber auch die anderen Dinge, die wir eben kurz angesprochen haben. Hochgradig professionell geworden, JavaScript-Entwicklung in 2018.

Und auch schon etwas länger, also es hat nicht erst im Jahresanfang angefangen. Die Entwicklung von JavaScript geht auch noch in der Form letztlich weiter. Also npm ist nicht nur einfach toll, sondern es ist auch die größte Bibliothek an austauschbarem Code, die es jemals zu Menschen gedenken gab. Also es gibt sowas ähnliches, gab es schon für Perl

und was weiß ich was, die haben nie so viele Module gehabt, wie das Node.js hat. Teilweise auch in zweifelhafter Qualität oder teilweise auch mit solchen Sachen, wie wir es eben hatten. Aber bitte schöpfen Sie da aus dem Vollen und createn Sie irgendwas Neues. Also machen Sie irgendwas Neues. Das, was festzuhalten ist, dass durchaus auch komplexe Konstrukte da sind, also wenn Sie noch nicht gewohnt dran sind, wie man mit ECMAScript 6 schreibt

und sich den Code anschauen, ist es manchmal ein bisschen schwieriger darüber zu diskutieren, weil man es vielleicht nicht so schnell begreift, was dort eigentlich passiert, aber der Umstieg lohnt sich hundertprozentig. Das, was wir eben bereits auch schon gesagt haben, es gibt reichlich Dokumentationen, die einem das Leben verbessert an der Stelle. Das heißt, wenn Sie irgendwie Hilfe brauchen, um irgendwie solche Sachen

zu lernen und Ihren bestehenden Bildprozess irgendwie umzubauen, das kriegen Sie hin. Da sind wir sicher, es gibt reichlich Ressourcen in allerlei Sprachen. Und letztlich kommt das Ganze runter auf zwei Sachen. Also entweder kennen Sie schon Javascript, dann empfehlen wir Ihnen bitte, bitte bleiben Sie am Ball, oder aber Sie kennen es noch nicht, dann bitte lernen Sie es jetzt.

Es lohnt sich wirklich und damit danken wir beide für die Aufmerksamkeit und hoffen Sie haben noch Fragen oder Anmerkungen. Danke für den inspirierenden Vortrag. Vielleicht schon ein kurzer Nachtrag, also was wir auf keinen Fall wollten Sie irgendwie zu entmutigen, wenn so zwei

alte Hasen hier stehen und ein bisschen Melakonie schwellen, wie es früher war. Wir haben den Umstieg auch gemacht und wir finden es klasse, auch wenn wir es früher auch total super fanden. Aber gehen Sie wirklich den Weg, irgendwann, wenn Sie sowieso nicht drum herum kommen, es ist echt klasse, also wir wollen Sie da wirklich ermutigen, diesen Weg mitzugehen. Mein Name ist Marc und ich schreibe

Eggmascript 6. Genau. Gibt es denn Fragen aus dem Plenum? Nicht so schüchtern. Sollen wir das Foto nochmal zeigen von Blink 182? Alle so geflasht und die haben alle Hunger.

Und alle müssen zum Foto. Genau. Dann frage ich einfach mal was. Aus eurer Erfahrung her, wie würdet ihr das, du hast ja schon gesagt, es ist ein Qualitätsanstieg in der JavaScript-Welt. Würdest du auch sagen, hat es dir Zeit gekostet oder im Endeffekt hast du jetzt mehr Zeit

für die richtige Webentwicklung? Vielleicht sind ja Firmen da, weil die sagen, setz dich mal Mitarbeiter dran, lohnt sich das überhaupt? Ja, also es kostet erstmal Zeit. Das ist einfach so, wenn man diesen Umstieg wagt. Man muss Know-how aufbauen, man muss jedenfalls Bestandscode ändern.

Das geht auch nicht von heute auf morgen. Aber wie bei vielen solchen Dingen, ist es erstmal ein Invest, der sich später auszahlt. Das kann ich jetzt keine Zahlen oder eine Quantifizierung nennen. Aber der Invest lohnt sich auf jeden Fall, weil man dann den Return, also den bekommt man zu einem späteren Zeitpunkt doppelt und dreifach zurück. Es ist tatsächlich so, gerade wenn man in Teams entwickelt und nicht alleine nur so für sich hinkodet,

sondern auf Enterprise-Ebene, um ein bisschen hochtramend zu klingen, in Teams professionell entwickeln mag. Ich möchte da auch noch kurz was ergänzen. Und zwar mit einem plakativen Beispiel. Ich glaube, im Gesamten hat man am Ende Zeit erspart und dem Developer auch ein bisschen mehr geistige Gesundheit übrig gelassen. Denn wenn Sie einen modernen Editor verwenden,

ich nenne es mal Visual Studio Code beispielsweise oder von mir aus auch Atom, und das sind auch Open Source Tools, und Sie da ECMAs RIP6-Sachen editieren, dann können Sie damit genauso arbeiten, wie mit einer statisch kompilierten Sprache wie Java. Also es gibt sowas wie Refaktorierung, es gibt sowas wie mach hier draus eine Klassenmethode aus einer anonymen Methode, es gibt sowas wie Autovervollständigung.

Und zwar kriegen Sie das alles geschenkt für jedes von diesen Bibliotheken. Das heißt, Sie machen irgendwie ein MPM-Install von irgendeiner dubiosen Klassepaket und während Sie das noch gerade benutzen, wird eigentlich schon Ihr Editor in die Lage versetzt und Sie damit auch ganz easy damit zu arbeiten. Das ist ein Beispiel nur dafür. Das lohnt sich auf jeden Fall.

Und am Ende hat auch der Nutzer davon was. Letztlich schreibt man Java Script ja immer dafür, dass dann zum Beispiel irgendeine Webseite mit einer Karte kommt. Wenn das Ganze schnell und crisp da ist, dann freuen sich alle auch. Also das hat wirklich, glaube ich, überragend mehr Vorteile, denn Nachteile, wenn man auch am Anfang ein bisschen investieren muss in Zeit vor allem.

Eine Frage, sehr schön. Ich wollte mal fragen, ob Sie eigentlich auch die Class-Syntax jetzt gezielt einsetzen, jetzt ja relativ neu dazugekommen ist. Vorher hatte man auch schon Vererbung, das war irgendwie

Objektvererbung, hat sich halt anders angefühlt. Nutzen Sie das? Hängt davon ab, also in OpenLayers, dem Projekt, wo ich jetzt also dem, was wahrscheinlich die meisten auch kennen, da haben wir intern auch ganz viele Klassen und wir setzen auf diesen alten, auch in diesem aktuellen Rewrite, setzen wir noch auf den alten Weg, also diese prototypische Vererbung.

Übrigens, Fußnote, die Class-Syntax macht hinter den Kulissen nichts anderes. Also das ist nur syntaktischer Sugar, wie der Engländer sagen würde, über die alte Art und Weise, wie man prototypisch vererbt. In OpenLayers werden wir das erstmal jetzt nicht tun, aber es ist nicht ausgeschlossen, dass wir das später tun, weil es einfach lesbarer ist. Es ist viel lesbarer, die Menschen verstehen es viel besser und das ist das

wichtigste. Code wird einmal geschrieben und 20 mal gelesen. Und deshalb muss man dafür sorgen, letztlich, dass das gut funktioniert. Und in privaten Projekten oder in Projekten, wo wir mehr auf alle Aspekte einfließen können, wie beispielsweise die Projekte von der Firma Terrestris, da setzen wir auf jeden Fall auf diese Class-Syntax. Einfach einfacher. Gut, dann

danke fürs Zuhören, danke für den schönen Vortrag, für den Einblick und alle ab zum Foto und dann zum Kuchen. Dankeschön.