Angular, React oder Vue, kann man das auch ohne Framework machen?

Findest du Frameworks unbedingt notwendig?

  • Ohne Frameworks kommt kein gutes Ergebnis bei raus und es ist schweiriger auf zu bauen

    Stimmen: 5 71,4%
  • Ohne Frameworks kann man einfacher arbeiten und auch alle Sachen machen wie mit Frameworks

    Stimmen: 2 28,6%

  • Umfrageteilnehmer
    7

BTCStorage

Ensign
Registriert
Mai 2020
Beiträge
166
Ich schaue mir zur Zeit Frameworks an wie Agular oder React und Vue und stelle mir zur Zeit eine Frage, der Sinn von diesen Frameworks, soweit ich das richtig verstanden habe, soll ja sein das man einfacher etwas aufbauen kann was sonst mit normalen Javascript so zu sagen unuebersichtlich wird.

Gibt es den aber irgendwelche Sachen die man mit normalen Javascript nicht machen koennte und nur mit den Frameworks machen kann?

Und vor allem funktioniert den das was man dann mit einem Framework baut immer besser und schneller als mit normalen Javsscript, oder gibt es da keine Nennenswerte Performance Unterschiede, oder ist die Performance sogar mit Frameworks immer etwas langsamer als bei normalen Javascript?

Ich habe gernerell nichts gegen die Frameworks, ich will nur gerne verstehen ob ich die unbedingt brauche, weil wenn ich mit normalen Javascript schon gut zurecht komme und auch alle Sachen damit bauen kann, dann fehlt mir ein wenig der Grund Frameworks ein zu setzen?
 
Die Antwortvorschläge passen nicht - man kann ohne Frameworks arbeiten, es bedeutet aber nicht, dass dabei kein gutes Ergebnis rauskommen kann. Es kann (muss aber auch nicht) schwieriger oder besser gesagt umfangreicher sein (weil man quasi von 0 aufbaut).

Es kommt halt immer auf das konkrete Projekt an. Ein einfaches kleines Projekt muss man nicht zwingend auf ein großes Framework aufbauen, wenn man das Framework nicht kennt und sich erst in dieses einarbeiten muss. Da kann es sinnvoller sein, sich einfach das Wissen anzueignen, was man für das kleine eigene Projekt braucht.

Kennt man das Framework allerdings schon, kann auch das kleine Projekt noch schneller und leichter von der Hand gehen, wenn man es einfach mit dem Framework umsetzt, anstatt das Rad neu zu erfinden.

Eine pauschale Aussage kann man nicht treffen. Heinz-Otto, der keine Ahnung von nichts hat, und auch nicht plant, sich in Zukunft stärker damit zu beschäftigen, würde ich für sein kleines Mini-Projekt wohl nicht zu einem umfangreichen Framework raten.
Hat er wiederum Interesse, dann könnte genau dieses kleine Mini-Projekt ideal sein, um sich erste Grundlagen anzueignen.
 
  • Gefällt mir
Reaktionen: DubZ, breedmaster, kim88 und 2 andere
Deine Antwortvorschläge zeigen schon, dass du dich noch mehr einlesen musst..
Das ist keine Ja / Nein Frage.
 
  • Gefällt mir
Reaktionen: kim88
Um deine erste Frage zu beantworten:
BTCStorage schrieb:
Gibt es den aber irgendwelche Sachen die man mit normalen Javascript nicht machen koennte und nur mit den Frameworks machen kann?
Nein, soweit ich weiß nicht, weil die frameworks ja auch nur javascript sind.



Zu deiner Abstimmung: ich denke hier fehlt der wichtigste Punkt: "Kommt auf den Einsatzzweck an" -> Für eine kleine Web-App, die ein paar Berechnungen durchführt, brauche ich sicher kein framework, wenn wir in der Firma eine große Seite machen mit einigen Modulen an der mehrere Entwickler arbeiten, erleichtert ein Framework halt das Arbeiten, weil es u.a. eine Struktur vorgibt, aber gehen tut es auch ohne.
 
Die Frameworks sind selbst in Javascript geschrieben und benutzen intern auch die normalen DOM-Funktionen von Javascript wie document.createElement() um die Seite zusammenzubauen.

