Die Wahl der “richtigen” JavaScript-Bibliothek

Gastbeitrag von | 20.12.2018

“Was ist die richtige JavaScript-Bibliothek bzw. das richtige JavaScript-Framework für uns?” Immer wieder wird mir diese Frage gestellt, und natürlich gibt es angesichts der Vielzahl der verfügbaren Möglichkeiten keine allgemeingültige, “richtige” Antwort darauf. Meiner Meinung nach sollte man einfach “das passende Werkzeug für die Aufgabe” verwenden, zumindest ist das meistens meine Aussage, wenn ich in Unternehmen Schulungen durchführe oder Architektur- bzw. Beratungsleistungen erbringe. Natürlich habe ich meine Technologiepräferenzen, aber es wäre naiv und kurzsichtig, sie einem Unternehmen, mit dem ich arbeite, aufzuzwingen. Wenn es eine Sache gibt, die ich in den letzten 20 Jahren gelernt habe, dann ist es, dass “one size fits all” weder in der Technik noch im Leben allgemein stimmt. Die Welt ist schlicht viel zu vielfältig. Gerne denken wir zwar, dass unser Weg der “richtige” sei (und ich schließe mich explizit damit ein) , aber diese Sichtweise ist sehr subjektiv und beschränkt auf das, was uns gefällt oder nicht gefällt, was wir wissen und was wir gerne benutzen, unsere persönlichen Erfahrungen, die Art der Anwendungen, die wir erstellen, sowie vieler anderer Faktoren.

Wenn es um JavaScript-Bibliotheken/Frameworks geht, dann ist es kein Geheimnis, dass ich ein Fan von Angular bin und seit vielen Jahren auf die AngularJS-Tage zurückblicke. Ich habe gesehen, dass beide Versionen sehr erfolgreich in kleinen und großen Unternehmen eingesetzt werden. Allerdings möchte ich mich in diesem Beitrag nicht auf Angular konzentrieren. Tatsächlich mag ich auch andere Optionen (Vue.js ist eine, die mir zum Beispiel wirklich gefällt) und verwende sie in Anwendungen meines Unternehmens und bei unseren Kunden. Wie erwähnt, glaube ich nicht an “one size fits all”, und daher versuche ich auch, immer das richtige Werkzeug für die Aufgabe – oder man könnte auch sagen, das richtige Tool für die richtige App – zu finden.

Vor etwa einem Jahr mussten wir beispielsweise eine kleine datenzentrierte Anwendung entwickeln, die dynamisch Controls basierend auf hierarchischen No-SQL-Daten rendert und die bearbeiteten Daten zur Verarbeitung an den Server zurückschickt. Wir begannen mit einem Framework und stellten bald fest, dass es für das Geschäftsproblem einen Overkill darstellte. Wir brauchten eine JavaScript-Bibliothek für Data Binding, nicht mehr, nicht weniger. Natürlich hätten wir mit React, Angular, Vue.js oder einer anderen ähnlichen Option arbeiten können, aber wir haben uns für Knockout.js entschieden (wir waren damit bereits sehr vertraut), weil es genau die Funktionalität bietet, die wir brauchten. Und genau das meine ich ich mit “dem passenden Tool für die richtige Aufgabe”. Wir arbeiten derzeit mit mehreren Unternehmen zusammen, die große Anwendungen mit vielen Funktionen entwickeln. So etwas wie Knockout.js ist wahrscheinlich nicht das richtige Werkzeug für diese Art von Anwendungen, da neben dem  Data Binding noch einige zusätzliche Funktionen benötigt werden, die andere Bibliotheken/Frameworks standardmäßig bereitstellen.

Sollten Sie also Angular, Vue.js, React oder etwas ähnliches wählen? Viele Teams fühlen sich von der schieren Anzahl der Möglichkeiten überwältigt und haben Angst, die “falsche Wahl” zu treffen. Nachfolgend finden Sie Überlegungen, wie ich eine Entscheidung treffen würde. Ich werde keine bestimmte Bibliothek oder ein bestimmtes Framework empfehlen, aber ich werde einige Schlüsselfragen stellen, die Sie meiner Meinung nach während Ihrer Auswahl beantworten sollten.

Wer interessiert sich für die Hintergründe?

