S
SideWinder schrieb:
Was ist bspw. mit so Dingen wie Projektverwaltung, Lagerverwaltungen, etc. die es auch wie Sand am Meer zum Programmieren gibt.
github, chiliproject, jira,... sind alles MPA.
Hier wird öfters aufgeteilt: die einzelnen Widgets (zB Terminplanung, Tickets, Repo,...) sind per MPA verbunden aber jeweils selber in sich als SPA gelöst. Oft überwiegt aber der Vorteil der einfachheit von MPAs.
MPA sind so viel komplexer? Warum? Weil JavaScript schwieriger "schön" zu programmieren ist wie C#? Die Frameworks sollten ja eigentlich gut unterstützen, ist das alles noch nicht so ausgereift?
Weil das Web nicht ganz so cool ist wie eine Desktop App.
Ein Problem ist zB das Laden der Resourcen. Du lädst bei Dekstop Apps einfach am Anfang alle Resourcen in den RAM, das ist schnell und RAM ist billig. Das geht im Web nicht. Man kann nicht alles laden und schon garnicht im RAM halten. RAM in Webanwendungen ist teuer weil es den Browser träge macht.
Das bedeutet nun, dass man komplexe Systeme verwendet um On Demand bzw. Predictive die Sachen zu laden - nun muss man hier aber mit Fehlern und Verzögerungen rechnen. Es ist zB nicht möglich einen Dialog zu Laden und gleich Listener drauf zu hängen - da der Dialog ja noch nicht existiert. Da muss man dann komplexe Systeme verwenden. zB ist machina hier ein cooles System.
Ein anderes Problem ist, dass man viel Code doppelt hat. Du hast deine Datenmodelle auf der Serverseite und auf der Clientseite. Die musst du korrekt synchron halten. Aber jeder request vom Client auf den Server kann fehlschlagen - was du immer miteinberechnen musst.
Ein anderes Problem ist es den State zu speichern. idR will man Deep-Links ja erlauben, also benutzt man hash-Tags in der URL um den State anzugeben - das kann aber tricky werden wenn man zB den User Optionen setzen lassen will. Man kann nicht alle Optionen in die URL packen, ergo kann man den Zurück Button im Browser nicht mehr gut unterstützen - was passiert aber nun wenn der User zurück drückt? idR findet kein neuer Request statt sondern der Browser geht einfach so zurück wie er denkt dass es sinnvoll wäre - wenn aber Daten auf den Client geschrieben wurden (local storage, cookies, per session auf der server seite) so wird das nicht invalidiert - was bedeutet dass der User recht leicht in ungültige States kommen kann, wenn man nicht gut aufpasst.
Während neue Request in MPAs immer schön alles resetten und man keine Fehler mitschleppen kann. zB kann man leicht in SPAs ein Element verstecken und vergessen es später wieder anzuzeigen weil plötzlich irgendein Vater Element eine Klasse hat die er eigentlich nicht haben dürfte weil irgendein Untermodul seine Klassen nicht korrekt resettet hat.
Oder ganz blöd: was passiert wenn der User einen Link in einem neuen Fenster aufmacht und plötzlich 2 Fenster mit selben State hat und dort dann unterschiedliche Aktionen tätigt...
Das sind alles natürliche Probleme die sich umgehen lassen, keine Frage - aber sie erhöhen die Komplexität der Anwendung. Und dann ist auch immer die Frage nach dem Vorteil: was genau bringt es denn eine Single Page zu haben? Klar ist es toll wenn man Roundtrips sparen kann, aber das ist nur die halbe wahrheit. Denn roundtrips habe ich auch bei SPAs - ich spare mir lediglich boilerplate Transferdaten. Das wirkliche Probleme im Internet sind aber Latenzzeiten und weniger Bandbreite - da man die Bandbreiten eh ganz gut niedrig halten kann.
Man hat durch aggressives cachen und gzip eh sehr minimale Datenübertragen. SPAs fühlen sich dafür oft schneller an (was sehr wichtig ist) da die Aktionen zuerst Feedback geben und dann arbeiten, während es bein MPAs ja so ist, dass zuerst die Arbeit kommt und dann das Feedback (Seite geladen).
Ich denke deshalb, dass die richtige Mischung wichtig ist. Twitter gefällt mir hier zB sehr schön. Es gibt einzelne Feature-Seiten die dann aber jeweils eine SPA sind.