Der Sinn besteht dabei halt da drin, dass du es dann nicht mehr machen musst. Man kümmert sich nur noch darum, was unter welchen Bedigungen angezeigt werden soll, indem man in der stark an HTML angelehnten Templatesprache eine Bindung an entsprechende Variablen anlegt. Ändern sich diese, wird das DOM entsprechend angepasst.

Zudem hat man eine stark standardisierte Vorgehensweise und vorgegebene Struktur, die von jedem verstanden wird, der das Framework kennt.
Wenn man die DOM-Operationen selbst macht, wird das entweder schnell unübersichtlich oder aber deutlich aufwändiger, weil man entsprechenden Code selbst bauen und kapseln muss.

Zur Performance: Gut optimiert dürfte die eigene Lösung schneller sein, da keine Änderungserkennung nötig ist. Die Frameworks sind in der Hinsicht aber recht gut optimiert (wenn man selbst keinen Mist baut :D), sodass dies keine große Rolle spielt.
Und wenn man anfängt selbst die DOM-Operationen zu kapseln und möglichst generisch zu machen, ist die eigene Performance vermutlich schnell schlechter ;)
 
Lar337 schrieb:
Zur Performance: Gut optimiert dürfte die eigene Lösung schneller sein, da keine Änderungserkennung nötig ist.
Die kann man auch in jedem Framework deaktivieren bzw. an die Anforderungen anpassen.

Grundsätzlich ist das kein Argument. Die 5% Performance, die man theoretisch sparen könnte, sind für 99,9% der Anwendungsfälle uninteressant. Und für unerfahrene Entwickler gilt eher das Gegenteil: Mit reinem JS wird der Code unübersichtlicher, fehleranfälliger, Bedarf mehr Wartung und wird im Zweifelsfalls sogar langsamer, weil die Frameworks natürlich auch haufenweise Optimierungen vornehmen, die man gerne mal vergisst oder derer man sich überhaupt nicht bewusst ist.

Ich setze selbst für die popeligsten Seiten auf React (auch gern mal in Form von Gatsby), weil es stupide einfach ist und man das Wissen immer wieder gebrauchen kann, egal ob es am Ende nur ein Formular mit Validierung ist, oder eine riesige Anwendung.

Vor Jahren habe ich noch auf Angular geschworen. Aber ich muss sagen: Da tut sich nix. Also eigentlich genau das was man von einem Enterprise Framework erwartet. Aber(!) für Enterprise sind mir da persönlich doch zu große Schwachstellen enthalten, vor allem in den Formularen. Da muss man erst mal sein eigenes Framework um das Framework bauen, damit man damit halbwegs komfortabel arbeiten kann.

Vue 3 habe ich mir noch nicht wirklich angesehen, aber die Previews und Talks sahen schon vielversprechend aus.
 
Verstehe, also ist der Hauptzweck fuer diese Frameworks das man damit schneller etwas bauen koennte, ich hatte schon hin und wieder gedacht das man damit vielleicht bestimmte Sachen machen kann die ohne Framework nicht gehen.

Was ist den wenn man sich selbst Javascript Bibliotheken erstellt mit Funktionen die man immer wieder verwenden kann, ist das dann im Prinzip genauso wie ein Framework, mit dem Vorteil das man es halt selbst erstellt hat und direkt versteht und nicht erst in die ganzen Regeln vom Framework lernen muss?


Lar337 schrieb:
DOM-Operationen zu kapseln

Was kann man den genau dadrunter verstehen, hast du ein Beispiel wie sowas aussieht?
 
Vermutlich würde man anfangen, häufiger genutzte Dinge zu kapseln.
Beispielsweise das Erstellen einer Liste aus einem Array.
Man übergibt eine Liste und die Funktion baut eine entsprechendes DOM-Objekt.
Die Liste über createElement() erzeugen, die Listenelemente über createElement erzeugen(), die Listenelemente mit appendChild() an die Liste hängen und dann die Liste an die richtigte Stelle im DOM.