Wenn die Debatte über eine die richtige Bibliothek oder das passende Framework aufkommt, sage ich immer gerne: “Meiner Mutter ist es egal, was du benutzt. Und deine Nutzer interessiert es auch nicht”. Das könnte man über die Mehrheit der Kunden sagen, die eine Anwendung verwenden, die Sie oder ich jemals geschrieben haben. Sie wollen etwas, das funktioniert, ein Geschäftsproblem löst und schnell und einfach zu bedienen ist. Nur sehr wenige Anwendungsbenutzer stöbern herum und fragen: “Hmmm….Ich frage mich, welche Bibliothek Sie verwenden?”. Wenn Sie eine Entscheidung über eine Bibliothek oder ein Framework treffen, denken Sie daran, dass die Anwendung, die Sie schreiben, ein Geschäftsproblem für Kunden und nicht für Sie (in den meisten Fällen zumindest) lösen soll. Wenn Sie persönliche Vorurteile zu Bibliotheken/Frameworks überwinden, werden Sie langfristig sicherlich bessere Entscheidungen treffen. Wir neigen dazu, uns für Konzepte zu interessieren, die wir bereits kennen und die wir gerne benutzen. Doch es ist wichtig, die Bereitschaft zu entwickeln, bei Entscheidungen über unsere “Komfortgrenzen” hinauszugehen. Jede einzelne Bibliothek bzw. jedes Framework, die bzw. das ich im Laufe der Jahre benutzt habe, hat Vor- und Nachteile. Leider neigen wir dazu, die Nachteile von Bibliotheken und Frameworks zu ignorieren, wenn wir sie gerne benutzen.

Als Entwickler tendieren wir manchmal dazu, in unsere eigene kleine Welt einzutauchen und zeitraubende Kämpfe um “wer hat Recht?” zu führen. Wir vergessen oft, dass, solange die Anwendung das tut, was sie tun soll, unsere Kunden sie wahrscheinlich gerne benutzen werden. Stellen wir nicht fest, wenn wir unsere Tätigkeiten herunterbrechen, dass es einfach darum geht, den Geschäftswert zu steigern und die Benutzer glücklich zu machen? Solange eine bestimmte Bibliothek oder ein Framework verwendet werden kann, um eine erfolgreiche Anwendung zu erstellen, spielt die von Ihnen gewählte Bibliothek oder das Framework keine wirkliche Rolle. Es ist Ihrer Mutter egal und Ihren Kunden auch. Natürlich immer vorausgesetzt, dass die Wahl der Bibliothek oder des Frameworks die entsprechend gestellten Geschäfts-, Leistungs- und Wartungsziele erfüllt. Allerdings sollten wir stets im Blick behalten, dass es neben der Zufriedenheit der Benutzer und dem Mehrwert für das Unternehmen weitere wichtige Kriterien für die Entwicklung von Applikationen gibt.

Was macht Sie am produktivsten?

Mit welcher Sprache, Bibliothek und/oder Framework kann Ihr Team am produktivsten arbeiten? Das ist die nächste Frage, die ich gerne stelle. Wenn es JavaScript ist (da dies der Schwerpunkt dieses Beitrags ist), sind Ihre Teammitglieder mit ES5, ES2015, TypeScript, CoffeeScript, Elm oder etwas anderem vertraut? Arbeitet Ihr Team bereits mit Frameworks oder hat es eher einen Skripting-Hintergrund?

Ich bin kein Fan davon, eine “beliebte” Bibliothek zu nutzen, ohne die notwendigen Fähigkeiten zu besitzen, um damit produktiv arbeiten zu können. Das zu tun, führt nach meiner Erfahrung letztendlich zu mehr Problemen als Lösungen, egal wie großartig eine Bibliothek oder ein Framework sein mag. In meinen vielen Trainings habe ich es immer wieder erlebt, dass Manager glauben, wenn sie Mitarbeiter zu einem Training schicken, werden diese hinterher einfach alles wissen, was sie für ihre Arbeit benötigen. Doch dem ist nicht so. Wenn Sie die wichtigsten Aspekte einer Bibliothek oder eines Frameworks nicht kennen, kann dies dazu führen, dass Anwendungen erstellt werden, die nicht auf Best Practices basieren und daher später zu Wartungsproblemen führen. Während ein Team sicherlich auf eine neue Sprache oder eine Bibliothek bzw. ein Framework trainiert werden kann, braucht es Zeit, bis es effizient und produktiv damit umgehen kann.

