Frontend-Frameworks: Lösungen oder aufgeblähte Probleme?

Moderne Front-End-Frameworks erfordern, dass Sie eine Entwicklungsumgebung mit allen Abhängigkeiten herunterladen und Ihren Code kompilieren, bevor Sie überhaupt versuchen, ihn in Ihrem Browser anzuzeigen. Ist das eine gute Sache? Liegt das Problem darin, dass wir komplexere Websites erstellen, oder sind die Frameworks selbst komplex und führen zu unnötiger Komplexität?

Die heutige Webentwicklung hat sich seit den 90er Jahren stark weiterentwickelt; Wir sind in der Lage, ganze Erlebnisse zu schaffen, die dem sehr nahe kommen, was jede native Anwendung leisten kann, und auch der Entwicklungsprozess hat sich geändert. Vorbei sind die Zeiten, in denen man als Front-End-Webentwickler Notepad öffnen, ein paar Codezeilen eingeben, im Browser überprüfen und in einen FTP-Ordner hochladen musste.

Die Frontend-Webentwicklung der Vergangenheit

Ich muss mit dem Offensichtlichen beginnen: Die Welt ist nicht mehr so ​​wie vor 10 Jahren. (Schockierend, ich weiß.) Das Einzige, was konstant bleibt, ist der Wandel. Damals hatten wir nur sehr wenige Browser, aber es gab viele Kompatibilitätsprobleme. Heutzutage sieht man Dinge wie „am besten auf Chrome 43.4.1 angezeigt“ nicht oft, aber damals war es ziemlich üblich. Wir haben jetzt mehr Browser, aber weniger Kompatibilitätsprobleme. Warum? Wegen jQuery . jQuery befriedigte die Notwendigkeit einer gemeinsamen Standardbibliothek, mit der Sie JavaScript-Code schreiben konnten, der das DOM manipuliert, ohne sich Gedanken darüber machen zu müssen, wie es auf jedem Browser und in jeder Version jedes Browsers ausgeführt werden würde – ein wahrer Albtraum in den 2000er Jahren .

Moderne Browser können das DOM standardmäßig manipulieren, sodass der Bedarf an einer solchen Bibliothek in den letzten Jahren stark zurückgegangen ist. jQuery wird nicht mehr benötigt , aber wir können immer noch eine Reihe äußerst nützlicher Plugins finden, die davon abhängen. Mit anderen Worten, Web-Frameworks sind möglicherweise nicht erforderlich, aber dennoch nützlich genug, um beliebt und weit verbreitet zu sein. Dies ist eine Eigenschaft, die den meisten gängigen Web-Frameworks auf dem Markt gemeinsam ist, von React, Angular, Vue und Ember bis hin zu Stil- und Formatierungsmodellen wie Bootstrap.

Warum Menschen Frameworks verwenden

In der Webentwicklung wie im Leben ist es immer praktisch, eine schnelle Lösung zu haben. Haben Sie schon einmal einen Router in JavaScript erstellt? Warum den schmerzhaften Lernprozess durchlaufen, wenn Sie ein Front-End-Framework npm-installieren können, um das Problem zu lösen? Zeit ist ein Luxus, wenn der Kunde Dinge gestern erledigen möchte oder Sie Code von einem anderen Entwickler erben, der für ein bestimmtes Framework entwickelt wurde, oder wenn Sie in ein Team integrieren, das bereits ein bestimmtes Framework verwendet. Seien wir ehrlich – Frameworks existieren aus einem bestimmten Grund. Wenn sie keinen Nutzen hätten, würde sie niemand benutzen.

Was sind also einige der Vorteile und einzigartigen Eigenschaften der Verwendung eines Webentwicklungs-Frameworks?

Zeit ist Geld. Wenn Sie ein Projekt entwickeln und es dem Kunden egal ist, welches Framework Sie verwenden – er weiß wahrscheinlich nicht einmal, was Sie verwenden –, geht es ihm nur darum, Ergebnisse zu erzielen, und je schneller, desto besser. Mit etablierten Frameworks können Sie von Anfang an ein sofortiges Gefühl des Fortschritts schaffen, nach dem sich der Kunde vom ersten Tag an sehnt. Je schneller Sie sich entwickeln, desto mehr Geld verdienen Sie außerdem, da die durch das Framework freigesetzte Zeit für die Übernahme von mehr genutzt werden kann Projekte.

