|

Die EnterJS 2019 - Ein Erfahrungsbericht

In der letzten Juni Woche fanden sich auch dieses Jahr wieder etliche Entwickler* aus ganz Deutschland und teilweise sogar aus dem Ausland zur 5. EnterJS in Darmstadt zusammen.

Während ich letztes Jahr noch mit all meinem Frontend-Kollegen auf der Konferenz war, haben wir uns dieses Jahr mehr auf verschiedene Konferenzen aufgeteilt.
Da mich bereits letztes Jahr das Event mit ihrer großen Vielfalt an Themen im Vorjahr sehr begeistern konnte, zog ich dieses Jahr also alleine in Richtung Darmstadtium.

Eingangsbereich des Darmstadtiums
Bildquelle: EnterJS auf Twitter

Die EnterJS ist eine vom dPunkt-Verlag organsierte Schulungsveranstaltung für JavaScript Entwickler im Enterprise Umfeld.
Das Event besteht aus zwei Workshoptagen und zwei Konferenztagen, wobei ich nur bei der Konferenz war.

Bitte beachtetet außerdem, dass ich logischerweise nur über die von mir besuchten Talks berichten kann. Viel Spaß beim Lesen 😊

Das Web ist für alle da

Der erste Konferenz-Tag begann mit einer Keynote von Simona Cotin über "Machine Learning", einem der großen aufkommenden Themen der letzten Jahre.
Tatsächlich ging es in der Keynote allerdings weniger um verrückte Welteroberungs-KIs wie HAL 9000, Tetris-Bots oder Deepfakes. Viel mehr um das Web als Technologieplattform im Allgemeinen:
Was ist das überhaupt das "Web", wie ist es entstanden und was macht es damals wie heute zu so etwas Besonderem und letzlich so großartig?

"Web for all" steht auf einer Slide von Simonas Präsentation

"Everyone should be able to use the web as it is today." - Simona Cotin

Zitatquelle: @ericwbailey

Geschickt verschob Simona durch diese Geschichtsstunde die Fragestellung weg von was können wir tun zu was sollten wir tun und viel wichtiger: Wem bringt das am Ende wirklich einen Nutzen?

Denn wie lehrte uns schon die freundliche Spinne aus der Nachbarschaft:

Aus großer Kraft folgt große Verantwortung!

So ging es also unter anderem um Dark Patterns, sprich Manipulation der User, sowie um die Zugänglichkeit der Platform, ein Thema, welches leider gerade im Enterprise Bereich sehr oft vernachlässigt wird. Mehr dazu später.

Simonas Talk stellte noch einmal ganz deutlich klar:

Für wen machen wir das hier überhaupt? Und wozu?

so dass uns der Talk zu den weiterführenden Themen führte.

ECMAScript unter der Lupe

ECMAScript, JavaScript, TypeScript, ...
Die Liste der Begriffe die auf "-Script" enden ist lang und undurchsichtig.
Und dann gibt es ja auch noch diese seltsame Versionierung mit ES5, ES6, ES 2016 oder neuerdings auch ES 2018 und ES 2019 (seit Juni dieses Jahres).

Bei all dem Wirrwarr ist es verständlich, da nicht mehr ganz durchblicken zu können.
So oder zumindest so ähnlich, scheint es auch der ehemaligen Studentin Lisa Messerli (hat leider kein Twitter, hab gefragt 😅) gegangen zu sein, so dass sie das tat, was der absolvierte Student so tut wenn er etwas nicht versteht: Er schaut in Büchern nach Antworten. 📚🎓
Doch leider stellte sich dies als weitaus schwieriger als erwartet heraus, denn es gibt kaum (gute) Bücher zu diesem Thema.
Dafür gibt es allerdings jede Menge Blogartikel, Fachartikel und Stack-Overflow-Antworten, die sich allerdings auch nicht so ganz einig zu sein scheinen, wenn es um einzelne Versionsunterschiede geht.