Ich würde Ihnen eine schrittweise Vorgehensweise empfehlen: Erstellen Sie eine kleine Prototyp-Anwendung mit der Bibliothek oder dem Framework Ihrer Wahl. Sobald der Prototyp erstellt ist, führen Sie eine Teamdiskussion durch und erörtern Sie, wie produktiv sich jeder fühlte. Sammeln Sie Vor- und Nachteile und allgemeine Meinungen der Teammitglieder. Es ist mir egal, ob es sich um Angular, Vue.js, React oder etwas anderes handelt, beginnen Sie mit etwas Kleinem, wenn Sie gerade dabei sind, eine Bibliothek / ein Framework auszuwählen. Nehmen Sie sich die Zeit für einen Proof of Concept. Es lohnt sich.

Wie groß ist der Aufwand für Pflege und Wartung?

Ich habe im Laufe meiner Karriere viel Produktionsunterstützung/Wartung für Anwendungen geleistet und früh erkannt, wie wichtig es ist, Anwendungen zu erstellen, die einfach zu warten sind. Veränderungen sind in der Welt der Technologie unvermeidlich (ja – ich sage das Offensichtliche hier), daher ist es wichtig, sich für eine Bibliothek / ein Framework zu entscheiden, die oder das Ihr Team gerne pflegt. Dazu gehört auch die Bewertung, wie einfach es sein wird, neue Mitarbeiter einzustellen, die mit der gewählten Bibliothek bzw. dem Framework sofort loslegen können, unter Berücksichtigung von Unterauftragnehmern oder Freelancern, sofern Sie mit solchen arbeiten.

Ein paar Fragen zum Thema zur Wartung:

  1. Sind die Entwickler und/oder Supportteams es gewohnt, mit einem Compiler oder einer skriptgesteuerten Sprache zu arbeiten? Oftmals ist es nicht so einfach wie die Wahl einer Bibliothek oder Frameworks; Sie müssen auch die Sprache wählen. Das mag offensichtlich erscheinen (JavaScript), aber es gibt andere Optionen zu berücksichtigen. Es ist wichtig, die zugrunde liegende Sprache zu wählen, die zusammen mit der Bibliothek / einem Framework verwendet wird. Entwickler, die an einen Compiler gewöhnt sind, mögen beispielsweise TypeScript, während JavaScript-Entwickler ohne Erfahrung mit einem Compiler sich mit ES5 oder ES2015 produktiver und komfortabler fühlen können.
  2. Schreibt Ihr Team Unit-Tests, End-to-End-Tests usw.? Bietet die Bibliothek oder das Framework dafür eine gute Unterstützung?
  3. Wie gestaltet sich der Entwicklungsprozess mit der Bibliothek bzw. dem Framework?
  4. Bietet die Bibliothek / das Framework eine Möglichkeit, Code und Features zu organisieren?
  5. Bietet die Bibliothek / das Framework einen allgemein akzeptierten Style Guide oder eine Liste von Best Practices, die Entwickler in einem Team befolgen können, um die Wartung dauerhaft zu erleichtern?

Wartung ist für mich persönlich einer der wichtigsten Faktoren bei der Auswahl einer Bibliothek oder eines Frameworks.

Die Frage nach der Lebensdauer

Bevor ich eine Entscheidung über eine Bibliothek oder Framework treffe, empfehle ich gerne, sich die Zeit zu nehmen, sich das Quellcode-Repository anzusehen. Hier gilt es einige Fragen zu stellen:

  1. Wann wurde die Bibliothek bzw. das Framework zuletzt aktualisiert? Ist es veraltet oder geht es aktiv voran?
  2. Wie geht das Bibliotheks-/Framework-Team mit der Versionierung um und passt diese in die Arbeitsweise Ihres Teams bzw. Ihrer Firma?
  3. Wie robust ist die allgemeine Open-Source-Community für die Bibliothek / das Framework. Aus meiner Sicht ist das eine absolute Schlüsselfrage.
  4. Wie schnell werden Probleme gelöst? Idealerweise sollten sich nicht die Gesamtzahl der offenen Fragen in Foren anschauen, denn Leute neigen dazu, den Bereich “Issues” eines Repositorys zu nutzen, um Fragen zu stellen und Vorschläge für Funktionen zu machen, die keine Probleme darstellen. Also schauen Sie sich an, wie oft Probleme gelöst werden, um ein Gefühl für den Zustand einer bestimmten Bibliothek oder eines Frameworks zu bekommen.
  5. Wie viele Mitwirkende hat die Bibliothek / das Framework?
  6. Wird die Bibliothek / das Framework von einem Vollzeit-Team unterstützt oder von einer Open-Source-Community betrieben? Beides hat Vor- und Nachteile.