Es dreht sich alles um die Gemeinschaft. Bei der Auswahl eines Frameworks ist dies ein sehr wichtiger Punkt – wer hilft Ihnen, wenn Sie bei einem Problem nicht weiterkommen? Sie und ich wissen beide, dass es irgendwann passieren wird. Sie werden an einen Punkt gelangen, an dem Sie etwas tun müssen, wofür das Framework nicht vorgesehen war oder auf das das Framework nie ausgelegt war, um Ihnen Zugriff zu gewähren. Daher ist es unerlässlich, eine Community zu haben, die Sie unterstützt. Entwicklung – insbesondere als Freiberufler – kann schwierig sein, da Sie in eine virtuelle Welt eingetaucht sind, und wenn Sie der einzige Front-End-Webentwickler in einem Team sind, bedeutet dies, dass Sie der einzige mit der Erfahrung und dem Fachwissen sind, um einen zu finden Lösung. Aber wenn das von Ihnen verwendete Front-End-Framework solide unterstützt wird, wird es auf der anderen Seite der Welt jemanden geben, der das gleiche Problem hatte und Ihnen vielleicht helfen kann.

Normen sind schön. Ist Ihnen schon einmal aufgefallen, dass Sie, wenn Sie in ein altes Stück Ihres eigenen Codes schauen, ziemlich einfach darin navigieren können? Oder zumindest einfacher als ein Stück Code, das von jemand anderem geschrieben wurde? Sie denken auf eine bestimmte Art, und Sie haben Ihre eigene Art, Dinge zu benennen und den Code zu organisieren. Das ist ein Standard. Wir alle folgen ihnen, auch wenn sie nur für uns selbst sind. Wir neigen dazu, ähnliche Dinge zum Frühstück zu essen, zu einer bestimmten Zeit aufzuwachen und unsere Schlüssel jeden Tag an der gleichen Stelle abzulegen. Und in der Tat, wenn wir unsere Routinen jeden Tag ändern würden, wäre das Leben viel schwieriger, nur weil wir herausfinden müssen, wie man Dinge macht. Haben Sie jemals Ihre Schlüssel verloren, weil Sie sie an einem anderen Ort als normal abgelegt haben? Standards machen das Leben einfacher. Bei der Arbeit in einem Team oder einer Community von Entwicklern sind sie absolut unverzichtbar.

Frameworks bieten von dem Moment an, in dem Sie sie installieren, einen Standard, der Sie anleitet, auf eine bestimmte Weise zu denken und zu codieren. Sie müssen keine Zeit damit verbringen, mit Ihrem Team einen Standard zu erstellen; Sie können einfach verfolgen, wie die Dinge im Framework ausgeführt werden. Das erleichtert die Zusammenarbeit. Es ist einfacher, nach einer Funktion zu suchen, wenn Sie wissen, dass sich die Funktion in einer bestimmten Datei befinden muss, da sie zum Hinzufügen einer Route in einer SPA erstellt wurde und in Ihrem Framework alle Routen in einer Datei mit diesem Namen abgelegt werden. Menschen mit unterschiedlichen Fähigkeiten können zusammenarbeiten, wenn Sie über dieses Standardisierungsniveau verfügen, denn während die fortgeschrittenen Programmierer wissen, warum die Dinge so gemacht werden, können selbst Junior-Entwickler dem Standard selbst folgen.

Wenn Frameworks versagen

Wenn Sie vor ein paar Jahren so etwas wie „Ich verwende keine Frameworks – ich sehe keinen wirklichen Nutzen darin“ sagen, würden Ihnen Leute mit Fackeln und Mistgabeln vor die Tür locken. Doch heute fragen sich immer mehr Menschen: „Warum sollte ich überhaupt ein Framework verwenden? Brauche ich sie wirklich? Ist es so schwer, ohne sie zu programmieren?“