Wobei da schon das erste Problem auftritt: Wie parametrisiert man die Funktion, damit man die Listenelemente selbst anpassen kann. Beispielsweise ein kleines Icon mit einbaut. Man bräuchte irgendwie eine Templatesprache.

Dann ruft man diese Funktion immer dann auf, wenn sich das Array ändert (was man irgendwie erkennen muss).

Irgendwann stellt man dann fest, dass das performancemäßig nicht so toll ist, da man ständig die Liste entfernen und neu aufbauen muss. Bei einer großen Liste ist das im DOM ein Performancefresser, insbesondere wenn nur ein Element entfernt oder hinzugefügt wurde.
Man benötigt also irgendwie eine Änderungserkennung, um möglichst große Teile wiederverwenden zu können und mit möglichst wenig Änderungen im DOM zum gewünschten Ergebnis zu kommen.
Auch hier ist es nicht die schnellste Lösung, die Liste direkt im DOM durchzuwandern. Schneller ist es, wenn man sich eine Art Kopie des DOM erzeugt, in der man Informationen zu allen Elementen einträgt, die man erzeugt hat. Dies vergleicht man dann mit dem, was man nun erzeugten müsste und identifiziert nun die Änderungen. Nur diese Änderungen nimmt man entsprechend am DOM vor.

Oder man benutzt einfach eines der Frameworks...
 
Habe ich schon mal gehoert, DOM Elemente Kopie und so Sachen.

Ich benutzte eigentlich meistens Ajax Funktionen, wenn jemand ein Knopf klickt wird aus der Datenbank mit PHP gelesen und die Ausgabe von PHP als HTML zurueck gegeben und dann mit Javascript ins DOM Dokument eingebaut. Und mit einer SetTimeout Funktion kann man ja jede Sekunde neu nachschauen in der Datenbank ob sich was geaendert hat, ich denke die Frameworks werden auch Settimeout Funktionen benutzen muessen wenn die eine Aenderung finden wollen.
 
Jede Sekunde Datenbank fragen? Das wird aber schnell zum DOS....

Ich finde, selber gebaut und Framework haben beide seine Berechtigungen.
- Wer nicht selber baut wird nie erfahren was da geht und wie.
- Wer hingegen alles immer selber baut wird nie von den vielen vielen Mannstunden profitieren, die in jedes der verfügbaren Frameworks eingeflossen sind.

Dazu kommt natürlich noch eine gewisse Disziplin beim Entwerfen. Frameworks verwenden heißt eine Abstraktionsebene zwischen sich und sein Ergebnis einfügen zu müssen - das ist in den allermeisten Fällen eine gute Sache.

Performance ist sicherlich ein etwas schwierigeres Thema, aber da muß man glaub ich einfach abwägen zwischen den Vorteilen und den Nachteilen. Kurz, wenn ein konkreter Anwendungsfall zu lange dauert, dann läuft da was schief; die Frage ist dann, was man anders/besser machen kann, damit das nicht mehr der Fall ist.

Das Framework als solches ist da meistens nicht selbst schuld dran, eher der Umgang damit; und dann ist es auch egal ob man das selber schlecht gezimmert oder ob man die Komponenten des Frameworks ungünstig zusammengesetzt hat.


Oder anders: "HTML ist auch ein Framework." Man beschreibt mittels vorgegebener Bauteile, was man haben will.
Per dieser Annahme kann man selbstverständlich auch ohne HTML Webinhalte haben, indem man den Kontext selber baut.

Die Argumentation Pro und Contra wäre an der Stelle fast exakt dieselbe.
 
  • Gefällt mir
Reaktionen: KitKat::new()
BTCStorage schrieb:
Was ist den wenn man sich selbst Javascript Bibliotheken erstellt mit Funktionen die man immer wieder verwenden kann, ist das dann im Prinzip genauso wie ein Framework, mit dem Vorteil das man es halt selbst erstellt hat und direkt versteht und nicht erst in die ganzen Regeln vom Framework lernen muss?

Im Prinzip ja. Im Grunde hast du ja die selbe Frage auch im PHP Bereich - alles sleber schreiben oder ein Framework wie Laravel oder Synfonie nutzen. Es gibt halt einfach viele Methoden die man in allen Projekten immer wieder braucht und repetativ sind und da machen Frameworks Sinn.