Ich wünschte, ich hätte jedes Mal bei der Frage “Wie lange denkst du, wird es die Bibliothek oder das Framework X geben?” einen Dollar erhalten. Natürlich ist es eine wichtige Frage, die uns alle beschäftigt. Es gibt Unternehmen, die können sich nicht den Luxus leisten, ihre Anwendungen ständig zu aktualisieren, weshalb die Teams Angst haben, eine Bibliothek oder ein Framework auszuwählen, die oder das eines Tages verschwinden könnte. Wenn ich nur eine Kristallkugel hätte, um die Zukunft vorherzusagen.

JavaScript-Projekte sind schnelllebig und in der Regel auch “lebendig”. Ich würde empfehlen, eine Bibliothek oder ein Framework auszuwählen, die oder das seit mindestens einem Jahr stabil ist, eine robuste Community hinter sich vereint und regelmäßig aktualisiert wird.

Die Wahl zwischen Bibliothek oder Framework

Sind Sie auf der Suche nach spezifischen Bibliotheksfunktionen (wie z.B. Rendering der Benutzeroberfläche und/oder Data Binding) oder wünschen Sie sich ein vollwertiges Framework, das viele Funktionen sofort einsatzbereit enthält? Bibliotheken zielen in der Regel auf einige sehr spezifische Funktionen ab, während Frameworks eine Vielzahl von Funktionen abdecken.

Wenn Ihr Team bereits ein Framework verwendet (z.B. auf der Serverseite), kann es sinnvoll sein, zu einem JavaScript-Framework zu wechseln, um die Dinge zwischen Client und Server so konsistent wie möglich zu halten. Ziehen Sie es andererseits vor, verschiedene Bibliotheken zusammenzustellen (ähnlich wie die Wahl, was Sie an einem Buffet essen möchten), so dass Sie die Flexibilität haben, verschiedene Funktionen bei Bedarf auszutauschen, dann können eine oder mehrere Bibliotheken das sein, wonach Sie suchen. Wie bei allem gibt es Vor- und Nachteile für beide Ansätze.

Ich war zunächst von AngularJS (und jetzt Angular) angezogen, weil sie eine Framework-Funktionalität bieten. Ich habe einen Java- und.NET-Hintergrund und im Laufe der Jahre viele erfolgreiche Web-Applikationen mit Frameworks veröffentlicht. Ich mag die Konsistenz, die Frameworks typischerweise für Entwickler im Team mit sich bringen. Funktionen wie UI-Rendering, Data Binding, Routing, Formvalidierung, Testing und vieles mehr sind in Frameworks wie Angular out-of-the-box verfügbar.

Bibliotheken wie React und andere können eine Menge Funktionalität bieten, ohne den “Overhead” eines Frameworks. Sie können den Einstieg erleichtern (sicherlich eine sehr subjektive Aussage) und sind je nachdem, welche Funktionalität Ihre Anwendung benötigt, im Allgemeinen leichter anzuwenden. Was ist also besser – eine Bibliothek oder ein Framework? Wenn Sie mit 100 Entwicklern srpechen, werden Sie 100 verschiedene Antworten erhalten. Hier ist mein Blick auf einige der beliebten Bibliotheken und Frameworks da draußen. Das sind sicherlich nicht die einzigen Optionen, aber sie sind die Big Player von heute (meiner Meinung nach jedenfalls). Hier sind 3, die ich persönlich untersucht, direkt bearbeitet oder in Unternehmen genutzt habe, mit denen ich erfolgreich zusammenarbeite.

Vue.js