Ich bin sicherlich einer von ihnen – ich war noch nie ein Fan von bestimmten Frameworks und habe während meiner gesamten Karriere ohne sie programmiert. Wenn ich in der Angelegenheit eine Wahl habe, ist meine Wahl immer „Nein, danke“. Ich entwickle seit Jahren in JavaScript und davor in ActionScript. Ich habe in Flash codiert, als die meisten Leute es bereits für tot hielten. (Ich weiß, ich weiß … aber ich habe viele Animationen gemacht, und Animation in einfachem HTML ist schwierig.) Wenn Sie also zu den vielen gehören, die nie daran denken, ohne Frameworks zu programmieren, lassen Sie mich Ihnen einige Gründe dafür zeigen kämpfen.

„One size fits all“ ist eine Lüge. Können Sie sich vorstellen, eine einzige Software zu schreiben, die alles kann, was Sie in Ihrer Karriere erreicht haben? Das ist eines der Hauptprobleme bei Webentwicklungs-Frameworks. Ihr Projekt hat sehr spezifische Anforderungen, die wir in der Regel lösen, indem wir Bibliotheken, Plugins oder Add-Ons hinzufügen, um den Umfang des Frameworks zu erweitern. Kein Framework bietet 100 % von dem, was Sie brauchen, und kein Framework besteht zu 100 % aus Dingen, die Sie nützlich finden werden.

Zu viel Code, den Sie nicht verwenden, kann zu Ladezeitverzögerungen für Ihre Website führen, was mit jedem zusätzlichen Benutzer wichtiger wird. Ein weiteres Problem ist, dass die Denkweise „eine Größe für alle“ zu ineffizientem Code führt. Nehmen wir zum Beispiel $('sku-product').html('SKU 909090'); , das ist jQuery-Code, von dem wir alle wissen, dass er am Ende in so etwas wie document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

Diese Art von Unterschied in einer einzelnen Zeile mag unwichtig erscheinen, aber das Ändern des Inhalts eines bestimmten Elements der Seite ist genau der Vorteil von React. Jetzt durchläuft React den Prozess der Erstellung einer Darstellung des DOM und der Analyse der Unterschiede in dem, was Sie zu rendern versuchen. Wäre es nicht einfacher, von Anfang an nur auf den Inhalt abzuzielen, den Sie ändern möchten?

Das Gewirr von Unkraut, durch das du gehst, wächst mit Dornen. Waren Sie jemals in der Situation, dass Sie Ihr Framework verwenden und versuchen, eine Bibliothek hinzuzufügen, nur um festzustellen, dass die von Ihnen benötigte Bibliotheksversion nicht gut mit der von Ihnen verwendeten Framework-Version funktioniert? Manchmal ist es aufwändiger, zwei Codeteile zusammenzubringen, als den Code einfach selbst zu schreiben. Und da die von Ihnen verwendeten Frameworks und Bibliotheken oft auf anderen Frameworks und Bibliotheken aufbauen, die verborgene Inkompatibilitäten aufweisen können, die Sie nicht einmal vorhersehen können, kann das Problem exponentiell komplexer werden und einen Punkt erreichen, an dem sie für Sie unmöglich zu bewältigen sind wollen, dass das Projekt weiter wächst.

Mit den Joneses Schritt zu halten ist eine Sache. Haben Sie jemals an einem Projekt in AngularJS gearbeitet, nur um herauszufinden, dass Sie etwas brauchen, das erst mit der Veröffentlichung von Angular 4 erschienen ist? Wussten Sie überhaupt, dass Angular 5 veröffentlicht wurde? Dies ist ein weiteres großes Problem; Selbst wenn Sie an einem einzigen Front-End-Framework festhalten, können sich die Dinge bei einer neuen Hauptversion so stark ändern, dass der Code, an dem Sie so hart gearbeitet haben, nicht einmal auf der neuen Version ausgeführt werden kann. Dies kann zu lästigen kleinen Änderungen führen, die an vielen Dateien vorgenommen werden müssen, bis hin zu einer vollständigen Neuschreibung Ihres Codes.

Mit den neuesten Builds eines Frameworks Schritt zu halten, ist eine Herausforderung, aber auch andere Frameworks leiden, wenn Updates vollständig eingestellt werden und sie nicht mit dem Rest der Technologie Schritt halten können. 2010 wurden sowohl AngularJS als auch Backbone zum ersten Mal veröffentlicht. Heute befindet sich Angular in seiner fünften Hauptversion und Backbone ist völlig aus dem Rampenlicht gerückt. Sieben Jahre scheinen eine lange Zeit zu sein. Wenn Sie Websites erstellen, haben sich diese wahrscheinlich in Ästhetik und Funktion komplett verändert. Wenn Sie eine App entwickeln, kann das Setzen auf das falsche Framework das Unternehmen später in eine schwierige – und teure – Situation bringen, wenn Dinge neu geschrieben werden müssen.

