Eine Angular Roadmap – Die Vergangenheit, Gegenwart und Zukunft von Angular

Angular Updates: Was ist neu in Version 11

Ab November 2020 ist Angular Version 11.0.0 verfügbar. Während diese Version viele Updates für die Plattform bringt, gehören zu den wichtigsten Features schnellere Builds mit TypeScript 4.0, Komponententest-Harnesse und ESLint-Updates.

Paleolithisches JavaScript – SproutCore

Am Anfang war SproutCore. Es war das erste umfassende JavaScript-Framework, das darauf abzielte, die Erstellung von Single-Page-Webanwendungen in Desktop-Qualität zu erleichtern. Es ist nicht so, dass dies vorher nicht möglich gewesen wäre. Als Google Gmail herausbrachte, zeigte es der Welt, dass Webanwendungen wirklich komplexe Desktop-Anwendungen ersetzen können. Google hat sogar das Closure-Toolkit – eine Reihe von Bibliotheken und einen optimierenden Compiler, die für die Entwicklung von Google Mail verwendet wurden – als Open Source zur Verfügung gestellt.

Das Problem war, dass die Closure-Tools von Google nicht sehr entwicklerfreundlich waren. Sie stützten sich stark auf Java, was Webentwickler, die an die Arbeit mit JavaScript, PHP, Ruby und Python gewöhnt waren, abschreckte. Gmail war eine großartige Demonstration dessen, was möglich war, aber die Entwicklung ähnlicher Anwendungen fühlte sich für viele immer noch unerreichbar an.

Einigen mutigen Entwicklern gelang es, mit einer Kombination aus jQuery, Klebeband und Hoffnung erstaunliche einseitige Anwendungen zusammenzustellen. Während diese Anwendungen für die Endbenutzer erstaunlich aussahen, verwandelten sie sich für die Entwickler, die an ihnen arbeiteten, schnell in riesige Haufen technischer Schulden, die dem Entwicklerteam den morgendlichen Gang zur Arbeit verleiden.

Infolgedessen begannen einige unternehmungslustige Entwickler, an Frameworks zu arbeiten, die Gmail-ähnliche Anwendungen für Webentwickler überall leicht zugänglich machen sollten. SproutCore war das erste dieser Frameworks, das sich durchsetzte. Es enthielt einen kompletten Satz von Widgets, die es ermöglichten, komplexe Webanwendungen zu erstellen, ohne HTML oder CSS auch nur anzufassen.

Dies war für ehemalige Desktop-Entwickler, die mit Ach und Krach ins Web gezogen worden waren, von großem Nutzen. Mehrere weitere Frameworks mit ähnlichen Zielen kamen auf; GWT und Cappuccino waren die bekanntesten. Diese Frameworks umgingen sogar JavaScript, indem sie andere Sprachen in JS transpilierten. Auch das war großartig für Desktop-Entwickler. Aber es ließ leidenschaftliche Webentwickler im Regen stehen und gab ihnen das Gefühl, dass ihre hart erarbeiteten HTML-, CSS- und JavaScript-Kenntnisse nicht wertvoll waren.

Damit war der Weg frei für ein Framework, das das Web wirklich einbezieht, anstatt es zu überpflastern und so zu tun, als wäre es etwas anderes. Einige frühe Frameworks (Backbone und Knockout) kamen auf den Markt und erzielten einen mäßigen Erfolg. Auch Ember tauchte um diese Zeit auf. Es nahm SproutCore, zerlegte es bis auf die Knochen und versuchte, es in etwas wirklich Web-freundliches umzuwandeln. Ember wollte der Six Million Dollar Man der JavaScript-Welt sein: besser, stärker und schneller umgebaut.

Keines dieser Frameworks erlangte große Popularität. Die Welt wartete auf etwas Besseres. Im Jahr 2010 erschien dieses Bessere – es hieß Angular.

Das goldene Zeitalter von Angular

