enterJS Darmstadt 2018 - Eine Zusammenfassung weiterer Talks

Übersicht

• Battle of the Frameworks
• JavaScript-Security: Webbrowser in Gefahr
• Vue.js on Steroids
• JavaScript-Essentials: Die Engine
• Aurelia – mehr Standards, weniger Framework

Battle of the Frameworks

Lora Vardarova, Zalando GmbH

Von Angular, React und Vue hat jeder, der sich für Javascript interessiert, zumindest schon einmal gehört – doch gerade, wer am Anfang seiner Karriere als JavaScript-Entwickler steht, fragt sich vermutlich: für welches dieser Frameworks, die alle mehr oder minder den gleichen Zweck erfüllen, sollte man sich entscheiden? Welches Framework ist das beste?

Überblick

Der Vortrag beginnt nach einer kurzen Einführung mit einer Geschichtsstunde, die Aufschluss über die Entstehung der heutigen Framework-Landschaft bietet und unter anderem aufzeigt, warum Angular nicht Angular.js ist.

Beim Vergleich der Features stellt sich heraus, dass sich alle drei behandelten Frameworks sehr ähnlich sind, und über unterschiedliche Konzepte nahezu dieselben Features umsetzen.

Entscheidungsfindung

Die Erfahrungen bei Zalando haben in den letzten Jahren verschiedene Wege und Irrwege aufgetan, wie die Entscheidung für ein Framework angegangen werden kann.

Dabei hat sich unter anderem herausgestellt, dass die beliebte Methode, mit allen infragekommenden Frameworks eine To-Do-App zu implementieren, in der Regel für eine qualifizierte Entscheidung nicht ausreicht, da eine To-Do-App schlicht zu simpel ist um die Stärken und Schwächen des Frameworks zu erfahren. Stattdessen empfiehlt Vardarova die Implementiertung einer progressive Web App, die als Reader-Client für die Hackernews von YCombinator fungiert.

Außerdem zeige die Erfahrung, dass zu den wichtigsten Faktoren die Community und die Dokumentation zählen.

Projektleiter und Teams können sich am Bus-Faktor orientieren: Wenn der Hauptentwickler des Projekts vom Bus überfahren wird, wie schnell kann ein guter Ersatz gefunden werden?

Die Entscheidung, welches Framework eingesetzt wird, treffen die Zalando-Entwickler pro Projekt, denn jedes Projekt hat seine eigene Roadmap und eigene Bedürfnisse, die in der Entscheidung berücksichtigt werden sollten. Dennoch sei es wichtig, sich eine Deadline zu setzen, da sonst die „decision trap“ zuschlage und die Entscheidung wichtige Entwicklungszeit koste.

And the winner is...

Die Frage, welches Framework das beste ist, wird explizit nicht beantwortet, sondern durch eine andere Fragestellung ersetzt: Welches Framework ist das passendste für mein Projekt?

Mir als Neuling in der JavaScript-Welt, der sich noch nicht auf ein Framework festgelegt hat, hat dieser Vortrag aufgezeigt, dass ich das eventuell gar nicht muss. Es war beruhigend, festzustellen, dass man selbst nach Festlegung auf ein Framework keine technologischen Sensationen verpasst, da alle Frameworks alle populären Features auf verschiedene Weisen umsetzen.

JavaScript-Security: Webbrowser in Gefahr

Joshua Tiago, Cirosec

Cross-Site-Scripting(XSS)-Lücken sind die am weitesten verbreiteten, aber gleichzeitig auch die am trivialsten auszunutzenden Sicherheitslücken im Internet. Da das nicht die beste Kombination für ein sicheres Internet ist, leistet Tiago mit diesem Vortrag seinen Beitrag im Kampf gegen die Sicherheitslücke, über die jeder bereits alles zu wissen glaubt.

Cross-Site-Scripting

Nach einer Zusammenfassung über die Relevanz von Cross-Site-Scripting frischt Tiago noch einmal die Grundlagen auf:

Der Angreifer schleust fremden Code in eine Webanwendung (z. B. durch einen manipulierten Link zu einer Website, die URL-Variablen ungeprüft im Seitentext ausgibt oder einen javscripthaltigen Forenbeitrag), die dann in einem fremden Browser ausgeführt wird.

Die Voraussetzungen, eine XSS-Lücke auszunutzen, sind allgemein, dass eine Anwendung Eingaben entgegennimmt und später wieder ausgibt, und dabei weder bei der Eingabe, noch bei der Ausgabe Steuerzeichen filtert (keine Eingabefilterung und keine Ausgabekodierung). Die typischen Fälle von Ein- und Ausgaben sind dabei Suchfelder, Online-Formulare und Gästebücher bzw. Foren, aber auch auf weniger offensichtliche Ein-/Ausgabemöglichkeiten wie der Header der HTTP-Anfrage sowie der Inhalt hochgeladener Dateien müssen unbedingt beachtet werden, wenn eine Anfälligkeit für Cross-Site-Scripting vermieden werden soll.

Eingabefilterung und Ausgabekodierung illustriert der Vortrag an zahlreichen Beispielen: So codiert Wikipedia die Ausgabe von Sucheingaben, was die Interpretation von JavaScript-Code darin durch den Browser verhindert.

Persistentes und nicht-persistentes Cross-Site-Scripting

Bei nicht-persistenten XSS-Angriffen (reflected XSS) bringt der Anwender einen Nutzer dazu, die Webanwendung auf eine bestimmte Art und Weise zu benutzen, damit der Schadcode ausgeführt wird. Dafür lässt er den Nutzer beispielsweise einen bestimmten Link anklicken, der eine Eingabe mit Code enthält, die später in der Oberfläche der Anwendung ausgegeben wird. Diese Art von Angriff verändert die Webanwendung selbst nicht und funktioniert nur, wenn der Nutzer die Seite auf die vom Angreifer geplante Art nutzt. Der Nutzer schickt den Schadcode dabei selbst in seiner Anfrage mit.

Persistente XSS-Angriffe (stored XSS) hingegen betten sich im Backend der Anwendung ein und funktionieren auch bei ganz normalen Seitenaufrufen. Sie sind danach dauerhaft in der Anwendung enthalten und betreffen alle Seitenbesucher. Ermöglicht werden solche Angriffe z. B. durch Foren oder Gästebücher.

DOM-basiertes Coss-Site-Scripting