Wenn man nur einen Hammer hat, sieht alles aus wie ein Nagel. Wenn Sie häufig Webentwicklungs-Frameworks verwendet haben, ist Ihnen dies wahrscheinlich passiert, bei dem eine einzige Codebasis die Form des Codes definiert, den Sie in Zukunft verwenden, auch wenn es nur am Rande verwandt ist. Angenommen, Sie bauen eine Plattform wie YouTube und möchten Framework X verwenden. Es könnte einen Punkt geben, an dem Sie sich entscheiden, Flash für die Videos zu verwenden, auch wenn es heutzutage lächerlich klingt, denn das ist es, was kommt mit Rahmen eingebaut.

Frameworks haben Meinungen, und sie sind stark; React zwingt Sie beispielsweise dazu, JSX auf eine bestimmte Weise zu verwenden. Sie können überall sehen, dass Code auf diese Weise verwendet wird. Gibt es eine Alternative? Jawohl. Aber wer nutzt es? Das ist nicht immer eine schlechte Sache, aber wenn Sie komplexe Animationen ausführen müssen, benötigen Sie möglicherweise nur ein Framework zum Animieren und nicht die Gesamtheit von React. Ich habe Leute gesehen, die verrückte Dinge getan haben, wie jQuery zu einer Seite hinzuzufügen, nur um einen Knoten an ein Element anzuhängen, etwas, das in Vanilla JS mit document.getElementById('id_of_node').appendChild(node); .

Eval ist böse, aber .innerHTML ist machiavellistisch

Ich möchte mir die Zeit nehmen, diesen Punkt separat zu untersuchen, weil ich denke, dass dies einer der Gründe ist, warum nicht mehr Leute ohne Frameworks programmieren. Wenn Sie sehen, wie der meiste Code funktioniert, wenn Sie versuchen, dem DOM etwas hinzuzufügen, werden Sie eine Menge HTML finden, das von der Eigenschaft .innerHTML wurde. Wir scheinen uns alle einig zu sein, dass eval schlecht für die Ausführung von JavaScript-Code ist, aber ich möchte hier .innerHTML ins Rampenlicht rücken. Wenn Sie HTML-Code als einfache Zeichenfolge einfügen, verlieren Sie alle Referenzen, die Sie möglicherweise auf einen der von Ihnen erstellten Knoten hatten. Es ist wahr, dass Sie sie möglicherweise zurückbekommen, indem Sie getElementsByClassName verwenden oder ihnen eine id zuweisen, aber das ist weniger als praktisch. Wenn Sie versuchen, den Wert eines der Knoten zu ändern, werden Sie den gesamten HTML-Code erneut rendern.

Das ist gut, wenn Sie mit dem Codieren beginnen. Sie können viele einfache Dinge leicht ohne viel Erfahrung machen. Das Problem tritt bei der Komplexität moderner Websites auf, die eher Apps ähneln – das bedeutet, dass wir die Werte unserer Knoten ständig ändern müssen, was ein kostenintensiver Vorgang ist, wenn Sie die gesamte Struktur neu anfügen über .innerHTML . React löst dieses Problem effizient über ein Schatten-DOM, und Angular geht es an, indem es die Bindung als einfache Möglichkeit verwendet, einen auf einer Seite angezeigten Wert zu ändern. Es kann jedoch auch ziemlich einfach gelöst werden, indem Sie die von Ihnen erstellten Knoten verfolgen und diejenigen speichern, die wiederverwendet oder in Variablen aktualisiert werden. Es gibt auch andere Gründe, sich generell von .innerHTML .

Die größten Mythen über das Programmieren ohne Frameworks

Zeit ist Geld. Ja, ich bringe dieses Konzept von früher zurück. Viele Leute haben das Gefühl, wenn sie aufhören, ein beliebtes Web-Framework zu verwenden, werden wir sofort zum Internet der 90er Jahre übergehen, als <marquee> jedermanns Lieblingstag war, rotierende GIFs auf einer Geocities-Site angesagt und kantig waren, Alta Vista war die erste Wahl. für Websuchen und Zugriffszähler waren allgegenwärtig.