Um endlich verlässlich durchblicken zu können, hat sich Lisa letztlich dann in das TC39, Technical Committee for ECMAScript Proposal-Verfahren (Vorschläge für die nächste ECMAScript Version) eingearbeitet.

Hier eine kurze Erläuterung der Versionen.
Kurz gesagt:

🌐 ECMAScript ist die Definierung der (Programmier-)Sprachstandards für das Web.
💬 Während JavaScript, TypeScript etc. sozusagen die von der Sprache abgeleiteten Dialektformen sind.

📝SIDENOTE:
Michael Aranda hat einen meiner Meinung nach sehr guten und umfangreichen Blogbeitrag über das Thema geschrieben, wen es interessiert, kann gerne dort vorbeischauen.

Nun aber noch kurz ein paar Worte zu der neuesten Version von ECMAScript, ES 2019:
Dieses Featureset /sollte/ seit letztem Monat offiziell fertig gestellt sein. Viele der Features (zugegeben es sind nicht sehr viele Features Teil von ES 2019) sind dank Babel und Co. bereits benutzbar.
Bis die Features allerdings global in allen modernen Browsern out of the box funktionieren, wird es wohl noch ein wenig dauern.

Die einzelnen Features von ES6, ES2016 bis ES2019 stellte Lisa uns anschaulich an diversen TypeScript Code-Beispielen dar, wobei sie immerzu das Publikum miteinbezog.
Mir persönlich gefallen vor allem die Regex-Erweiterungen aus ES2018 (was auch kein Satz ist, von dem von dem dachte, ihn eines Tages mal zu äußern 😅😂)

Web Components sind tot - Lang leben Web Components

Das am kontroversesten diskutierte Thema der Messe waren vermutlich Web Components.

Da mich Web Components selbst sehr stark interessieren und ich mich schon im Vorfeld viel damit beschäftigt habe, erhoffte ich mir auf einige meiner schon lange offenen Fragen endlich eine Antwort.
Diese sollte ich auch bekommen, wobei ich sie allerdings nicht unbedingt als zufriedenstellend betiteln würde.

Vergleich der Web Stacks von 2014 und 2019.
Es zeigt sich: Vieles was früher ein Framework machen musste, ist heutzutage dank Web Standard möglich.

Quelle: Ich auf Twitter über René Winkelmeyer

Denn während einige Speaker wie u.a. Alexander Knapstein zusammen mit Dominic Böttger oder auch René Winkelmeyer die Technologie anpreisen 🙏🏼 und zeigen, dass man diese Low-Level API (zu Teilen) auch mit legacy Browsersupport (namentlich IE11) produktiv verwenden kann wie beispielsweise bei Sixt MyDriver oder Github zu sehen, äußerten sich andere u.a. Oliver Zeigermann dem Thema gegenüber deutlich skeptischer 🤨.

Ihre Kritikpunkte sind ziemlich klar und deutlich:
Die Technologie ist

  • zu Boilerplate-lastig
  • wirkt unnötig komplex
  • die Syntax ist zu verbose (man wiederholt sich sehr oft) *(siehe update)
  • Polyfills decken unzureichend Features wie etwa den ShadowDOM ab
  • Bei Verwendung des ShadowDOMs gibt es SEO-Probleme *(siehe update)
  • und nicht einmal das Einsatzgebiet für Web Components ist so richtig eindeutig geklärt.
  • usw...

Update (29.07.): Dominic Böttger hat sich nochmal zu Wort gemeldet und gesagt, dass einige der offenen Fragen mittlerweile geklärt seien: So scheint das SEO Problem mit dem Shaddow DOM doch kein Problem zu sein und auch die verbose Syntax ist dank dem neuen Prerenderer von StencilJS kein wirkliches Problem mehr. (Wenn man sich für Stencil als Buildtool für Web Components entscheidet, versteht sich 😅)

Quelle: dieser Tweet