DOM-basiertes XSS ist eine Form des Cross-Site-Scriptings, bei welcher der Schadcode nicht über den Server übertragen wird, sondern der gesamte Angriff im Browser-DOM des Nutzers stattfindet. Dadurch können serverseitige Schutzmechanismen und Filter nicht schützen. Möglich wird DOM-basiertes XSS unter anderem durch Teile der URL, die nicht an den Server geschickt werden (alles nach einem #) und die Verwendung unsicherer JavaScript-Funktionen. Wenn Daten ungeprüft von Objekten wie

• document.location

• document.URL

• document.referrer

übernommen werden, und von den Funktionen

• document.write

• document.writeln

verarbeitet werden, ist DOM-basiertes XSS möglich.

Das führt Tiago an einem Beispiel vor, in dem er einen Namen als URL-Parameter entgegennimmt und auf der Seite ausgibt. Ersetzt er den Namen in der URL durch JavaScript-Code, kann er die Seite dazu bringen, ein JavaScript-Alert-Fenster mit der Message „HACKED!!!“ auszugeben.

Um DOM-basiertes XSS zu verhindern, müssen Ausgaben also auch clientseitig codiert werden. Möglich ist das z. B. durch die Bibliothek OWASP ESAPI, die dafür zwei einfache Funktionen zur Verfügung stellt:

$ESAPI.encoder().encodeForHTML( myinput );

$ESAPI.encoder().encodeForJavaScript( myinput );

Neue Techniken, neue Angriffsmöglichkeiten

Die zahlreichen Techniken, die HTML5 mit sich brachte, machten nicht nur das Web schöner und flexibler, sondern auch die Angriffsmöglichkeiten. Diese Features ermöglichen unter anderem den Aufbau von Botnetzen, das persistieren von Schadcode auf dem Client und Angriffe auf die Privatsphäre der Nutzer.

Persistieren von Schadcode

Das Persistieren von Schadcode auf dem Client ist dabei mit allen vorgestellten XSS-Arten möglich (persistent, reflected und DOM-based XSS). Während der Schadcode beim persistent XSS ohnehin schon auf dem Server persistiert ist, kann er bei den anderen XSS-Arten im Application Cache bzw. im Local Storage des Nutzers gespeichert werden. Das macht die Erkennung durch den Server schwer bis unmöglich.

Um den persistenten Code loszuwerden, müssen Web-Cache und Web-Storage komplett gelöscht werden. Der Browser kann danach allerdings sofort wieder infiziert werden, wenn der Schadcode noch in einem anderen Tab oder Fenster läuft.

Der Aufbau von Botnetzen

JavaScript kann Requests aller Art senden, und wenn das JavaScript persistiert ist, lassen sich damit sehr leicht Botnetze aufbauen. Das liegt unter anderem daran, dass inzwischen einige Botnetzframeworks entstanden sind – vergleichbar mit den bekannten App-Frameworks fürs Frontend. Nur eben für Botnetze. Tiago stellt als Beispiel BeEF vor, das eine übersichtliche Weboberfläche zum Dirigieren verschiedenster Botnetz-Funktionen bietet.

SVG-Grafiken

SVG-Grafiken können ebenfalls JavaScript-Code enthalten. Wenn sie über den <svg>-Tag eingebunden sind, wird dieser einfach ausgeführt. Deswegen sollte man zum Einbinden von Grafiken immer den <img>-Tag benutzen – dieser führt keinen Code aus.

Schutzmaßnahmen

Als Schutzmaßnahme schlägt Tiago Content Security Policies vor. Diese können im Webserver konfiguriert werden.

Da XSS-Angriffe meistens über Inline-Skripte in den Ausgaben von Webanwendungen funktionieren, können Content Security Policies grundsätzlich jegliche inline-Skripte verbieten. Darüber hinaus ist es möglich, das Einbinden von Skripten, Grafiken und Videos nur aus bestimmten Quellen zu erlauben. Auch XMLHttpRequests und andere Requests können durch Content Security Policies eingeschränkt werden.

Level-2-Content-Securitiy-Policies können Skripte sogar mittels eines Hashs absichern, der verifiziert, dass das Skript echt ist. Alternativ zum Hash kann, sofern das Skript vom selben Server wie die Webapplikation ausgeliefert wird, ein vom Server generierter Zufalls-Wert, der sogenannte Nonce, das Skript absichern. Dieser wird vom Server sowohl im Skript, als auch im Script-Tag eingefügt und kann von einem Angreifer nicht vorhergesagt werden.

Content Security Policies werden von allen verbreiteten Browsern akzeptiert und sollten daher eingesetzt werden.

JavaScript-Security Top 3

Zum Abschluss stellt Tiago die drei wichtigsten Punkte dar, die JavaScript-Entwickler aus seiner Sicht zum Thema beachten sollten:

1. Der Client/Browser ist immer als unsicher zu betrachten – es ist immer davon auszugehen, dass er bereits kompromittiert wurde, weswegen alle kritischen Funktionen serverseitig validiert werden müssen

2. XSS ist mit allen Maßnahmen um jeden Preis zu verhindern: Eingaben müssen immer validiert, Ausgaben kodiert, Content Security Policy aktiviert werden

3. JavaScript-Bibliotheken müssen immer aktuell gehalten werden

Wertvolles Wissen über Sicherheit – JavaScript-unabhängig

Das Thema XSS-Sicherheitslücken kommt immer wieder auf, ich kannte das Prinzip und wählte diesen Vortrag nur „zur Sicherheit“, um als angehender JavaScript-Entwickler alles richtig zu machen. Dass das Thema so groß ist, welche Techniken alles zweckentfremdet werden können und dass es gar Frameworks gibt, um über XSS Botnetze aufzubauen, hätte ich hingegen nicht gedacht, weswegen ich sehr dankbar bin, diesen Vortrag gehört haben zu können. Das Wissen über die unterschiedlichen Angriffsszenarien wird mir unter allen Programmiersprachen und auch in der Backend-Entwicklung zugute kommen und mir helfen, sicherere Anwendungen zu entwickeln – ich hoffe, den anderen Hörern des Vortrags und den Lesern dieses Blogbeitrags geht es genauso.

Vue.js on Steroids

Christian Hunger und David Müller, eXXcellent

Vue.js gehört zu den beliebtesten drei JavaScript-Fameworks, was sich unter anderem auch in der Anzahl an Vorträgen auf der enterJS zu dem Thema widerspiegelt. In der Praxis wird vue.js allerdings selten alleine eingesetzt – vue.js on Steroids bietet am Beispiel eines fiktiven Supplements-Stores für Web-Developer Überblick über ein vue.js-Ökosystem mit den „Steroids“ nuxt.js, Vuetify, Vue-rx, Vuex und Jest.

Die Entwicklertools

Als Entwicklertools werden das Vue.js-CLI und das Devtools-Plugin für Browser vorgestellt. Beide werden am Beispiel des Supplement-Stores vorgeführt.

So erstellen die Vortragenden das Projekt über das CLI mit dem Nuxt&Vuetify-Template. Ohne Template erstellt das CLI über den Befehl vue create app eine nackte vue-App, das Template hingegen erstellt eine wesentlich umfangreichere Ordnerstruktur, die für die Verwendung mit vuetify.js und nuxt.js ausgelegt ist.

Die Devtools erweitern die Chrome-Entwicklertools um einen Vue-Tab, der tiefe Eingriffe in den Status der vue-Anwendung erlaubt wie das zurücksetzen von Mutations. Mutations sind Commits von States, die den jeweiligen Status der Anwendung repräsentieren, ein System, das von Vuex bereitgestellt wird.

State-Managment mit Vuex

Das State-Managment-Framework Vuex wird auch gleich als nächstes Steroid vorsgetellt. Wer Redux kennt, wird sich hier gleich zuhause fühlen, denn Vuex implementiert genau wie dieses das Flux-Pattern.

Ein State-Managment-Framework bietet allen Komponenten die Möglichkeit, ihren State an einer zentralen Stelle, dem sogenannten Store, zu verändern, und stellt somit einen zentralen Punkt für den Zustand der gesamten Anwendung bereit.

Das verändern des States findet über sogenannte Actions statt. Diese definieren eine Veränderung, ohne diese aber durchzuführen. Dadurch können sie auch asynchrone Abläufe beschreiben. Die tatsächlichen Veränderungen am State hingegen werden über Mutations durchgeführt.

Um auf den Store zuzugreifen, stellt Vuex Getter bereit. Diese bereiten Daten z. B. für die GUI auf und bieten eine logische Sicht auf den Store. Im Zusammenspiel mit Computed Properties lassen sich Getter einfach in eine UI-Komponente einhängen.

Nuxt: Server-Side-Rendering und mehr

Nuxt.js ermöglicht Prerendering, Server Side Rendering und vereinfacht das Routing. Vuex wird durch Nuxt bereits mitgebracht. Nuxt lässt sich in drei Production Modes betreiben:

Single Page Application

Die Single Page Application ist eine ganz normale Single Page Application, die clientseitiges Routing umsetzt und Inhalte per API-Aufruf vom Server nachlädt.

SPA mit Server Side Rendering

Beim Server Side Rendering wird das JavaScript und die Dom-Manipulation bereits vom Server ausgeführt, damit das fertig gerenderte HTML an den Client verschickt werden kann. Auch der Vuex-Store wird bereits vom Server gefüllt und an den Client übertragen. Das Nachladen von Inhalten entfällt, dadurch kann die Seite schneller geladen werden und ist außerdem suchmaschinenfreundlicher (wichtig für SEO). Außerdem ist zumindest beim ersten Seitenaufruf kein JavaScript auf dem Client notwendig.

Prerendered SPA

Statische Seiten kann man sich auch prerendern lassen – wer bspw. einen Blog betreibt, muss die Inhalte nicht bei jedem Seitenaufruf vom Server rendern lassen, sondern kann mit nuxt generate statisches HTML für jede Route generieren. Daher wird dieser Modus im Vortrag auch „Server Side Rendering Light“ genannt.

Alle Dinge, die Nuxt kann, lassen sich auch mit reinem vue.js umsetzen – Nuxt vereinfacht die Dinge aber.

Vue-rx

Vue-rx ist eine Umsetzung von ReactiveX für vue. ReactiveX bietet verbesserte Promises, die komlexe asynchrone Abläufe modellieren können, und versucht dabei das beste aus dem Observer-Pattern, dem Iterator-Pattern und funktionalem Programmieren zu vereinen.

Wer komplexe DOM-Events, Websockets oder Animationen umsetzen will, und wem Promises nicht ausreichen, sollte sich auf jeden Fall einmal mit dem ReactiveX-Konzept befassen.

Schnell UIs zaubern mit Komponentenbibliotheken

Slider, Text-Inputs, Buttons – die meisten GUIs bestehen seit der ersten Smalltalk-Entwicklungsumgebung aus denselben Elementen. Nur dass diese heutzutage geräteübergreifend funktionieren und sowohl mit Maus- als auch Touch-Eingaben zurechtkommen müssen.

Um diese Standard-Komponenten nicht jedes Mal neu schreiben zu müssen, empfiehlt sich der Einsatz von Komponentenbibliotheken – diese bieten einem sämtliche GUI-Elemente, von Slideshows, Tabellen, Radiobuttons bishin zu ganzen Dialogen und Bestellabläufen als Komponenten an.

Wer vor hat, mit vue.js eine Webanwendung zu bauen, sollte sich auf jeden Fall die beiden vorgestellten Komponentenbibliotheken, Vuetify und Buefy, anschauen.

Jest

Unabhängig von Vue.js ist es immer wichtig, Tests zu schreiben – auch für Frontender. Daher wird als letztes Steroid mit Jest das führende JavaScript-Testing-Framework vorgestellt. Jest rühmt sich damit, weitestgehend ohne Konfiguration zu funktionieren. Über die expect-Funktion, die das zu erwartende Test-Ergebnis definieren lässt, kann man so ohne große Lernkurve alle möglichen Arten von Tests schreiben.

Viel zu lernen du noch hast

Dieser Vortrag hat mir wieder einmal gezeigt, wie viel größer als ich dachte die JavaScript-Welt doch ist, und welches Potential in JavaScript-Frameworks steckt. Die meisten der vorgestellten Steroide sind so oder in ähnlicher Form nicht nur für Vue.js verfügbar, von daher werde ich mich auch in der Entwicklung mit anderen Frameworks mit interessanten Konzepten wie State-Managment oder ReactiveX beschäftigen.

JavaScript-Essentials: Die Engine

Rainer Hahnekamp

JavaScript wird zur Laufzeit ausgeführt, und wie jede zur Laufzeit ausgeführte Sprache braucht sie eine Engine. Zu wissen, wie die Engine funktioniert, ist Macht, denn nur so kann man effektiv seinen Code optimieren. Mit viel Live-Coding zeigt Hahnekamp, wie man die Engine für seine Zwecke nutzt.

JavaScript, die lahme Ente

JavaScript eilt ein Ruf voraus. Dieser setzt die Programmiersprache nicht unbedingt mit schnellen Ausführungsgeschwindigkeiten in Verbindung. Inzwischen setzen aber ganze Industriezweige auf die Entwicklung mit JavaScript, mit Node.js gibt es sogar einen als schnell geltenden JavaScript-Server, JavaScript läuft auf embedded devices. Benchmarks zeigen, dass JavaScript die Konkurrenz unter Umständen abhängt. Doch die Erfahrungen jedes passionierten Internetnutzers können bezeugen, dass es noch heute langsamen JavaScript-Code gibt, und wie kann JavaScript überhaupt schnell sein, wenn es doch zur Laufzeit interpretiert wird?

Hahnekamp schreibt ein Programm, das für vier verschiedene Star-Wars-Charaktere Objekte erzeugt, in denen jeweils der Name gespeichert ist. Um die Geschwindigkeit zu messen, iteriert er mehrere zehntausend Mal über die Objekte. Es dauert etwas mehr als zwei Sekunden. Fügt er jedoch einem Objekt eine Eigenschaft hinzu, die die anderen nicht besitzen, dauert das Iterieren über sieben Sekunden – wenn noch mehr Eigenschaften, wie Beruf (nur für Han Solo), Nachname (bei Yoda nicht bekannt) hinzugefügt werden, steigt die Zeit auf knapp 10 Sekunden an.

Optimierte Ausführung mit aktuellen Engines

Um dieses Phänomen zu erklären, führt Hahnekamp in die Geschichte von JavaScript ein: Früher war JavaScript nämlich wirklich sehr lahm und nur für einfach Funktionen in Websites gedacht. Erst mit Googles V8-Engine im Jahr 2008 wurde das Ausführen von JavaScript so weit optimiert, dass damit komplexe Webanwendungen möglich waren.

Dafür werden Teile des Codes vor der Ausführung im Hintergrund vorkompiliert. Gleichzeitig wird der schwach typisierte JavaScript-Code vor der Ausführung intern hart typisiert. Dafür erkennt die Engine in jedem Objekt ein Object Shape und teilt ihm eine Hidden Class zu. Wenn also mehrere Objekte dieselben Properties in der selben Reihenfolge besitzen, erstellt die Engine dafür heimlich eine Hidden Class. Dadurch weiß sie bei Iterationen direkt, wo die Properties im Speicher liegen und muss nicht immer erst die Speicheradresse ausrechnen.

Zurück zum Live-Coding-Beispiel

Hahnekamp ergänzt seine Star-Wars-Charaktere um die fehlenden Properties der anderen, und füllt diese einfach mit null auf. Die Iterationen dauern trotz gestiegener Anzahl der Properties keine drei Sekunden. Wer also gut aufpasst, kann durch das entsprechende Setzen von Properties ordentlich die Performance optimieren. Die gleichen Regeln gelten auch für Sprachen wie TypeScript, wie Hahnekamp referiert, da TypeScript später auch von der selben Engine ausgeführt wird – in den meisten Fällen sollte die Optimierung hier aber ohnehin greifen, da TypeScript eine harte Typisierung erzwingt.

Smarte Engines erfordern smarte Coder

Ich persönlich bin kein Freund davon, wenn eine Programmiersprache so smart ist, dass der Programmierer mindestens genau so smart sein muss, um zu verstehen, was sein Code eigentlich genau macht. Da JavaScript im Web aber einfach alternativlos ist, bin ich sehr froh, nun zu wissen, wie heutige Engines Objektzugriffe optimieren, da Perfomance gerade im Web mit seinen unterschiedlichen Endgeräten von entscheidender Bedeutung ist. Vor allem bin ich auch glücklich über die ansprechende Gestaltung des Talks mit den anschaulichen Live-Coding-Beispielen.

Aurelia – mehr Standards, weniger Framework

Katharina Bähr, Zühlke GmbH

Während es in den meisten Talks nur um die drei großen Frameworks Angular, React und Vue.js kreisen, hat sich Katharina Bähr mit ihrem Entwickler-Team für das Aurelia-Framework entschieden, das sich durch Konformität mit den allgemeinen Standards von JavaScript und TypeScript auszeichnet.

Todo-App

Todo-Apps sind nach Cookie-Hinweisen vermutlich der zweithäufigste Verwendungszweck von JavaScript. Daher bietet sich das Schreiben einer Todo-App als Einstieg in ein Framework ziemlich gut an.

Bähr führt mit einer gut abgestimmten Mischung aus Live-Coding und vorbereiteten Git-Commits durch die Todo-App. Aurelia fällt dabei vor allem dadurch auf, dass man es nicht bemerkt – der entstehende TypeScript-Code enthält kaum Hinweise darauf, dass ein Framework genutzt wird. Lediglich die Klasse main.ts implementiert eine configure-Funktion, der ein Aurelia-Objekt injiziert wird.

Generell ist der Konfigurationsaufwand bei Aurelia aber sehr klein, weil das Framework konventionenbasiert funktioniert. Wenn man sich an das vorgegebene Namensschema hält (das bei Bedarf natürlich konfigurierbar ist), wirkt das Projekt wie reiner TypeScript-Code. Wenn man bereits selbiges oder ES Next beherrscht, sollte Aurelia einen sehr einfachen Einstieg ermöglichen, da nicht viel gelernt werden muss.

Alle Features vorhanden

Aurelia kann trotzdem so ziemlich alles, was die bekannteren Konkurrenten können – Bähr selbst entwickelte bei Zühlke zunächst mit Angular.js, vor Erscheinen von Angular2 entschied sich das dortige Entwicklerteam aber für den Umstieg auf Aurelia. Inzwischen entwickelt sie Web-Apps nahezu ausschließlich mit Aurelia und ist von dem Framework sichtlich begeistert.

Die Community sei zwar nicht so groß, aber mindestens genauso hilfreich wie bei Angular. Das Projekt sei gut dokumentiert, die Erweiterungen zwar nicht so zahlreich, aber dafür umso häufiger vom Aurelia-Team selbst, was sich in Qualität, Dokumentation und Support positiv niederschlage.

Aurelia wird nicht von einem großen Internet-Konzern wie Google oder Facebook entwickelt. Statt dessen verdient Bluespire, das Unternehmen, das Aurelia ins Leben gerufen hat, sein Geld mit Support-Leistungen rund um das Framework. Dadurch hängt laut Bähr das wirtschaftliche Interesse stärker von den Bedürfnissen aller Nutzer ab, während die Entwicklung der anderen Frameworks von der Bedeutung dieser für die Technik-Plattformen der entwickelnden Unternehmen abhinge.

Aurelia ist freundlich

Die vorgestellten Eigenschaften des Aurelia-Frameworks gefallen mir sehr. Das Prinzip Convention over Configuartion kenne ich durch meinen Backend-Hintergrund aus der Entwicklung mit dem PHP-Framework Symfony, wo es den Code stark vereinfacht und gut strukturiert. Vor allem das Einsteigen in ein neues, unbekanntes Projekt wird meiner Erfahrung nach durch gute Konventionen stark vereinfacht und löst viele Probleme beim Verständnis des Codes.

Bähr stellt Aurelia dabei so überzeugend und sympathisch dar, dass ich direkt am nächsten Tag anfing, meine erste Aurelia-App zu schreiben. Dabei musste ich kaum etwas über Aurelia lernen, für mich war das eher ein TypeScript-Tutorial.

Auch Symfony wird durch ein Unternehmen entwickelt, das wirtschaftlich vor allem von Support und Schulung rund um ebendieses abhängt. Bei Symfony hat dieser Umstand zu einer sehr entwicklerfreundlichen Frameworkentwicklung geführt, was es mir plausibel erscheinen lässt, dass sich Bluespire ähnlich gut um die Belange der Entwickler kümmert.

Ein gewisses Kümmern um die Entwickler zeigt sich auch in der Öffentlichkeitsarbeit von Bluespire: nach dem Vortrag erfuhr ich im Gespräch mit Bähr von einem Paket mit Aurelia-Stickern, die das Aurelia-Team ihr zuschickte, nachdem sie auf ihren Blog gestoßen sind, der sich u. a. mit der Aurelia-Entwicklung beschäftigt.

Ich werde mir Aurelia weiter anschauen, und kann jedem, der auf der Suche nach dem richtigen Framework für sich ist oder einfach ein neues Framework ausprobieren möchte empfehlen, das gleiche zu tun.

Die enterJS als Perspektivwandel