angular.js pros and cons
0 
dedlfix
0 0 0 
Der Martin
0
0 
Gunnar Bittersmann
0 0 dedlfix
angular.js pros and cons
Ich möchte gerne genau wissen, was sind die Vor- und Nachteile von agular.js (und Wiki)?
Vorteile:
- Erleichtert die Arbeit für Entwickler
Nachteile:
- Das ist eigentlich Sache von serverseitigen Scripten?!?
- Wieder eine Resource mehr zu laden
- vermixt Kompetenzen: logik in html
Würde gerne mal wissen, ob das "good practice" ist.
Cheers,
Baba
-
Tach!
Ich möchte gerne genau wissen, was sind die Vor- und Nachteile von agular.js (und Wiki)?
Vorteile und Nachteile lassen sich nur auf einen bestimmtes Anwendungsfall ermittlen. Es gibt keine allgemeinen Vorteile oder Nachteile. Definiere also bitte deinen Anwendungsfall. Der kann durchaus auch recht allgemein gehalten sein.
Nachteile:
Du zählst Argumente auf, die müssen nicht unbedingt Nachteile sein.
- Das ist eigentlich Sache von serverseitigen Scripten?!?
Bei einer Single Page Application (SPA) findet die Anwendung zum größten Teil im Browser statt. Der Server übernimmt vielleicht noch die Speicherung oder global zu koordinierende Aufgaben.
- Wieder eine Resource mehr zu laden
Ohne Angular oder generell Bibliotheken müsstest du den Code selbst schreiben, den diese mitbringen. Vielleicht ist da ein gewisser Prozentsatz unbenötigtes Zeug drin, aber der ist auch in deinem eigenen Code drin, wenn er nicht exakt und speziell auf deinen Anwendungsfall zugeschnitten ist.
- vermixt Kompetenzen: logik in html
Welche Logik ist den in Angulars Direktiven drin? Meinst du sowas wie ng-repeat? Und warum sollten die Ausgabe betreffende Anweisungen nicht im Ausgabeteil enthalten sein? Präzisiere doch bitte mal, was du genau mit diesem Punkt bemängeln möchtest.
dedlfix.
-
Ich möchte gerne genau wissen, was sind die Vor- und Nachteile von agular.js (und Wiki)?
Die Frage ob server- oder clientseitiger Programmlogik ist uralt. Alles hat seine Vor- und Nachteile. Nehmen wir das einfache Beispiel "Tabelle sortieren", wird sehr schnell klar: Hier liegt der Vorteil im Einsatz einer clientseitigen Technik, die Seite mit der Tabelle muss nicht neu geladen werden, ein Klick auf die Überschrift und schwubbs ist die Tabelle sortiert.
Oder Formulare zum Erfassen von Eingaben und Hochladen von Dokumenten, z.B. Bewerbungsformulare die sich über mehrere Seiten erstrecken: Wenn die Seite wechselt, also neu geladen werden muss, müssen die Daten serverseitig zwischengespeichert werden, i.d.R. in der Session bevor mit dem endgültigen Submit auf Seite 20 der ganze Kram irgendwo serverseitig persistent gemacht wird. Da kann ne Menge dabei schiefgehen, sei es, dass nur die Session wegfliegt und der Besucher auf Seite 19 die Meldung kriegt: "Ihre Session ist leider abgelaufen, bitte loggen Sie sich neu ein".
Eine clientseitige Technik kann eingegebene Daten und hochzuladende Dokumente auch lokal speichern, z.B. in localStorage, indexedDB, in einem Objekt oder der Benutzer hat einen "Speichern unter..." Dialog, wo er die bisherigen Eingaben sichern und die Arbeit spräter wieder aufnehmen kann, wobei er sogar den Browser schließen und den Rechner runterfahren kann. Klar, inner Session geht das nicht und ab zum Server gehts erst, wenn das Ränzlein mit den Daten vollständig gepackt und verschnürt ist.
Seitens MDN und auch MS wird diesem Trend Rechnung getragen, neue Features (JS, HTML5, XHR2, ArrayBuffer usw.) ermöglichen es, Anwendungen immer benutzerfreundlicher zu machen und ggf. auch einen nahtlosen Übergang von Off- zu Online und umgekehrt.
Ein Application-Cache ermöglicht, dass Ressourcen wie JSON-Dateien, JS-Code und auch Bilderchen lokal verfügbar sind, nachdem die Anwendung einmal online aufgerufen wurde (Setup). Es liegt auf der Hand, nicht etwa 300 oder mehr Seiten (10000 Artikel für einen Shop) für den AppCache zu manifestieren, sondern die "Einzelseiten" kompakt zu speichern, so dass sich ein Framework darim kümmert, was da gerade im Browser angezeigt wird, ohne einen neuen Request feuern zu müssen (siehe Beispiel Artikeldaten, als JSON auf Angular-Tutorials).
Würde gerne mal wissen, ob das "good practice" ist.
Wenns um das Entwickeln von SPA's geht: Setze ein Framework ein. Ob das Angular heißt oder Angela, ist egal. Nutze eine OpenSource, die ist dokumentiert und es gibt eine Community, so kommst Du auch zum Ziel.
MfG
-
Mahlzeit,
oder Angela, ist egal.
Nein, das ist nicht egal. Wenn ein Framework so heisst, würde bei einer identischen Abfrage jedesmal eine andere Antwort kommen und die wäre zu 99,9% gelogen.
--
42-
Hallo,
oder Angela, ist egal.
Nein, das ist nicht egal. Wenn ein Framework so heisst, würde bei einer identischen Abfrage jedesmal eine andere Antwort kommen und die wäre zu 99,9% gelogen.YMMD! :-D
Schönes Wochenende,
Martin--
"Hier steht, deutsche Wissenschaftler hätten es im Experiment geschafft, die Lichtgeschwindigkeit auf wenige Zentimeter pro Sekunde zu verringern." - "Toll. Steht da auch, wie sie es gemacht haben?" - "Sie haben den Lichtstrahl durch eine Behörde geleitet."
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( -
Mahlzeit,
oder Angela, ist egal.
Nein, das ist nicht egal. Wenn ein Framework so heisst, würde bei einer identischen Abfrage jedesmal eine andere Antwort kommen und die wäre zu 99,9% gelogen.
Ha :)
Ich kann mich an ein Script erinnern, das nannten wir vanGogh, das hat Daten für Statistiken bereinigt…
-
-
@@hotti:
nuqneH
Nehmen wir das einfache Beispiel "Tabelle sortieren", wird sehr schnell klar: Hier liegt der Vorteil im Einsatz einer clientseitigen Technik, die Seite mit der Tabelle muss nicht neu geladen werden, ein Klick auf die Überschrift und schwubbs ist die Tabelle sortiert.
Vorausgesetzt, sämtliche Daten sind bereits beim Client. Wenn irgendein Paging oder Nachladen im Spiel ist, muss sich doch der Server um die Sortierung (und Ausgabe der dann ersten Ergebnisse) kümmern.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer) -
Wenns um das Entwickeln von SPA's geht: Setze ein Framework ein. Ob das Angular heißt oder Angela, ist egal. Nutze eine OpenSource, die ist dokumentiert und es gibt eine Community, so kommst Du auch zum Ziel.
Vielen Dank für Deine Einschätzung und die Erklärung. Aber was ist, wenn es nicht um SPA (single page applications) geht?
Ich nehme das mal zum Anlass, mich auf angular.js einzulassen :) Weiß auch nicht, wo meine Abneigung gegen Frameworks begründet ist. Ich habe vielleicht schon zuviele gesehen, die die Welt nicht wirklich verbessern...
Cheers,
Baba-
Tach!
Aber was ist, wenn es nicht um SPA (single page applications) geht?
Du musst in jedem Fall entscheiden, ob ein Framework oder ein anderes für deinen Anwendungsfall Vorteile verspricht oder ob eine ganz andere Lösung geeigneter erscheint. Ich bezweifle, dass es da eine allgemeingütige Formel gibt. Eher muss hier eine gehörige Portion Kenntnis der Frameworks nebst Erfahrung und Bauchgefühl bei der Entscheidungsfindung zum Einsatz kommen.
dedlfix.
-
-