Noch bevor Angular Version 1.0 veröffentlicht wurde, eroberte Angular die Welt der Frontend-Entwicklung im Sturm. Endlich gab es ein einfach zu bedienendes JavaScript-Framework, das HTML wie einen Bürger erster Klasse behandelte. Entwickler und Designer konnten nun zusammenarbeiten, um erstaunliche einseitige Anwendungen zu erstellen. Das war eine Erleichterung für Designer, die verärgert und beleidigt waren, weil ältere Frameworks HTML und CSS als Werkzeuge für Barbaren behandelt hatten, Werkzeuge, die kein zivilisierter Entwickler anfassen sollte.

Das erste, was Entwicklern, die Angular zum ersten Mal ausprobierten, magisch erschien, war die Zwei-Wege-Datenbindung. Zuvor hatten die meisten Entwickler diese Art der Datenbindung nur in Desktop-Frameworks wie WPF und Windows Forms gesehen. Es war großartig, Formulare und andere UI-Elemente an JavaScript-Modellobjekte binden zu können. Obwohl die Zwei-Wege-Datenbindung bei übermäßigem Einsatz zu Leistungsproblemen führen kann, konnten Teams, die sie mit Bedacht einsetzten, mit Angular komplexe Front-End-Anwendungen viel schneller als je zuvor erstellen.

Angular erwies sich nicht nur wegen der einfachen Bindung von Daten an HTML-Elemente als beliebt. Angular-Direktiven boten eine einfache Möglichkeit, wiederverwendbare HTML- und CSS-Komponenten zu erstellen. Obwohl andere JavaScript-Frameworks dies bereits vor Angular boten, war Angular das erste, das sich großer Beliebtheit erfreute. Wiederverwendbare Komponenten waren schon lange in serverseitigen Frameworks im Einsatz. ASP.NET User Controls und partielle Templates in Rails und Django sind nur einige
Beispiele.

Schließlich machte Angular die Dependency Injection in der Welt der Frontend-Entwicklung populär. Dependency Injection war lange Zeit in Unternehmensanwendungen beliebt, was vielleicht der Grund dafür ist, dass sie sich in der JavaScript-Welt nicht durchgesetzt hat. Front-End-Entwickler sind seit langem abgeneigt gegenüber dem, was sie als unnötig komplexe Entwurfsmuster für Unternehmenssoftware ansehen. Diese Sorge ist nicht unbegründet. Haben Sie sich beim Schreiben einer Anwendung schon einmal gesagt: „Was ich hier wirklich brauche, ist eine „SimpleBeanFactoryAwareAspectInstanceFactory?“

Die Injektion von Abhängigkeiten hat sich jedoch bewährt. Und Angular hat die Injektion von Abhängigkeiten für ein Publikum einfach gemacht, das sie in der Vergangenheit nicht oft verwendet hat. Sie brauchen einen HTTP-Client? Oder möchten Sie vielleicht eine Animation erstellen? Das ist kein Problem. Angular verfügt über integrierte Dienste für diese Aufgaben. Sie brauchen sie nur anzufordern, und Angular fügt sie in Ihre Komponenten ein. Sie brauchen nichts selbst zu instanziieren.

Oder wollten Sie vielleicht die window– oder location-Objekte des Browsers verwenden, ohne dass es unmöglich ist, Ihre Komponenten außerhalb des Browsers einem Unit-Test zu unterziehen? Auch hier hat Angular mit seinen eingebauten Diensten $window und $location vorgesorgt. Zur Laufzeit erhalten Sie die Browserobjekte, die Sie erwartet haben. Und wenn Sie Unit-Tests serverseitig in Node.js ausführen, können Sie Mock-Dienste an Ihre Komponenten übergeben, um sicherzustellen, dass sie sich in verschiedenen Szenarien wie erwartet verhalten.