Vue.js ist ein “progressives JavaScript-Framework” (obwohl ich es immer als Bibliothek betrachtet habe). Mit zusätzlichen Skripten können Sie mit Vue sowohl große als auch kleine Anwendungen erstellen. Neben der einfachen Handhabung ist es auch sehr schnell und lässt sich sehr einfach in Betrieb nehmen. Wenn Sie mit AngularJS (der 1.x-Version) vertraut sind, werden Sie Vue sehr schnell verstehen. Es handelt sich um ein Open-Source-Projekt, das schnell wächst. Es hat eine CLI, die Ihnen hilft, mit Ihrem ersten Projekt zu beginnen: npm install -g vue-cli

React

React ist eine UI-Bibliothek, die viele zusätzliche Funktionen (und Bibliotheken von Drittanbietern) bietet, die hinzugefügt werden können. Es bietet eine hervorragende Performance, ist einfach zu bedienen und sehr beliebt. Ein hauptamtliches Team bei Facebook sowie eine robuste Open-Source-Community unterstützen das Projekt. Eine kleinere Variante von React namens Preact ist ebenfalls verfügbar. Es wird von Facebook verwendet, was ein Bonus ist, wenn es um die Langlebigkeit geht. React stellt eine CLI zur Verfügung, die den Einstieg erleichtert: npm install -g create-react-app

Angular

Wenn Sie ein Framework bevorzugen, dann probieren Sie Angular aus. Es bietet eine Reihe robuster, sofort einsatzbereiter Funktionen, die alle integriert sind. Es bietet auch Ahead-of-Time (AOT)-Kompilierung für Builds und verfügt über eine robuste CLI. Es wird von einem Vollzeit-Team bei Google betrieben und verfügt außerdem über eine robuste Open-Source-Community. Es wird von vielen wichtigen Apps innerhalb von Google verwendet, was ein Bonus ist, wenn es um die Langlebigkeit geht. Beachten Sie, dass, wenn Sie neu sind, “AngularJS” sich auf die Version 1.x bezieht, während “Angular” sich auf die Version 2+ bezieht. Beginnen Sie die Verwendung der CLI mit folgendem Befehl: npm install -g @angular/cli

Es gibt sicherlich noch einige weitere Bibliotheken/Frameworks, die aufgelistet werden könnten, und die Liste wird sich mit der Zeit definitiv ändern. Ich habe mich entschieden, nur solche aufzulisten, mit denen ich entweder durch die Entwicklung oder die Zusammenarbeit mit einem Unternehmen eigene Erfahrungen gesammelt habe.

Die Entwicklung für Mobilgeräte

Wenn Ihre Anwendungen auf mobilen Geräten (Web oder “nativ”) ausgeführt werden, wie gut unterstützt die Bibliothek oder das Framework, die Sie betrachten, die mobile Entwicklung? Müssen Sie alle mobilen, “touch”- Controls manuell entwickeln? Es sind solche und ähnliche Fragen, die Sie sich bei der Auswahl der passenden Bibliothek oder des richtigen Frameworks stellen sollten.

Welche Optionen von Drittanbietern sind verfügbar?

Ein weiterer zu berücksichtigender Faktor sind die Optionen von Drittanbietern, die für eine Bibliothek oder ein Framework verfügbar sind. Möchten Sie wirklich die Auswahl eines Datums oder einen Kalender von Grund auf neu bauen? (Ich vermute, wenn Sie das einmal getan haben, werden Sie laut “Nein” rufen!) Ein robuster Satz von Drittanbieterfunktionen, die Sie in eine Bibliothek oder ein Framework integrieren können, ist besonders wichtig, wenn es um die Produktivität geht.

Meine Einschätzung zu Vanilla JS

Einige Leute werden argumentieren, dass Vanilla JavaScript der richtige Weg für JavaScript-zentrierte Anwendungen ist, also möchte ich diese Option noch erwähnen. Obwohl ich aus verschiedenen Gründen mit dem Vanilla JavaScript-Ansatz (insbesondere bei größeren Unternehmensanwendungen) völlig anderer Meinung bin, ist es sicherlich eine gute Option, die je nach Art der Anwendung, die Sie erstellen, in Betracht zu ziehen ist.