Bedenke auch, wenn du selber schreibst musst du deine Code Basis über Jahre anpassen. Neue ES Standards, Build Tools die plötzlich veraltet sind usw, bei Frameworks lebst du da einfacher.
 
Ich glaube eure Kommentare haben mich jetzt davon ueberzeugt das Frameworks doch Sinnvoll sind, man kann es auch ohne bauen, aber ich verstehe jetzt das die bereits fertig optimierte Frameworks Codes einfach besser funktionieren koennen, weil mehrere Leute das schon optimiert haben
RalphS schrieb:
Jede Sekunde Datenbank fragen? Das wird aber schnell zum DOS....
Gut das du das ansprichst, ich habe erst vor kurzen mit Leuten diskutiert ueber das Thema, was waere wenn jede Sekunde 100 oder mehr Benutzer eine Anfrage an meine Datenbank senden ueber den Aufruf einer PHP Datei, ob das nicht nach einem DDOS Angrif aussieht, die meisten Leute meinten das die Datenbank viel viel mehr aushaelst als paar 100 oder 1000 Anfragen pro Sekunde.

Was ist den die optimalste Weise wie man das baut wenn man beispielweise dem Benutzer der Webseite zeigen will sobald im ein anderer Benutzer eine Nachricht in sein Postfach schreibt. Wenn man jede Sekunde im Postfach des Benutzers nachschaut geht das natuerlich, aber am optimalsten waere es eigentlich wenn das Postfach von der Datenbank aus informiert wird das eine neue Nachricht da ist, also etwas in Richtung Websockets, oder?
 
BTCStorage schrieb:
Gut das du das ansprichst, ich habe erst vor kurzen mit Leuten diskutiert ueber das Thema, was waere wenn jede Sekunde 100 oder mehr Benutzer eine Anfrage an meine Datenbank senden ueber den Aufruf einer PHP Datei, ob das nicht nach einem DDOS Angrif aussieht, die meisten Leute meinten das die Datenbank viel viel mehr aushaelst als paar 100 oder 1000 Anfragen pro Sekunde.
Das hängt sehr, sehr stark von der Query, der Hardware und dem Framework drumherum ab. Auf vernünftiger Hardware ist es kein Problem mehrere Tausend Queries pro Sekunde zu machen, wenn diese Queries relativ einfach sind und indexiert (z.B. eine Zeile nach Primary Key holen). Das Webframework auf dem Server darf halt auch nicht limitieren, was bei schwachen CPUs und interpretierten Sprachen sein kann, aber auch nicht muss.

Auf einem kleinen vServer sieht das wieder anders aus, da hat man einfach wenig Leistung. Datenbanken skalieren generell gut mit mehr Kernen, aber das hilft nicht wenn man nur einen Kern hat. Und wenn die Query etwas langsamer ist, oder die DB nicht ins RAM passt, dann wird es auch schnell sehr viel langsamer.

Einmal pro Sekunde pollen ist schon recht viel, das ist eher etwas was man z.B. bei Chat Anwendungen machen würde. Das würde ich generell nicht direkt auf die DB gehen lassen, außer es sind wirklich wenige Clients. Wenn man so pollt, eher mit größerem Abstand wenn möglich. Die moderne Lösung sind da sowieso Websockets, dann kann der Server Bescheid sagen wenn es was neues gibt, ohne Polling.
 
Dalek schrieb:
Die moderne Lösung sind da sowieso Websockets, dann kann der Server Bescheid sagen wenn es was neues gibt, ohne Polling.

ja das meine ich auch, es ist ja im Prinzip nur eine Notloesung wenn man jede Sekunde nachschaut weil man nichts verpassen will, vielleicht kommt den ganzen Tag aber keine Nachricht und man verschwendet nur Resourcen. Da wuerde es auch nichts bringen wenn man die vielen Anfragen jede Sekunde ueber ein node.js Server macht statt ueber PHP und Apache oder? Die Mysql Datenbank wuerde trotzdem zu viel Arbeiten auch bei Einsatz von node.js? habe den Vorteil von Node.js dort noch nicht ganz so gut verstanden, ich weis nur das es irgendwie gut einsetbar ist wenn viele Sachen gleichzeittig gemacht werden sollen.
 