Wenn das alles noch nicht genug war, machte es Angular auch einfach, eigene Dienste zu registrieren und zu injizieren. Für Entwickler, die daran gewöhnt waren, alle ihre Daten an das DOM zu binden und auf das Beste zu hoffen, war das großartig. Wenn Sie eine neue Front-End-Anwendung schreiben, die APIs aufruft, die Ihr Unternehmen bei übermäßiger Nutzung viel Geld kosten würden, würden Sie es wahrscheinlich vorziehen, im Voraus Tests schreiben zu können, um sicherzustellen, dass Ihre Anwendung nicht versucht, so etwas wie den Aufruf der Twilio-API 800 Millionen Mal durchzuführen.

Sie würden also einen Twilio-Dienst erstellen, der zur Laufzeit injiziert wird. Zur Testzeit erstellen Sie einen Mock-Service, der die Kosten jedes API-Aufrufs aufzeichnet, den Ihre Anwendung zu tätigen versucht. Sie schreiben Tests, die gängige Nutzungsszenarien abdecken und sicherstellen, dass diese Szenarien nicht dazu führen, dass Ihr Unternehmen eine siebenstellige Rechnung erhält. Insgesamt stellten die meisten Entwickler fest, dass Angular-Direktiven in Kombination mit Dependency Injection das Schreiben von modularen, testbaren Front-End-Anwendungen unter Verwendung bewährter Software-Engineering-Techniken ermöglicht. Viele Entwicklungsteams waren mit dieser Situation sehr zufrieden und entschieden sich für Angular.

Der Niedergang von Angular? Der Aufstieg von React

Auch wenn es in der Welt von Angular größtenteils gut lief, war nicht alles Sonnenschein und Lollipop. Entwickler stießen auf ernsthafte Leistungsprobleme, wenn sie versuchten, zu viele Modellobjekte an zu viele DOM-Elemente zu binden. Einige Anwendungen verlangsamten sich zu einem Kriechgang. Direkte Aufrufe von $digest und andere schwarzmagische Zaubereien wurden notwendig, um eine akzeptable Leistung zu erzielen. Etwa zur gleichen Zeit tauchte ein neuer Herausforderer auf: React. Zunächst schien React keine allzu große Gefahr für Angular darzustellen. Schließlich hatten sich diese React-Verrückten die Mühe gemacht, JSX zu erfinden, das wie eine Möglichkeit aussah, Markup in den Code zu mischen. Hatten wir uns nicht die Mühe gemacht, Templatesprachen aus dem ausdrücklichen Grund zu erfinden, um die Vermischung von Markup und Code zu vermeiden?

Wie sich herausstellte, war der Ansatz von React in der Community der Frontend-Entwickler ziemlich beliebt. Die Popularität stieg jedoch nicht rasant an. Angular war immer noch dominant, und es sah so aus, als würde das auch so bleiben. Bis die Popularität von Angular von einer unerwarteten Quelle einen kräftigen Tritt in den Hintern bekam: dem Angular-Team selbst.

Die Einführung von Angular 2

Angular 2 wurde erstmals auf der ng-europe-Konferenz im Jahr 2014 angekündigt. Die Pläne des Angular-Teams waren für die Angular-Community gelinde gesagt ein Schock. Die Reaktion der Angular-Entwickler war schnell und negativ… und das nicht ohne Grund. Angular 2 würde viele vertraute Konzepte von Angular 1 loswerden, eine neue, inkompatible Templating-Sprache einführen (und, ach ja, auch mit einer völlig neuen Sprache programmiert werden).

AngularJS

Obwohl sowohl Angular 1 als auch Angular 2 als „Angular“ bezeichnet wurden, handelte es sich in Wirklichkeit um sehr unterschiedliche Frameworks mit ein paar Gemeinsamkeiten. Um Verwirrung zu vermeiden, begann das Angular-Team, die alte Version von Angular als „AngularJS“ und die neue Version einfach als „Angular“ zu bezeichnen. Dies ist intuitiv sinnvoll, da AngularJS in JavaScript geschrieben wurde, Angular hingegen nicht. Um den Unterschied zwischen den Frameworks deutlich zu machen, bezeichne ich Angular 1 von nun an als AngularJS.

