Client- oder serverlastige? Web-Applikationen

[SideWinder]

Wenn ich jetzt eine größere Web-Applikation schreiben möchte...worauf soll ich setzen?

Glaubt ihr die Sache bleibt eher serverlastig, sprich bspw. ASP.NET MVC und in die HTML-Seiten dann im Nachhinein ein bisschen jQuery einbauen für verbessertes UI-Feeling?

Glaubt ihr die Sache wird eher clientseitig werden, sprich Data-Services (bspw. via REST mit ASP.NET WebAPI) anbieten und den Rest am Client fabrizieren, ergo Einsatz von Angular.js/Knockout.js und Konsorten unter Einsatz von neuen HTML5-Technologien.

Wohin bewegt sich die Industrie? Hängt das vom Einsatzzweck ab? Wann würdet ihr zu welcher Richtung tendieren und warum? Was verspricht Entwicklungs-Effizienz bei gleichzeitiger Nachhaltigkeit?

MfG SideWinder

[Shade Of Mine]

Das haengt davon ab was du haben willst.
Wenn es eine wirkliche App sein soll die im Browser laeuft, wirst du das eher JavaScript lastig angehen muessen. Dann sind Knockout, Backbone, etc. deine Freunde.

Aber viele Webanwendungen haben nicht diese Anforderungen an den Rich-Client Bereich. Dann reicht jQuery und jQueryUI mit vielleicht etwas canJS oder dergleichen.

Prinzipiell brauchst du aber dennoch ein starkes Backend - denn im Endeffekt muss das skalieren und flexibel sein. Da gibt es aktuell eigentlich 3 Loesungen:
fuer kleine Sachen wird oft gerne node.js genommen (was mir persoenlich weniger gefaellt) oder micro frameworks wie Slim oder Silex.
und fuer die mittleren Sachen gibt es Symfony mit PHP und wenn es ganz gross wird Rails und Java-Loesungen.

Prinzipiell machen wir zB alles mit Symfony und das Frontend dann spezialisiert auf die Anforderungen mit jQuery und einer passenden unterstuetzenden Library. Wobei wir aktuell noch Libs wie zB canjs testen ob die uns da weiter helfen koennen.

Also im Prinzip zusammengefasst: das Backend muss auch bei JS-lastigen Apps stark sein. uU reichen Microframeworks. Einen grossen Trend gibt es hier aber nicht. Rails ist etwas abgefallen nach dem riesen Hype, ist aber dennoch noch weit verbreitet. Bei PHP gibt es eigentich nur Symfony und .NET mag man nicht nehmen weil kein Mensch Windows Server ins Netz stellen mag. Bleibt Java, damit habe ich aber wenig Erfahrung.

Im Frontend Bereich hat sich noch nichts als Standard etabliert. Es gibt Knockout, Backbone, Ember, SproutCore, etc. Prinzipiell die ganze Liste die man bei TodoMVC findet. Hier fehlt noch der grosse durchbruch von einer Library... Wobei ich hier, wenn ich frisch anfangen wuerde wohl zuerst einmal einen Blick auf Maria werfen wuerde.

Im Endeffekt ist es so, dass aktuell Frontend und Backend sehr stark entkoppelt sind. Und das wird sich wohl auch wenig aendern in absehbarer Zeit. Der Backendbereich ist weitgehend stabil aber der frontend bereich ist aktuell stark fragmentiert und es hat sich noch nichts wirklich rauskristallisiert.

Man ist sich noch nichtmal einig ob JavaScript der richtige Weg ist oder CoffeeScript/TypeScript/Dart hier nicht sinnvoller waeren. Dann tut sich bei CSS auch eine Menge, was viele Feature die bisher in JS zu implementieren waren wieder unnoetig macht.

Der einzige Trend den ich hier kenne ist requireJS - der Trend die einzelnen Libraries sich so zusammenzusuchen wie man sie braucht. Aber gerade mit Predictive Loading und Konsorten - da tut sich aktuell so viel... Schwer was vorherzusagen.

