Welches JavaScript-Framework wird von dir bevorzugt?
Ich habe mich eine Zeit lang mit Angular beschäftigt, bin dann vor circa zwei Jahren auf Vue (Nuxt) umgestiegen. Ich bin im Großen und Ganzen zufrieden, jedoch nutzt Vue zum Teil ältere Paketquellen. Auch der TS-Support ist jetzt nicht der Beste, warum React bei mir gerade wieder etwas mehr in den Fokus rückt.
Die Job- und somit Verdienstmöglichkeiten sind bei Angular und React auch besser, als es bei Vue der Fall zu sein scheint. Letzteres war mir schon zu Beginn klar, was mich aber nicht abgeschreckt hat, mich doch intensiver mit Vue zu befassen. Die Umfrage hier ist für mich eher nebensächlich. Viel mehr interessieren mich eure Pros und Contras, die entweder für oder gegen eines dieser Frameworks sprechen.
- Welches Framework verwendest du und warum?
- Wieso hast du dich oder habt ihr euch für eben jenes Framework entschieden?
Das Ergebnis basiert auf 8 Abstimmungen
2 Antworten
Guten Tag,
Zuerst einmal muss ich sagen, dass ich von Vue keine Ahnung habe, das Framework daher nicht beurteilen kann.
Ich habe vor etwa anderthalb Jahren mit React begonnen. Der Funktionsumfang ist meiner Meinung nach recht überschaubar, was sich positiv auf die Lernkurve auswirkt. Konzepte wie der State, der Lifecycle und Hooks müssen verstanden werden. Hat man dieses Konzept aber einmal verinnerlicht und ist damit vertraut, macht die Entwicklung von Websites auf Basis von React Spaß. Ein weiterer wichtiger Bestandteil der React-Library ist für mich JSX sowie das Virtual-DOM. Ich persönlich habe es lieber, wenn ein Framework sämtliche Funktionalitäten (etwa einen HTTP-Client oder einen Router) von Haus aus mitbringt. Bei React muss man auf Libraries von Dritten setzen, etwa react-query für HTTP oder den React Router für das Routing. Aber React ist halt "nur" eine Library, kein umfangreiches Framework.
Vor ungefähr einem halben Jahr habe ich dann mit Angular begonnen. Das Konzept von Komponenten ist insofern kein anderes, als das von React. Jedoch gefällt mir die strikte Trennung von Template und Komponenten-Logik deutlich besser. Anstelle von JSX steht die Template-Syntax von Angular zur Verfügung, in der Interpolation, Direktiven, Bindings und Pipes zur Verfügung stehen. Besonders zu schätzen weiß ich die Strukturdirektiven wie ngIf oder ngFor, mit deren Hilfe Elemente konditional gerendert bzw. Elemente anhand eines Arrays erstellt und dynamisch "gefüllt" werden können. Auch muss zur Aktualisierung des Templates nicht der für die Komponente geltende State aktualisiert werden, wie es in React der Fall ist. Stattdessen reicht es aus, die in der Klasse definierte Eigenschaft zu ändern, was die Entwicklung sehr komfortabel macht. Die ChangeDetection von Angular sorgt dafür, dass die Anpassungen am Template durch eine solche Aktualisierung minimal gehalten wird. Reicht diese automatisch durchgeführte Detection nicht aus oder entspricht nicht den Anforderungen des Entwicklers, kann sie auch durch diesen beeinflusst werden. Angular hat als ausgereiftes Framework bereits alles an Board, was man sich für die Entwicklung moderner Single Page Applications nur wünschen kann: Einen HTTP-Client, einen Router, Module für Formulare und (komplexe) Animationen. Ich genieße einfach diesen Komfort bei der Entwicklung, ohne auf irgendwelche Libraries Dritter angewiesen zu sein.
Die Bundle-Size einer Angular Applikation ist im Regelfall größer als die einer React Applikation. In meinen Augen bringen diese im 2-stelligen KiB-Bereich liegenden Größenunterschiede aber kaum einen nennenswerten Nachteil, beachtet man die heutige Internetgeschwindigkeit.
Ich habe React schon lange nicht mehr angefasst. Dennoch ist es eine recht schlanke und hilfreiche Library, mit der komplexe Webanwendungen entwickelt werden können. Angular jedoch kommt meinen Anforderungen viel näher, weshalb ich in diesem Bereich nur noch mit Angular arbeite.
Letztendlich ist ein Vergleich zwischen Library und Framework nicht unbedingt sinnvoll. Die Modularisierung und das Gesamtkonzept von Angular-Applikationen haben mich allerdings überzeugt.
MfG Heinzfred
Sehr gerne. Angular ist mit TypeScript eben sehr eng verzahnt, ebenso mit RxJS für die reaktive Programmierung. Das bedeutet zwar alles mehr Lernaufwand, aber umso mehr macht mir die Entwicklung Spaß. Wolltest Du Angular einfach mal ausprobieren, oder warst du nicht so überzeugt?
Wolltest Du Angular einfach mal ausprobieren, oder warst du nicht so überzeugt?
Für den größeren Lernaufwand fehlte mir zumindest damals einfach die Zeit und schlussendlich von Vue samt Nuxt und dessen schnellen Lernkurve "angefixt" wurde. Bis dato habe ich eher an mittelgroßen Projekten gearbeitet, bei denen die Skalierbarkeit auch nicht allzu sehr im Fokus stand.
Meinerseits besteht jedenfalls Interesse, dass ich mir auch in anderen Frameworks fundiertes Wissen aneigne. Mit Angular habe ich bereits etwas herumgespielt, bin dann aber wie gesagt erst einmal bei Vue/Nuxt gelandet. Was aber nicht heißt, dass Angular dadurch weniger interessant für mich ist oder wäre.
Deine Antwort hat mich jedenfalls positiv überrascht, da ich hier auf GF nicht mit so einer ausführlichen Rückmeldung gerechnet habe. Kannst du zu Angular zufällig gute Fachlektüre empfehlen? Das meiste ziehe ich mir zwar aus der Dokumentation, trotzdem finde ich es ganz gut, hier und da mal in einem Buch nachzuschlagen. Falls du also dahingehend einen Tipp hast, bitte her damit.
Ich danke Dir erstmal für den Stern auf meine Antwort!
Ich helfe gerne weiter und natürlich habe Fachlektüre parat, die ich bestens empfehlen kann. Ich persönlich belese mich lieber in einem Fachbuch, statt die offizielle Dokumentation zu lesen. Diese ist zwar sehr umfangreich, macht das Lernen aber insofern schwieriger, als dass die Inhalte meist nicht strukturell aufeinander aufbauen und viele nützliche Kniffe nicht erläutert werden. Man weiß also oft nicht so recht, wo man anfangen und aufhören soll.
Prinzipiell habe ich 2 recht umfangreiche Angular-Werke bei mir, in denen ich den Großteil gelesen habe.
Meine absolute Empfehlung ist dieses Buch hier vom dpunkt-Verlag. Das Wissen wird zunächst sehr verständlich erklärt, bevor es in einem Beispielprojekt angewendet wird, das in jedem Kapitel kontinuierlich erweitert wird. Es wird vor allem auch sehr detailliert auf TypeScript und die Library RxJS eingegangen, die fester Bestandteil einer Angular-Anwendung sind. Die besagten Kniffe und Antipatterns werden ebenfalls aufgezeigt. Mit diesem Buch macht das Lernen von Angular Spaß.
Ich bin da auch nicht anders und helfe ebenfalls gerne weiter, sofern ich den etwas beitragen kann. Auch dazu sage, dass ich damals eher aus der grafischen Ecke kam und zufällig als Quereinsteiger in den Bereich hinein geschubst wurde.
Ich sage nur Tabellen-basierte Layouts mit Microsoft Frontpage, WYSIWYG-Geschubse in Dreamweaver, allerlei Baukasten-Gedöns, bis dann irgendwann der Funke übergesprungen ist. Meine IDE ist seitdem wie mein zweites zu Hause und dabei auch mal die Zeit um mich herum vergessen kann.
Man weiß also oft nicht so recht, wo man anfangen und aufhören soll.
Ich weiß, was du meinst. Das war auch mit ein Impuls, warum ich hier nachfrage, auf welches Framework ich mich konzentrieren soll. Mir hilft es vorab daher ungemein, wenn ich mich mit Menschen austausche, die bereits dieses oder jenes Tool nutzen und bereits etwas mehr dazu schreiben können.
Den Stern habe ich dir auch nicht gegeben, weil deine Antwort bisher die einzige ist, sondern weil sie wirklich geholfen hat. Eben, weil ich auch lieber Template und Logiken voneinander trenne und bis dato nicht wusste, wie es in React diesbezüglich ausschaut. Angular und Vue sind sich ja doch ähnlich, bei React wusste ich es zunächst nicht. Was sich aber dank deiner Hilfe geändert hat.
Es wird vor allem auch sehr detailliert auf TypeScript und die Library RxJS eingegangen, die fester Bestandteil einer Angular-Anwendung sind.
Da ich jetzt noch nicht so lange mit TypeScript arbeite, ist es schon mal gut zu wissen, dass auch darauf detailliert eingegangen wird.
Was mich an dieser Stelle auch noch interessieren würde, wie "kleinschichtig" deine Komponenten angelegt werden. Brichst du das Ganze bis auf eine Link-Komponente herunter oder arbeitest du eher mit größeren Blöcken? Ebenso wüsste ich gerne, wie du es in puncto CSS (SCSS) handhabst.
Ich habe es in Vue/Nuxt eigentlich immer so gemacht, dass zumindest meine Variablen, Mixins und Funktionen global eingebunden werden. Meine Komponenten bekommen dann Grundformatierungen mit, die dann ggf. beim Einbinden individualisiert werden. Ich nutze BEM und setze dann halt einen Modifier - für letzteren wird dann das SCSS "gescoped".
Guten Abend,
Entschulige die recht späte Rückmeldung. Bezüglich deiner Frage zu den Komponenten kann ich von mir aus nur sagen, dass man ein gesunden Mittelmaß finden muss. Es kommt natürlich immer darauf an, inwieweit der Code wiederverwendet werden soll. Für die einzelnen Sektionen einer Website, also etwa Header und Footer, lege ich immer eine separate Komponente an. Man muss sich im Voraus immer ein wenig Gedanken machen, ob man die Funktionalität und das Aussehen eines Links oder Buttons beispielsweise in einer oder mehreren Komponenten wiederverwenden möchte. Bei Buttons zumindest macht das oft Sinn, denn diese sollten im Großen und Ganzen einheitlich gehalten werden. Das sollte aber nur bis zu einem bestimmten Punkt in einer geteilten Komponente verpackt werden. Möchte ich den Button im selben Design aber mit verschiedenen Größen wiederverwenden, so ist das mit einer Komponente natürlich vollkommen in Ordnung. Die Komponente bekommt die Größe des Buttons als Information (in Angular per Property-Binding) übergeben und stellt diesen in der gewählten Größe dar. Unterscheiden sich die Buttons allerdings in mehrerern Eigenschaften bis hin zu Funktionalität, so ist die verschiedene Darstellung durch unübersichtliche Fallunterscheidungen in der Komponente eher kein guter Ansatz. Hier sollte man dann doch separate Komponenten entwerfen.
Prinzipiell ist der Gedanke, viele kleine Komponenten zu entwerfen, keine schlechte Idee. So erreicht man meist eine gute Wiederverwendbarkeit und vermeidet unnötig große Templates in einer Datei, was die Übersicht und Wiederverwendbarkeit doch sehr stark erschweren kann.
Ich persönlich nutze Tailwind-CSS. Ich arbeite also mit Klassen im Template, die Tailwind-CSS zur Verfügung stellt und schreibe kaum eigene Style-Regeln. Da es sich um ein sehr umfangreiches CSS-Framework handelt, werden alle nicht benötigten Klassen nicht mit in die fertige CSS-Datei übernommen. Sollten doch einmal eigene Styles notwendig sein, können diese wie üblich in die CSS-Datei geschrieben und anschließend verwendet werden.
LG
Guten Morgen,
alles gut und halb so wild, da ich selber auch nicht immer sofort reagiere. Man sitzt ja nicht 24/7 am PC und selbst wenn, bestimmt der Alltag, ob und wann man sich die Zeit zum Schreiben von Kommentaren nehmen kann. Von daher, alles gut.
Es kommt natürlich immer darauf an, inwieweit der Code wiederverwendet werden soll.
Ich habe mir im Laufe der Jahre ein eigenes Framework erstellt, welches eigentlich immer als Basis für neue Projekte dient. Sobald neue Technologien dazu kommen, wird manches davon adaptiert oder ich schreibe es entsprechend um.
Für die einzelnen Sektionen einer Website, also etwa Header und Footer, lege ich immer eine separate Komponente an.
Ich handhabe es eigentlich nicht anders. Bei mir gibt es globale Komponenten, wo Aufbau und Aussehen eigentlich gleich bleibt. Ich passe maximal Typografie, Farben und ähnliches an das CD an, sofern denn ein solches existiert.
Möchte ich den Button im selben Design aber mit verschiedenen Größen wiederverwenden, so ist das mit einer Komponente natürlich vollkommen in Ordnung.
Ich nutze in Sass/SCSS mindestens eine config.scss, in der mithilfe von Variablen gesteuert wird, ob z.B. Buttons eckig, abgerundet oder rund dargestellt werden. Layouts baue ich dann überwiegend in Schwarz/Weiß resp. in Graustufen zusammen. Farben werden dann zum Schluss hinzugefügt, sei es für CTA, Branding (CD Farben, Schriften etc.).
Prinzipiell ist der Gedanke, viele kleine Komponenten zu entwerfen, keine schlechte Idee.
Ich habe anfangs noch normalize, modernizr oder das HTML5 Boilerplate verwendet, mittlerweile lasse ich derlei Dinge aber meist weg. Was auch daran liegt, dass der Support für ältere Browser schon fast obsolet geworden ist. Sei durch Update-Zwang und kürzere Update-Zyklen bei Browsers.
Ich persönlich nutze Tailwind-CSS. Ich arbeite also mit Klassen im Template, die Tailwind-CSS zur Verfügung stellt und schreibe kaum eigene Style-Regeln.
Ich nutze Tailwind-CSS seit etwa drei Monaten, schreibe aber auch eigenes CSS bzw. SCSS. Als Namenskonvention wird BEM genutzt, was mit SCSS oder einem Preprocessor schon für mehr Ordnung sorgt. Ich bin allerdings ein Freund der Sass-Syntax, da ich für HTML gerne Pug nutze. Ich spare mir also in beiden Sprachen einiges an Schreibarbeit. Die SCSS-Syntax nutze ich eigentlich nur, wenn ich bei einem Projekt nicht alleine für die Entwicklung zuständig bin.
LG
Ein eigenes Framework? Das klingt spannend!
Mit Sass oder SCSS habe ich bislang kaum beschäftigt, das Konzept mit Variablen vermeidet aber sicherlich einige Redundanzen.
Mit Pug habe ich auch mal gearbeitet, es ist ein wenig gewöhnungsbedürftig, aber man spart sich viel Tippabreit.
Was steht eigentlich noch so auf Deinem Lernplan? Ich finde ja Go recht vielversprechend als Alternative zu NodeJS für's Backend.
LG
Ein eigenes Framework? Das klingt spannend!
Mein Framework wird im Grunde durch Funktionen, Features und/oder nützliche Snippets angereichert, die ich irgendwann einmal für mich selber oder für Projekte erstellt habe. Vorteil für mich, ich muss nicht erst in eine Dokumentation schauen, um zu wissen, wofür nun diese oder jene "Komponente" ist.
Jedoch fairerweise dazuschreibe, dass nicht alles von mir selber stammt. Ich schnappe hier und da Techniken und Lösungsansätze auf, schreibe sie ggf. für meine Zwecke um und adaptiere es letztendlich, um bei Bedarf wieder schnell darauf zugreifen zu können. Letztendlich ein Langzeitprojekt, um mir bei zukünftigen Projekten sowohl Arbeit als auch Zeit zu sparen.
Mit Sass oder SCSS habe ich bislang kaum beschäftigt, das Konzept mit Variablen vermeidet aber sicherlich einige Redundanzen.
Mit SCSS wird CSS auf Steroide gesetzt und dank Mixins, Funktionen, @if Kontrollanweisung kann man ziemlich "nice" Sachen anstellen. Sei es das Genieren von Klassen samt beliebiger Eigenschaften. Bei Pug ist es nicht anders, nur dass dort halt HTML anstelle von CSS "erweitert" wird. Aber Pug kennst du ja bereits.
Was steht eigentlich noch so auf Deinem Lernplan? Ich finde ja Go recht vielversprechend als Alternative zu NodeJS für's Backend.
Auf meinem Lernplan steht zunächst eine Vertiefung in Python samt Django, gefolgt von Kotlin und Swift - zumindest solides Grundlagenwissen. Go hatte ich auch auf dem Schirm, der Tag hat dafür aber einfach zu wenig Stunden. Daher denke ich, dass ich erst einmal mit Python und Django weitermache.
LG
Guten Morgen,
Techniken zu übernehmen ist doch volllommen legitim. Wenn ich etwa mein Backend in NodeJS entwickle, setze ich in diesem Sinne auch auf bewährte Libraries wie Express, statt den Webserver aufwändig selbst zu implementieren.
Ich habe schon etwas fortgeschrittenere Kenntnisse in Python, ist aber schon ein wenig her. Serverseitig bestimmt sehr spannend, vor allem im Bereich KI macht Python ja eine gute Figur. Syntaktisch auch ganz angenehm. Mich erstaunt immer wieder, mit wie wenig Code man zum Ziel kommt.
Ich bleibe noch ein wenig in der Webentwicklung, möchte aber gern wieder ein wenig mit C durchstarten und meine Assembly Kenntnisse erweitern. Das Arbeiten mit Registern und die enge Zusammenarbeit mit dem Arbeitsspeicher reizt mich schon ein wenig.
LG
Hallo! In den letzten 1,5 Jahren habe ich mich hauptsächlich auf Next.js und React konzentriert und finde, dass es in Bezug auf die Entwicklererfahrung kaum etwas Besseres gibt. Vor etwa 3 Monaten habe ich jedoch begonnen, mich auch in Vue einzuarbeiten, insbesondere mit dem Ziel, Nuxt zu beherrschen.
Der Auslöser dafür war, dass mit dem Next App-Ordner keine animierten Pagetransitions mehr möglich sind. Diese Einschränkung gilt spätestens seit React 18 auch für Gatsby. Auf der Suche nach einem Tool, das meine Anforderungen an hochwertiges Design für einfache statische Websites erfüllt, bin ich bei Nuxt und Vue gelandet.
Seitdem verwende ich Next.js 14 für Full-Stack-Anwendungen und Nuxt für hochwertige Websites. Obwohl ich die Entwicklererfahrung in Vue und Nuxt etwas herausfordernder finde, schätze ich Nuxt sehr, weil es mir die gestalterische Freiheit bietet, die meine Kunden sich wünschen.
Vielen Dank für Deine ausführliche Antwort. Ich habe halt bei der Entwicklung mit Vue zunehmend festgestellt, dass häufiger mal gewisse Pakete nicht so aktuell sind, wie sie eigentlich sein könnten. Da Nuxt wiederum auf Vue aufsetzt, ist "TS" etwas, was mich zum Nach und Umdenken bewegt hat.
Ich stimme Dir zu, dass ein Vergleich zwischen Library und Framework nicht unbedingt sinnvoll ist. Daher sind mir Eure eigenen Erfahrungsberichte umso wichtiger, sofern Ihr mit einem oder mehren diesen Tools bereits gearbeitet habt. Gerade bei Libraries von Dritten sehe ich halt das Problem, dass genau jene schnell mal Zeitaufwand verursachen, der eigentlich nicht sein müsste.
Nochmals vielen Dank an Dich für Deinen lesenswerten Beitrag.
LG medmonk