Als Ergebnis all dessen verloren die Entwickler von AngularJS den Glauben an die Zukunft des Frameworks. Sie drohten damit, bei zukünftigen Projekten auf ein neues Framework umzusteigen, und genau das taten viele von ihnen. React war der größte Nutznießer der Massenflucht aus AngularJS.

Auch wenn React nicht so viel geleistet hat wie AngularJS, war das in gewisser Weise positiv. Wenn du eine View-Bibliothek verwendest, die nicht versucht, alles und jedes zu integrieren, ist es für die Entwickler dieser Bibliothek viel schwieriger, dir in Zukunft den Teppich unter den Füßen wegzuziehen. Am Anfang war die Verwendung von React im Vergleich zu AngularJS etwas mühsam. Man musste einen Flickenteppich von Bibliotheken zusammenschustern, nur um die Funktionalität abzudecken, die AngularJS von Haus aus bietet.

Viele Teams sahen darin eine gute Möglichkeit, das Risiko zu verringern, da es unwahrscheinlich war, dass die Entwickler all dieser Bibliotheken beschließen würden, gleichzeitig rückwärtskompatible Änderungen vorzunehmen, was im Wesentlichen das war, was Angular getan hatte.

Das Aufkommen von Vue

Um die Probleme von AngularJS noch zu verschlimmern, tauchte etwa zur gleichen Zeit, als sich das Drama um Angular 2 abspielte, ein weiteres Framework namens Vue auf. Vue wurde von AngularJS inspiriert, zielte aber darauf ab, es zu vereinfachen und das loszuwerden, was der Schöpfer von Vue als unnötige Komplexität ansah (daher fühlte sich Vue für bestehende AngularJS-Entwickler sehr vertraut an). Vue bot einen sicheren Hafen für viele AngularJS-Entwickler, die nicht zu React wechseln wollten.

Das bedeutet nicht, dass AngularJS-Entwickler nicht geduldig auf das Erscheinen von Angular 2 gewartet haben. Aber es ist klar, dass es einen Massenexodus von AngularJS zu React und Vue gab, aufgrund der Unsicherheit, die durch die Pläne für Angular 2 verursacht wurde.

Auferstehung aus der Asche mit Angular 2

Endlich wurde Angular 2 veröffentlicht. Wie erwartet, wurden viele bekannte Konzepte von AngularJS abgeschafft, aber einige der besten Elemente wie Services und Dependency Injection wurden beibehalten. Zum Glück für die Vernunft der Entwickler verwendet Angular einfaches TypeScript und nicht wie ursprünglich geplant einen Fork.

Um die Dinge noch verwirrender zu machen, hat das Angular-Team einen Fork des neuen Frameworks beibehalten, der die Programmiersprache Dart anstelle von TypeScript verwendet. Anfänglich wurden die TypeScript- und Dart-Versionen synchron entwickelt und aus einer einzigen Codebasis generiert. Schließlich beschlossen die TS- und Dart-Versionen von Angular, getrennte Wege zu gehen, und Angular Dart existiert jetzt als eigenständige Version.

Auch nach dieser Verwirrung begann die Popularität von Angular nach der Veröffentlichung von Angular 2 wieder zu steigen. Das geschah langsam. Wie so oft in der Softwareentwicklung verschoben sich die Trends. Die Entwickler erkannten, dass ein großes, in Batterien integriertes Framework tatsächlich nützlich sein könnte. Denn wenn Ihre Anwendung groß genug ist, brauchen Sie am Ende tatsächlich alle diese Batterien.

Vor allem Entwickler aus dem Unternehmensbereich begannen, wieder auf Angular umzusteigen. Das macht Sinn. Wenn man mit einer Webanwendung für Unternehmen beginnt, weiß man normalerweise, dass sie komplex sein wird. Es macht keinen Sinn, mit einem winzigen MVP anzufangen, wenn man von Anfang an weiß, welche 87 Aufgaben die Anwendung erfüllen muss.