Es zeigt sich:
Die Technologie steckt (immer) noch in den Kinderschuhen.
Zusätzlich schränken Legacy-Browser die Möglichkeiten der Web Components stark ein und verhindern, dass die Technologie ihr meiner Meinung nach durchaus vorhandenes Potential entfalten kann.
Also mal abwarten, wie sich die Technologie weiterentwickelt und bis in drei Jahren der IE-Support endlich das Zeitliche segnet.
So oder so: Es bleibt spannend!

Technologien, die uns das Leben erleichtern sollen

Unsere Softwarestacks sind groß, vielseitig und manchmal ziemlich undurchsichtig.
Da können Einblicke in die einzelnen Systeme helfen, diese besser zu verstehen und tiefgreifende Zusammenhänge zu erkennen.

So hat uns Mirco Zeiß nicht nur erklärt, wie man eine eigene ESLint-Regel schreiben kann, sondern auch, wie ein Linter das zu scannende Dokument unterteilt und wahrnimmt.
Erwähnenswert ist hierbei vor allem auch das Onlinetool AST Explorer, das den User beispielsweise eine JavaScript Datei aus der Sicht eines Linters betrachten lässt.

Auch die Technik des Hot Module Replacements (kurz HMR) mit Webpack wurde uns anschaulich von Stanimira Vlaeva an einem Beispiel eines Weihnachtsbaum-Generators im Terminal 🎄 (also anhand eines zur Jahreszeit passenden Beispiels 😅😂) auf Basis von Node.js demonstiert.
Durch HMR ist es möglich, Code zu aktualisieren, ohne den kompletten State der Applikation mit jeder Codeänderung zu verlieren.

Hier mal ein eigenes, einfaches Beispiel hierfür: Wir wollen ein Formular ausfüllen, um es zu testen.
Normalerweise müsste man nach jedem Code-Update das Formular neu ausfüllen. Dank HMR merkt sich das Formular jedoch praktischerweise den aktuellen State und es kann ohne wahrnehmbare Verzögerung mit dem angepassten Formular weiterentwickelt werden, ohne dass dabei die bereits ausgefüllten Formular-Felder neu befüllt werden müssen.

Auch das von Rainer Hahnekamp vermittlete technisch tiefgehende Verständnis dafür, wie die browsereigene Garbage Collection, sprich das automatische Entfernen von ungenutzen Variablen aus dem "Heap" (engl. für "Haufen") Zwischenspeicher funktioniert, war nicht nur sehr spannend, sondern es hilft hoffentlich eines Tages State-Probleme zu identifizieren und im besten Fall auch dauerhaft zu beheben.

Vom Murmelspiel 🧮 über schwarze Magie 🔮 bis hin zur A11y ♿

Meine persönlichen Highlights waren dann aber wohl die folgenden drei Talks:

🧮 Marble-Diagramme und andere RxJs Patterns

Michael Hladky sorgt dabei mit seiner lockeren und lustigen Art für mehr Durchblick bei RxJs Prinzipien und Patterns. Die Libary dient dabei dem Umgang mit speziellen, asynchronen API-Antworten, den sogenannten "Observables". (bekannt u.a. aus Angular)

Dank dem Talk kann ich nun nicht nur Marble-Diagramme die zur Visualsierung der Verhaltensweisen dienen, besser bzw. richtig verstehen, sondern kenne jetzt auch die Hintergründe von Reactive Extensions in JavaScript und bin hoffentlich dank Funktions-Gruppierungen auch in der Lage, einen geeigneten Operator zu finden und anzuwenden.

🔮 Das Backend typensicher machen (mit TypeScript)

Peter Kröner steht vor dem Publikum und zeigt auf dem Projektor "dunkle Magie" in Form von einem sehr komplexen und unverständlichen Code-Schnipsel in TypeScript
Peter zeigt uns ein komplexes TypeScript Beispiel.
Keine Sorge: Das sieht einfacher aus, als es ist. 🤯😂