Warum gefällt mir dieser Ansatz nicht? Wenn die zu erstellende Applikation ziemlich klein ist, dann kann der Vanilla JS-Ansatz gut funktionieren. Für robustere Anwendungen muss jedoch alles von Grund auf neu aufgebaut werden, was bedeutet, dass das Rad für Routing, Data Binding, Formvalidierung, Historie usw. neu erfunden wird. Es bedeutet, Sie müssen alle Browser-Merkmale, Sicherheitsstandards, neue und zukünftige Technologien etc. kennen. Doch wer hat die Zeit, um immer auf dem Laufenden zu bleiben und gleichzeitig Geschäftsanwendungen zu entwickeln? Was passiert, wenn die Schlüsselpersonen, die die Vanilla JavaScript-Codebasis aufgebaut haben, sich entscheiden, das Unternehmen zu wechseln? Auf einmal müssen Sie sich nicht nur um die Wartung der  Geschäftsanwendung kümmern, sondern auch um die benutzerdefinierten JavaScript-Dienstprogramme oder das Framework, das von jemandem intern entwickelt wurde.

Fazit

Die Auswahl der richtigen Bibliothek bzw. des richtigen Frameworks ist immer eine persönliche Wahl. Daher ist es wichtig, mögliche Vorlieben und Vorurteile bei der Entscheidungsfindung zu hinterfragen. Ich habe nicht versucht, für verschiedene Bibilotheken oder Frameworks Vor- und Nachteile aufzulisten (abgesehen davon, dass ich einige wenige hier im Beitrag kurz erwähnt habe), da ich der festen Überzeugung bin, dass jede Person/jedes Team selbst experimentieren muss, bevor sie eine Entscheidung trifft.

Sprechen Sie mit jemandem, dem Sie vertrauen, der eine Bibliothek oder ein Framework verwendet hat, die oder das für Sie in Frage kommt. Holen Sie sich Feedback ein. Bauen Sie einen einfachen Prototyp und sehen Sie, wie Sie sich danach fühlen. So erhalten Sie sicherlich einige Antworten auf die Fragen, die ich hier im Artikel gestellt habe.

Es gibt viele zusätzliche Fragen und Richtlinien, die aufgelistet werden könnten, um die Auswahl der “richtigen” Bibliothek oder des “passenden” Frameworks weiter zu detaillieren. Alle Bibliotheken bzw. Frameworks haben ihre eigenen Vor- und Nachteile und alle können verwendet werden, um kleine, mittlere und große Anwendungen zu erstellen. Leider gibt es nur subjektive Antworten auf die Frage nach der “richtigen” oder “passenden” Lösung. Das sollten Sie auf jeden Fall im Hinterkopf behalten, wenn Sie Artikel lesen, die Bibliotheken und Frameworks miteinander vergleichen; Vergleiche sind subjektiv.

Ich hoffe, dass einige der hier aufgeführten Fragen und Überlegungen Ihnen helfen werden, eine gute Entscheidung für sich und Ihr Team zu treffen.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Der Beitrag von Dan Wahlin ist im Original unter https://blog.codewithdan.com/choosing-the-right-javascript-library-framework-for-your-application/ erschienen. Mit Zustimmung von Dan Wahlin übersetzen wir verschiedene Beiträge von ihm hier in unserem Blog vom Englischen ins Deutsche. Beiträge im Original finden Sie unter https://blog.codewithdan.com/. In LinkedIn können Sie sich mit ihm unter https://www.linkedin.com/in/danwahlin/ vernetzen.

Dan Wahlin
Dan Wahlin

Dan Wahlin ist Entwickler, Architekt, Technologietrainer, Autor und öffentlicher Redner mit Fachkenntnissen in der Architektur, dem Design und dem Bau von lokal und in der Cloud gehosteten Webanwendungen unter Verwendung verschiedener Technologien (JavaScript, TypeScript, Angular, .NET, C #, ASP.NET) , Node.js, HTML5 / CSS, Docker, Azure, Github / git, Windows / OSX / Linux und mehr). Er ist Autor mehrerer Bücher, verfasste Hunderte von technischen Artikeln und erstellt Videokurse für Pluralsight und Udemy. Dan spricht gerne bei Anwendergruppen, Meetups, Code-Camps und Konferenzen auf der ganzen Welt, darunter Microsoft BUILD und (früher) TechEd, MIX, DevIntersection, AngleBrackets, DevSum, Ng-Conf, Angular U und viele andere.