Wo ist Angular 3?

Obwohl Angular 2 nicht perfekt war, erkannten viele Entwickler komplexer Webanwendungen, dass das neue und verbesserte Angular gut zu ihren Bedürfnissen passte. Zum Glück für sie hatte Angular einige spannende Verbesserungen auf Lager. Noch wichtiger ist, dass das Angular-Team bewiesen hat, dass es in der Lage ist, durchgängig neue Versionen des Frameworks zu veröffentlichen, mit nur wenigen Änderungen zwischen den Versionen

In einem Schritt, der damals seltsam erschien, beschloss das Angular-Team, Version 3 ganz zu überspringen und zu Version 4 überzugehen. Dies geschah aus gutem Grund: Das Team, das an dem Router-Paket von Angular arbeitete, hatte bereits die Version 3 veröffentlicht, während der Rest von Angular noch bei Version 2.3 war. Sie beschlossen, alle Angular-Paketversionen in Zukunft synchron zu halten, und alles für die nächste Version auf Version 4 zu bringen, war der einfachste Weg, dies zu erreichen.

Angular 4

Angular 4 enthielt einige wichtige Änderungen, darunter die vorzeitige Kompilierung, die zu kleineren JavaScript-Bündeln in der Produktion und kürzeren Ladezeiten der Anwendung führte. Die Unterstützung für serverseitiges Rendering wurde hinzugefügt, was für Teams, die ihre Anwendung vorzeitig rendern wollten, um die anfängliche Ladeleistung zu verbessern, ein Gewinn war. Viele andere Verbesserungen wurden im gesamten Framework hinzugefügt, aber das Upgrade von Anwendungen von Angular 2 auf 4 war in den meisten Fällen schnell und schmerzlos.

Angular 4.3 und Angular 5

Angular 4.3 fügte einen neuen HTTP-Client hinzu, der einfacher zu verwenden war als der alte HTTP-Dienst. In Angular 5 wurde der alte HTTP-Dienst veraltet und würde in der nächsten Version wegfallen. Trotz dieser Unannehmlichkeiten gab es relativ wenig Murren, da das Upgrade in den meisten Fällen unkompliziert war. Angular 5 fügte auch eine bessere Internationalisierungsunterstützung und weitere Build-Optimierungen hinzu.

Angular 6 und 7

Angular 6 und 7 waren für einige Entwickler enttäuschend. Es gab keine großen Änderungen, aber viele kleine Verbesserungen der Lebensqualität, vor allem bei den Angular-CLI-Werkzeugen. Die abnehmende Zahl der sichtbaren Änderungen ist kein Hinweis darauf, dass das Angular-Team aufgehört hat, innovativ zu sein. Stattdessen zeigt es, dass das Framework ausgereift ist, so dass das Entwicklerteam nun mehr Arbeit hinter den Kulissen leisten kann, um Fehler zu beheben und die Leistung zu verbessern.

Die Stabilität des Frameworks seit der Veröffentlichung von Angular 2 hat einige AngularJS-Entwickler der alten Schule zurück in die Angular-Welt gezogen. Es hat auch die Aufmerksamkeit von Entwicklungsteams in Unternehmen auf sich gezogen. Bei der Entwicklung von Unternehmensanwendungen, die Jahrzehnte überdauern können, ist es ideal, ein Framework zu verwenden, das in einem vorhersehbaren Zeitplan neue Versionen herausbringt, sich aber nicht zu schnell ändert. Ein Entwickler, der bisher nur mit Angular 2 gearbeitet hat, kann innerhalb von Minuten eine Angular 7-Applikation entwickeln.

Angular 8 und Angular Ivy

Und das bringt uns zu heute. Wie wir gesehen haben, hat Angular einen langen Weg hinter sich. Es wurde von Webentwicklern geliebt, verschmäht und bewundert, auch wenn es noch nicht wieder so beliebt ist wie in den Anfangstagen.