Falls nicht schon geschehen, mal bei http2 gucken und dort insbesondere bei Server Push.

Clientseitiges polling ist immer erstmal problematisch. Evtl reicht es aber auch, wenn Daten nicht jederzeit 100% aktuell zur Verfügung stehen.
 
RalphS schrieb:
Falls nicht schon geschehen, mal bei http2 gucken und dort insbesondere bei Server Push.
Chrome hat Server Push vor kurzem wieder entfernt, das hat sich nie durchgesetzt und hat nie so gut funktioniert wie man sich das mal gedacht hatte.
 
Ich denke Websockets sind schon optimal fuer solche Aufgaben und ich kann nur vermuten das Frameworks das im Hintergrund auch so machen, wenn man beispielweise Usern neue Emails anzeigen lassen will. Weil mit einer Wiederholungsschleife so wie ich das bisher gemacht habe, kann das ja jeder bauen aber das ist zu viel Resourcenverbrauch.

https2 hoert sich auf den ersten blick sehr interessant an, danke fuer den Tipps, das kannte ich auch noch nicht.
 
Der ganze React/Angular-Mist ist das Passende für die Fire-and-Forget-Klitschen. Schnell mal Seiten zusammen geschustert und dann bitte nie wieder was von hören wollen. Alles nur kurzlebiger Hipster/Millennials Hype-Unfug.
 
  • Gefällt mir
Reaktionen: BTCStorage
GroMag schrieb:
Der ganze React/Angular-Mist ist das Passende für die Fire-and-Forget-Klitschen. Schnell mal Seiten zusammen geschustert und dann bitte nie wieder was von hören wollen. Alles nur kurzlebiger Hipster/Millennials Hype-Unfug.
Danke fuer deinen Beitrag, deine Meinung gefaellt mir sehr gut, verstehe ich dich richtig das du Frameworks unnoetig findest? Findest du nicht das man bei gewissen Sachen durch Frameworks Zeit spart und besser optimierte Scripte einsetzen kann?
 
Was GroMag anspricht ist eher die Herangehensweise vieler, die diese Frameworks nutzen, um Zeit zu sparen und "mal eben" eine Website hochziehen, die letztendlich vielleicht 10% von dem braucht, was das Framework anbietet. Allerdings ist das auch sehr reißerisch formuliert und die Formulierung lässt vermuten, dass es eine allgemeine Abneigung gegen diese Art von Frameworks oder das Javascript-Ecosystem gibt.

Das Problem ist häufig, dass gar nicht mehr Grundlagen gelernt werden, sondern direkt React/Vue/Angular. Was anfangs weniger problematisch ist, sich aber nach einiger Zeit, bei komplexeren Setups als schwierig erweisen kann. Ein Framework schützt nicht vor schlechter Programmierung und schlechtem Design. Schau dich mal in entsprechenden Subreddits um und du wirst merken, dass dort häufig dieselben Anfängerfragen auftauchen, die auch in reinen Javascript-Foren stehen könnten. Es fehlt einfach häufig an Grundlagen und es wird einfach auf den Hype-Zug aufgesprungen, ohne zu wissen wieso. Ich denke jeder sollte anfangs mal versuchen eine dynamische Website im größeren Stil zu entwickeln, um dann zu erkennen, weswegen diese Frameworks überhaupt existieren.

Allerdings haben diese Frameworks natürlich auch aus bereits genannten Gründen schon ihre Daseinsberechtigung, gerade im Firmenumfeld mit einer großen Anzahl von Entwicklern. Sicher werden einige ihre Projekte mit eigenem Code hochziehen, was jedoch häufig auch in die Entwicklung eines eigenen Frameworks ausartet und diese Wartung sehr viel Zeit und Geld kostet.

Wie gesagt ist die Kritik an Frameworks berechtigt, gerade was Anfänger betrifft, allerdings wird man im Enterprise-Umfeld nicht drum herumkommen.
 
  • Gefällt mir
Reaktionen: calluna, breedmaster und KitKat::new()

Ähnliche Themen

Zurück
Oben