Bildquelle: @g33konaut auf Twitter

Peter Kröner ist da etwas, sagen wir mal, anders. In einem Mordstempo (das an eine Videogeschwindigkeit von 2x erinnert) erklärte der selbsternannte Erklärbär🧸 uns, wie wir
frontendseitig den lustig-dreinschauenden TypeScript Typen "any" (in Fachkreisen auch "yolo" genannt) loswerden können, in dem wir

Mehr Typen schreiben um (letzlich) weniger Typen zu schreiben.

Klingt verwirrtend, und ehrlich gesagt ist es das zunächst auch.

Einfach gesagt prüfen wir ob die automatisch zugewiesenen Typen ("foo" ist immer ein String; 42 hingegen immer eine Zahl) der Backend API-Antwort unseren Erwartungen entsprechen. Und wenn nicht, dann "swipe left" (das ist Tinderisch für) "und wir lehnen die Anfrage ab".

Nur eine Frage konnte Peter leider nicht beantworten: "Holst du beim Reden auch mal Luft? 🗣️"
Wahrscheinlich werden wir es nie erfahren...

♿ A11y geht uns alle an. Aber dieses Mal wirklich!

Und zu guter Letzt bescherte Eric Bailey mir und vielen Anderen Gänsehaut:
Und das bei einem Thema, von dem ich dachte, dass ich diesbezüglich nicht mehr groß überrascht werden könne, schließlich habe ich selbst vor einiger Zeit mal an einem Talk für das Frontend-Meetup Rhein Neckar zu dem Thema mitgearbeitet:
Die Rede ist von "Accessablity" (kurz: A11y), sprich Barrierefreiheit im Netz.

Präsentationsfolie mit dem Inhalt: "Disability is a mismatch between a person´s abilities and their environment"

Quelle: Eric Bailey

Und wie bei der ersten Keynote vom Vortag war die Aussage sehr deutlich: Das Web ist für alle da. Jedem* sollte die Benutzung ermöglicht werden, jeder* kann betroffen sein.
Und natürlich denkt man trotzdem "ja, aber ich nicht" und vermutlich beeindrucken einen selbst auch Statistiken zu dem Thema nicht sonderlich.

Aber als das Publikum gebeten wurde, sich bei körperlichen und mentalen Einschränkungen zu melden, (sofern man sich damit wohl fühlt) wurde es plötzlich still und nur noch die Blicke wanderten umher.
Denn wohl-gefühlt hab (zumindest) ich mich nicht sonderlich als ich mich zusammen mit anderen gemeldet habe, aber dafür habe ich eines verinnerlicht:
Einschränkungen betreffen uns alle. Manchen mehr, manchen weniger.
Aber jeder ist zu irgendeinem Zeitpunkt in seinem Leben auf eine Weise eingeschränkt und es liegt an uns als Entwickler* und letzlich als Mitmenschen, die Hürde für diesen Zeitpunkt möglichst klein zu machen und zu halten.

Fazit

Wie auch im Vorjahr hat mich die EnterJS nicht enttäuscht. ☺️
Teilweise hat sie mich sogar richtig begeistert! 😍

Das ist allerdings nicht zuletzt der großartigen Organisation und Service zu verdanken.
Aber auch echt vielen der großartigen Teilnehmern*.
Ich kann mich nicht erinnern, wann ich das letzte Mal einen so qualitativ guten, fachlichen Austausch mit so vielen verschiedenen Personen hatte, wie dieses Jahr auf der EnterJS!

Vielen Dank an alle, die diese Tage so großartig gemacht haben! ❤️
Und wer weiß, vielleicht sieht man sich nächstes Jahr (wieder) dort^^ 😉☺️

Eine Folie mit einer Person, die von Herzen umgeben ist und den rechten Arm als "Kraftsymbol" in die Luft hält.

Spread the Love 💕

Quelle: Simona Cotin