Am Horizont sehen wir Angular 8. In Angular 8 wurde eine Menge Arbeit geleistet, um die Verwendung mit dem Bazel-Build-System zu vereinfachen, was für alle Entwickler, die es außerhalb von Google verwenden, eine großartige Nachricht ist. Lesen Sie mehr über die Änderungen in Angular 8.

Noch spannender ist jedoch, dass das Angular-Team hart an einem neuen Rendering namens Angular Ivy arbeitet. Es soll ein Drop-in-Ersatz für das aktuelle Rendering sein. Im Großen und Ganzen werden aktuelle Anwendungen keine Änderungen vornehmen müssen, um Angular Ivy zu verwenden.

Wenn Angular Ivy ein „Drop-in“-Ersatz ist, warum sollten sich Entwickler dafür interessieren? Zwei wichtige Gründe: Geschwindigkeit und Paketgröße – zwei sehr wichtige Anliegen. Ein paar Jahre lang schien es, als wären Webentwickler ein wenig verrückt geworden. Teams lieferten JavaScript-Pakete mit einer Größe von 5 MB, 10 MB oder sogar noch mehr und dachten, dass dies kein Problem sei. Schließlich funktionierten die Anwendungen perfekt auf den i7-betriebenen MacBook Pros der Entwickler, also sollten sie auch für alle anderen gut funktionieren, oder?

Dummerweise ist in der realen Welt nicht jeder mit der neuesten und besten Hardware ausgestattet. Hunderte von Millionen Menschen gehen nur mit älteren Android-Handys ins Internet, die etwas mehr Rechenleistung haben als eine Kartoffel, und das über Internetverbindungen, die nur wenig schneller sind als eine Einwahlverbindung. Für diese Nutzer dauert es ewig, bis ein großes JavaScript-Paket geladen ist, und noch länger, bis ihr Gerät es analysiert und ausführt. Selbst in weniger extremen Fällen gibt es weltweit unzählige Nutzer, die nicht die neueste und beste Hardware verwenden. Für sie sind umfangreiche JavaScript-Anwendungen brauchbar (aber mühsam).

Angular Ivy

Der Angular Ivy Renderer wird in mehrfacher Hinsicht helfen:

1. Er wird mit einem Auge auf Effizienz geschrieben, so dass er die gleichen Aufgaben mit viel weniger CPU-Anweisungen erledigen wird. Dies wird sowohl die Akkulaufzeit als auch die Vernunft von Benutzern mit weniger leistungsfähigen Geräten verbessern.
2. Der Renderer wird wesentlich modularer geschrieben sein als der aktuelle Renderer. Das macht ihn viel zugänglicher für Tree-Shaking und die Eliminierung von totem Code. Das Ergebnis ist, dass Ihr JavaScript-Produktions-Bundle nur den Code enthält, der zum Ausführen Ihrer Anwendung benötigt wird, anstatt alles plus das Spülbecken zu bündeln, wie es beim aktuellen Renderer häufig der Fall ist.
3. Zusätzlich zur Verringerung der Bundle-Größe und der verbesserten Rendering-Geschwindigkeit bietet Angular Ivy noch einige weitere Verbesserungen der Lebensqualität für Angular-Entwickler. Die Rebuild-Zeiten sind deutlich schneller. Wenn Sie also Ihre App im Entwicklungsmodus laufen lassen und darauf warten, dass Ihre Änderungen angezeigt werden, werden Sie jetzt viel weniger Zeit mit Warten verbringen.
4. Die Template-Typ-Prüfung wurde verbessert, was bedeutet, dass Sie mehr Fehler zur Kompilierzeit statt zur Laufzeit abfangen werden. Laufzeit-Template-Fehler sind ärgerlich, weil sie entweder Sie beim Testen oder Ihre Benutzer beißen, wenn sie versuchen, Ihre Anwendung zu verwenden.
5. Der Angular Ivy Template Compiler wird Code generieren, der für Menschen lesbar ist, was der aktuelle View Engine Compiler nicht tut. Dies wird sich als nützlich erweisen, wenn Sie versuchen, schwierige Template-Fehler aufzuspüren.