[SideWinder]

Wir haben tatsächlich IIS großflächig im Einsatz, da die Projekte auch sehr groß sind dementsprechend auch ASP.NET statt Java.

Was hältst du persönlich von Angular.js? Das hast du als einzige größere MVC-JS-Library nicht aufgezählt.

Sollten Single-Page-Applikationen nicht durchwegs besser performen als ständige Komplett-Roundtrips zum Server? Wo erfahre ich etwas über die Nachteile von SPAs? Warum quasi überhaupt noch eine klassische Web-Applikation schreiben wenn Performance ein Nachteil ist?

MfG SideWinder

[Shade Of Mine]

SideWinder schrieb:

Was hältst du persönlich von Angular.js? Das hast du als einzige größere MVC-JS-Library nicht aufgezählt.

Ich habe damit keinerlei Erfahrung. Ich kenne Backbone und Knockout etwas, aber die Fülle an MVC Libraries ist so groß... Da wirst du auch kaum Leute finden die alle Libs relativ gut kennen.

Das Problem ist wie gesagt, dass sich noch nichts durchgesetzt hat. Es gibt keine Library die wirklich besser ist als die anderen.

Sollten Single-Page-Applikationen nicht durchwegs besser performen als ständige Komplett-Roundtrips zum Server? Wo erfahre ich etwas über die Nachteile von SPAs? Warum quasi überhaupt noch eine klassische Web-Applikation schreiben wenn Performance ein Nachteil ist?

Die Anforderung ist die Frage. SPAs sind deutlich komplexer und Fehler in der Anwendung können sich böse verschleppen.

Wenn ich aber zB ein GMail schreiben wollen würde, würde ich das als SPA machen. Wenn es aber darum geht Content anzubieten wie, zB sagen wir Tumblr - dann will ich lieber mehrere Seiten haben.

Das Problem mit einer einzelnen Seite ist vorallem: SEO. Es ist nicht wirklich gut möglich Suchmaschinen dazu zu bringen solchen Webapps gut zu crawlen. Man kann sich natürlich mit komplexen Sitemaps helfen und so, aber im Endeffekt wird das nichts tolles werden.

Deshalb ist das alles eine Frage der Anforderung. Und nicht vergessen: eine SPA ist wirklich viel viel komplexer als eine MPA.

Prinzipiell macht man meistens ein Mischding. zB wenn du einen Registrierungprozess hast, der 3 Steps hat, so ist dieser Prozess auf einer Seite während der Rest der App aber multiple Seiten hat. Diese Konzepte sind also auch nicht sich widersprechend.

Meine Frage deshalb erstmal:
über was für Apps reden wir hier eigentlich? Desktop Apps die ins Web geschoben werden, werden eher SPAs werden während Content anbietende Apps eher MPAs bleiben werden. Wobei, wie gesagt, es keine wirkliche Grenze gibt sondern man beiede Konzepte mischen kann.

[SideWinder]

Shade Of Mine schrieb:

Meine Frage deshalb erstmal:
über was für Apps reden wir hier eigentlich? Desktop Apps die ins Web geschoben werden, werden eher SPAs werden während Content anbietende Apps eher MPAs bleiben werden. Wobei, wie gesagt, es keine wirkliche Grenze gibt sondern man beiede Konzepte mischen kann.

Ganz allgemeine Frage, geht um kein konkretes Projekt, habe nur erst vor kurzem davon gehört, mich nun etwas eingelesen und möchte nun Vor- und Nachteile kennen lernen - am besten von Leuten die es verstehen und nicht von den SPA-Technology-Providern

GMail-artig -> SPA
Content-Provider -> MPA, weil SEO

Was ist bspw. mit so Dingen wie Projektverwaltung, Lagerverwaltungen, etc. die es auch wie Sand am Meer zum Programmieren gibt.

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?

MfG SideWinder

[Shade Of Mine]

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.