Mit Web-Frameworks scheinen Ihre ersten Codezeilen viel Zeit zu sparen, aber irgendwann werden die Gewinne zu Verlusten. Sie verbringen Ihre Zeit damit, darüber zu lesen, wie Sie das Framework dazu bringen, Dinge zu tun, für die es nicht gebaut wurde, wie Sie Bibliotheken integrieren und sie dazu bringen, gut mit dem Framework zu spielen, und herauszufinden, dass der Code, den Sie erstellt haben, während Sie den Standards des Frameworks folgen, nicht funktioniert überhaupt funktionieren und jetzt müssen Sie es umschreiben. Wenn Sie Dinge ohne Rahmen tun, beginnen Sie langsamer, aber Sie machen stetige Fortschritte. Am Ende geht es darum, wo der einfache Teil sein soll. Es wird keinen großen Unterschied in der Gesamtzeit machen.

Mein Code wird länger sein als die Große Mauer. Schreiben ohne Framework ist wie das Kaufen eines Films, anstatt einen Streaming-Dienst zu abonnieren. Sie erhalten keinen sofortigen Zugriff auf Hunderte von Filmen, die Sie sich ansehen möchten, aber Sie müssen auch kein Geld für Tausende anderer Filme ausgeben, die Sie nicht einmal aus dem Store herunterladen würden. Sie können einfach schreiben, was Sie brauchen.

Ist der Mittelsmann sinnvoll? Sicher. Aber es ist normalerweise nicht notwendig . Jede Codezeile, die Sie schreiben, hat mehr Bedeutung, da Sie sich nicht an die Anforderungen eines Frameworks anpassen müssen. Es kann sich anfühlen, als würden Sie mehr Code mit reinem JavaScript schreiben, da die Art und Weise, wie die DOM-Elemente erstellt werden, Zeilen erfordert, um ein Element zu erstellen, es an das DOM anzuhängen und möglicherweise eine Klasse für das Styling hinzuzufügen, anstatt eine einzelne Zeile von aufzurufen Code in JSX. Aber wenn Sie Code mit einer Bibliothek wie jQuery oder React vergleichen, kann Vanilla JS in der Länge ziemlich ähnlich sein. Manchmal ist es länger, manchmal aber auch kürzer.

Das Rad muss nicht neu erfunden werden. Das Mantra der Informatikprofessoren überall. Und es ist wahr – es muss nicht speziell Frameworks bedeuten. Das Senden einer Ajax-Anfrage zum Laden oder Speichern von Daten ist beispielsweise in fast jeder Web-App erforderlich, aber kein Framework zu haben bedeutet nicht, dass Sie den Code jedes Mal neu schreiben müssen. Sie können Ihre eigene Bibliothek oder Codebasis erstellen oder Code von anderen extrahieren. Je kleiner es ist, desto einfacher ist es, es nach Bedarf zu ändern oder anzupassen. Daher ist es praktisch, wenn Sie etwas Bestimmtes für ein Projekt benötigen. Es ist einfacher, 100 bis 200 Codezeilen zu ändern, als durch den Berg von Dateien zu navigieren, die eine Bibliothek oder ein Framework eines Drittanbieters möglicherweise enthält.

Es funktioniert nur für kleine Projekte. Dies ist ein weit verbreiteter Mythos, aber überhaupt nicht wahr; Derzeit arbeite ich an einem kompletten System, um alle Aspekte eines Unternehmens online an einem einzigen Ort zu verwalten, einschließlich eines Moduls, das so etwas wie Google Drive ist. Ob mit Frameworks oder ohne, ich gehe sehr ähnliche Schritte durch und stoße auf sehr ähnliche Probleme. Der Unterschied ist vernachlässigbar. Ohne Frameworks ist mein gesamter Code jedoch kleiner und einfacher zu verwalten.

ICH WILL BEWEISE