Das Endergebnis: kleinere Anwendungen, schnellere Anwendungen, zufriedenere Entwickler und zufriedenere Nutzer.

Angular 9

Hier ist ein Überblick über Angular 9.

Die wichtigsten Highlights sind:

• Eingebaute Angular-Funktionen
• Ausgereifte Entwicklung mit Angular
• Verständnis der Angular-View-Engines
• Angular Ivy löst altbekannte Probleme
• Angular Ivy und Mobile
• Selector-less Directives
• Angular Diagnostics Improvements
• Internationalization with Angular Ivy
• DI and Type-Safe in Angular 9
• Dependency Injection Changes in Angular Core
• Angular Benchmarks (Angular 8.2.7 vs. 9.0.0-next.5)

Angular 10

Angular Version 10.0.0 wurde Ende Juni 2020 veröffentlicht. Angular 10 ist eine Hauptversion und enthält Änderungen wie einen neuen Datumsbereichspicker in Angular Material, aktualisierte TypeScript-Versionen, Bibliotheksversionen und mehr.

Neue Funktionen sind:

• Ngtsc Compiler Interface
• Konfigurieren von Async Timeouts
• Stale Lock File Reporting
• Lazy Computation of basePaths
• Merging Translation Files
• Explicit Mapping

Angular 11

Angular Version 11.0.0 wurde im November 2020 veröffentlicht. Die Hauptversion von Angular 11 bietet Updates für die gesamte Plattform, einschließlich der CLI und des Komponenten-Frameworks.

Zu den wichtigsten Funktionen gehören:

• Schnellere Builds mit TypeScript 4.0
• Component Test Harnesses
• ESLint Updates
• Updated Language Service Preview
• Updated Hot Module Replacement (HMR) Support
• Verbesserte Reportings und Logging
• Automatic Font Inliining

Angulars Vergangenheit, Gegenwart und Zukunft

Wenn Sie Angular seit seinen Anfängen bis heute nutzen, dann herzlichen Glückwunsch! Es gab zwar eine Menge rauer Stellen, aber am Ende haben wir ein schnelles, modernes Framework, dessen Verwendung Spaß macht.

Wenn Sie ein AngularJS-Entwickler waren, aber zu React, Vue oder etwas anderem übergegangen sind, möchte ich Sie ermutigen, sich Angular noch einmal anzusehen. Es ist Ihre Zeit wert, auch wenn Sie sich entscheiden, bei dem zu bleiben, was Sie jetzt verwenden.

Und wenn Sie Angular noch nie benutzt haben, warum probieren Sie es nicht aus?

Wir haben gerade eine rasante Tour durch die Vergangenheit, Gegenwart und Zukunft von Angular gemacht. Zweifellos war es eine aufregende Reise. Unabhängig von Ihrem Angular-Hintergrund, hoffe ich, dass Sie die Tour genossen haben!

Mit welchem Framework arbeiten Sie und warum? Wenn Sie Fragen oder Kommentare haben, stellen Sie sicher, sie unten eingeben.

Suchen Sie nach Framework-unabhängigen UI-Komponenten? GrapeCity verfügt über ein komplettes Set von JavaScript UI-Komponenten, einschließlich Datenrastern, Diagrammen, Messgeräten und Eingabesteuerungen. Wir bieten auch leistungsstarke Tabellenkalkulationskomponenten, Berichtssteuerungen und erweiterte Präsentationsansichten. Wir bieten umfassende Unterstützung für Angular (sowie React und Vue) und sind bestrebt, unsere Komponenten für die Verwendung in modernen JavaScript-Frameworks zu erweitern.