Die enterJS 2017 in Darmstadt - Recap und Zusammenfassung

Vom 20. bis 23. Juni 2017 haben wir die enterJS in Darmstadt besucht. Wir hatten so die Gelegenheit, einige sehr interessante Voträge zum Thema JavaScript zu hören und uns über die neuesten Entwicklungen zu informieren.

Wir haben hier die für uns interessantesten Vorträge kurz zusammengefasst.

Keynote: ECMAScript of the Future: ES2017 & Beyond

Brian Terlson (Microsoft)

Brian Terlson hat in seiner Keynote einen Überblick über die Entwicklung der Sprache JavaScript und der damit verbundenen Probleme gegeben. Es gab einen kleinen Ausblick, auf welche Features wir uns bald freuen dürfen und wie das ECMA TC39 Comittee die Sprache JavaScript zukünftig gestalten wird.

Die wichtigsten Punkte:

  • Das ECMA TC39 Comittee hat sich selbst dazu verpflichtet, jedes Jahr einen neuen Standard zu veröffentlichen.
  • Wer an der Sprache mitarbeiten möchte ist dazu eingeladen, auf GitHub Proposals einzureichen, zu diskutieren und auch an der Implementierung mitzuarbeiten.
  • Ein guter Einstiegspunkt ist die offizielle ECMAScript Test Suite, die von allen JavaScript Engines zur Validierung genutzt wird.
  • It's all about the domain - Erfahrungen aus 10 Jahren Domain Driven Design

    Carola Lilienthal (Workplace Solutions)

    Carola Lilienthal beschreibt den Wandel von generischen, technisch orientierten Architekturen zu domaingetriebenen Architekturen. Im Fokus steht in der modernen Softwareentwicklung nicht mehr das große, generische und vereinheitlichte Modell sondern eine kontext- und fachorientierte Architektur der Software. Ziel ist das Bilden von Kerndomänen und Subdomänen, um Abhängigkeiten zu reduzieren und eine möglichst optimale Implementierung für die jeweilige fachliche Domäne zu erreichen.

    Die wichtigsten Punkte:

  • Durch die Aufspaltung der Software nach Domänen lässt sich komplexe Software in fachliche Bereiche teilen, die von einzelnen Teams relativ unabhängig voneinander bearbeitet werden können.
  • Jede fachliche Domäne erhält eine Software, die auf die jeweilige Aufgabe optimiert ist.
  • Abhängigkeiten in der Software werden reduziert, die Wartung wird somit vereinfacht.
  • Deployments können für jede Domäne einzeln vorgenommen werden. Große Releases entfallen.
  • Node.js in ressourcenbeschränkten Embedded-Linux-Umbgebungen

    Josef Holzmayr (R-S-I Elektrotechnik)

    Josef Holzmayr bietet in seinem Vortrag einige sehr interessante Einblicke in die Probleme bei der Entwicklung von Embedded Software. Schwerpunkt ist die Frage, wann es sinnvoll ist, Node.js in ressourcenbeschränkten Systemen einzusetzen. Mit Hilfe von anschaulichen Beispielen zeigt er wesentliche Kriterien auf, die bei der Entscheidung berücksichtigt werden sollten.

    Die wichtigsten Punkte:

  • Entscheidend ist die Kosten-/Nutzenrelation durch den Einsatz von Node.js, da die Node-Runtime höhere Anforderungen an die Hardware mit sich bringt. Den eventuellen Einsparungen bei den Entwicklungskosten müssen folglich die Mehrkosten bei der Produktion und Wartung der Hardware gegenübergestellt werden.
  • Der Lebenszyklus eines Embedded Systems unterscheidet sich von dem eines Servers. Nachträgliche “Over-the-Air” Updates sind nicht möglich, die Software muss bei der Produktion auf das System geflashed werden. Auch hier ist die Zeitdauer der Installation bei großen Stückzahlen ein wesentlicher Kostenfaktor.
  • Die Boot-Zeiten der Embedded Systeme verlängern sich durch den Einsatz von Node.js enorm, teilweise fast um Minuten. Ist die Node-Anwendung aber einmal gebootet, läuft sie auch auf ressourcenarmen Systemen schnell mit Response-Zeiten im Millisekunden-Bereich.
  • Sinnvoll ist der Einsatz von Node.js, um die Programmierung von CGI zum umgehen und stattdessen mit express.js über eine API zu implementieren. Serverseitiges Rendering sollte möglichst vermieden werden. Generell sollten alle ressourcenfressenden Funktionen ausgelagert werden (Browser, Build, OpenEmbedded, C/C++).
  • Effizient ist auch die Nutzung von socket.io auf Embedded Devices. In Kombination mit Broadcast ist so ein (Fast-)Echtzeit Datentransport vom Device zum Client möglich.
  • Pack Wars. JS distribution in a galaxy far, far away

    Opher Vishnia (Interlude)

    Die Möglichkeiten, JavaScript zu bundlen sind recht vielfältig. Opher Vishnia beschreibt mit witzigen und anschaulichen Star Wars Analogien die Gründe für die Notwendigkeit von JavaScript Bundling. Er geht auf die bekannten JavaScript Bundler Browserify, RequireJS, Webpack, SystemJS ein und zeigt sehr anschaulich die jeweiligen Vor- und Nachteile der Tools auf.

    Die wichtigsten Punkte:

  • Packaging ist bei komplexen JavaScript Applikationen praktisch eine Notwendigkeit, um den Nutzer nicht mit lästigen Ladezeiten durch das separate Laden von HTML, CSS und JavaScript Snippets zu frustrieren.
  • Packaging hilft dabei, den Code und seine Abhängigkeiten besser zu strukturieren.
  • Der globale Namespace wird entlastet.
  • Packaging ermöglicht die Nutzung von Backend Code und Backend-Modulen im Frontend, wenn CommonJS vom Bundler unterstützt wird.