In Ordnung. Lassen Sie uns aufhören, über Theorie zu sprechen, und zu einem Beispiel aus der Praxis springen. Vor einigen Tagen musste ich eine Liste von Marken mit Logos für ein Geschäft zeigen. Der ursprüngliche Code verwendete jQuery, aber es gab ein Problem, bei dem beim Laden in Mozilla ein defektes Bildsymbol für Marken angezeigt wurde, für die noch keine Logos hochgeladen wurden. Wir können den Shop nicht unfertig aussehen lassen, nur weil Firma X noch nicht mit der Arbeit fertig ist, aber das Feature benötigt wird, um live zu gehen.

Der folgende Code verwendet das jQuery-Äquivalent von .innerHTML :

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

Ohne zu tief auf die Vor- und Nachteile von jQuery einzugehen, besteht das Problem hier darin, dass wir keinen Bezug zu den von uns erstellten Bildern haben. Es gibt zwar Lösungen, bei denen kein Code geändert werden muss, aber nutzen wir diese Gelegenheit, um zu sehen, wie dies ganz ohne Bibliothek möglich ist:

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

Der ursprüngliche jQuery-Code war sechs Zeilen lang, während die Vanilla-JS-Lösung zwölf Zeilen brauchte. Um das Problem zu lösen, dauert es doppelt so lange, jedes Bild zu verstecken, bis es geladen ist. Schauen wir uns also die Alternative an. Kann es auch in jQuery gelöst werden? Hör zu:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

Mit ein paar zusätzlichen Codezeilen gibt es jetzt nur noch drei Zeilen Unterschied zwischen jQuery und Vanilla, aber bei jQuery können Sie sehen, dass die img_out -Zeile schnell sehr komplex wird, bis zu dem Punkt, an dem Sie anhalten müssen und überlege genau, was du tust. Die direkte Codierung des DOM durch die Verwendung von Knotenfunktionen zum Hinzufügen von Attributen, Funktionen und dergleichen ist möglicherweise länger, aber jede Zeile hat eine klarere und präzisere Bedeutung, wodurch sie in Zukunft einfacher zu lesen und zu warten ist.

Werfen wir einen Blick auf React:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

Diese Version ist eindeutig suboptimal. Der Code ist nicht kürzer als in Vanilla, und wir sind noch nicht einmal an dem Punkt angelangt, das Problem zu lösen und die Links zu verstecken, bis das darin enthaltene Bild geladen ist.

Für jedes Beispiel werden die Ergebnisse unterschiedlich sein. Manchmal ist jQuery kürzer. Manchmal gewinnt React. Es gibt Zeiten, in denen Vanilla JS kürzer sein kann als beide. In jedem Fall war das Ziel hier nicht zu beweisen, dass das eine dem anderen von Natur aus überlegen ist, sondern zu demonstrieren, dass es keinen signifikanten Unterschied zwischen der Verwendung von Vanilla JS und der Verwendung eines Frameworks gibt, wenn es um die Codelänge geht.

Fazit

Wie bei fast allen Problemen im wirklichen Leben ist nichts schwarz oder weiß. Das Programmieren ohne Webentwicklungs-Frameworks ist möglicherweise die beste Lösung für einige Ihrer Projekte und ein Alptraum für andere. Wie bei jedem Werkzeug liegt der Schlüssel darin, nicht nur zu lernen, wie man es benutzt, sondern auch wann und welche Vor- und Nachteile es haben könnte. Das Codieren in reinem JavaScript ist wie bei jedem anderen Framework – es zu beherrschen braucht Zeit, bis Sie sich sicher fühlen, es zu verwenden.

Aber der Hauptunterschied, zumindest für mich, ist, dass Frameworks kommen und gehen, und selbst wenn ein Framework lange Zeit beliebt ist, kann es sich von einer Version zur anderen dramatisch ändern. Reines JavaScript wird noch viel länger eine Option sein, bis es nicht mehr relevant ist und eine andere Sprache auftaucht. Selbst dann gibt es mehr Konzepte und Strategien, die Sie direkt von einer Sprache in eine andere migrieren können, als Sie es mit einem gegebenen Framework in eine andere könnten. Da Zeit und Aufwand in etwa gleich sind, wenn es um ein einzelnes Projekt geht, sind die Verringerung des Wissensverlusts und die Lektionen, die Sie für die nächste Herausforderung mitnehmen können, sehr wichtige Faktoren, die es zu berücksichtigen gilt.