Ist eine client-seitige UI-rendering via Javascript eine gute Idee?

Bin ich auf das hintere Ende des Gebäudes, nur diese Art von app. Es ist ein ExtJS GUI auf Zend Framework JSON-RPC-web-services, die Einführung einer iGoogle-gadget wie portal.

Vorteile:

• Sehr ansprechende UI, ExtJS bietet Ihnen eine großartige user experience.
• Sehr vorhersehbar client-server-Kommunikation. Alles ist json (einfach zu Debuggen). Es gibt standardisierte Fehlerbehandlung, die in der API (zumindest das ist, wie ich es entworfen hat).
• Das front-end ist austauschbar. Ich könnte schreiben, eine C++ - app, die auf der server-back-end. Trennung von front-end und back-end-über client-server-Linien bedeutet, Sie sind leichter zu prüfen unabhängig voneinander.
• Sie Leben und atmen javascript, das ist toll, wenn Sie es mögen.

Nachteile:

• Sie Leben und atmen javascript, die saugt, wenn Sie es hassen. In unserem Fall bedeutete dies eine große Umschulung der Entwickler-team, da waren wir PHP-schwer.
• Alles Leben in einem einzigen, langlebigen DOM, so haben Sie zu bleiben Sie auf Ihre Zehen mit memory-management und sicherstellen, dass Zeug bekommt ordnungsgemäß bereinigt. Auch, laden zu viel UI macht IE go "- ow, ow, du bist zu verletzen mein Gehirn".
• Es gibt kein laufen, eine schnelle Abfrage zum abrufen einer option in der Mitte der Generierung der Benutzeroberfläche. Das Programm-design-Einschränkungen Leben auf dem client sind entmutigend auf den ersten. Sie gewöhnen sich daran, aber es ist ein bisschen eine Hürde.
• Laden alle, die javascript bedeutet, dass Ihre Benutzer benötigen, um schnelle verbindungen und moderne Browser.

Treibende Grund für uns, dies zu tun war, um eine bessere user experience. Benutzer erwarten, dass ein desktop-ähnliches Erlebnis, und Sie können nicht liefern, dass über ein server-roundtrip. Wir Holen Sie zu liefern, dass jetzt, aber es ist nicht zu leugnen, es gibt große Herausforderungen, die mit einem Ansatz wie diesem. Insgesamt bin ich zufrieden, obwohl.

Update (september 2013):

Immer noch mit dieser Architektur und immer noch denken, es ist die richtige Architektur, wenn Sie eine echte web-Anwendung (nicht nur eine web-Seite mit dynamischen Funktionen). Unser team und das Produkt ist jetzt viel größer (kurz vor der 500.000 Zeilen code), aber die Architektur skaliert hat, ohne Frage. Es gibt nun wirklich viele gute, skalierbare javascript-frameworks (angular, ember, ...), so ist es einfacher als je zuvor, um auf diese Weise verabschieden zu arbeiten.

Da @rwoo gebeten, einige Herausforderungen, die wir noch haben:

• On-demand-laden der js-code wird zu einem problem schwieriger als vorgesehen. Es ist wichtig, sich mit diesem Teil zu Recht in die Architektur.
• Hatten wir integrieren die automatische jshint Validierung in einem pre-commit-hooks in subversion, weil js ist viel zu tolerant gegenüber Syntaxfehlern und Sie oft gar nicht bemerken dies, bis das Produkt die Kunden erreichen.
• Da die Datenbank auf dem anderen Ende der web-service-Anforderung müssen Sie sorgfältig entwerfen Sie Ihre web-service-API oder Sie werden am Ende mit miese Leistung durch warten auf zu viele XHR-Anfragen. Das ist lösbar, aber anspruchsvoll, und es wird nicht leichter mit der Zeit.
• Während Sie mit der rechten framework cross-browser-Probleme werden minimiert, Sie gehen nicht vollkommen Weg, was bedeutet, dass Sie brauchen, um zu testen in allen Browsern in allen Versionen. Das ist so viel Arbeit, dass Sie zum automatisieren Sie mit so etwas wie Selen, und es stellt sich heraus, das ist schwieriger zu tun, mit einem client-Seite gerendert, die Benutzeroberfläche, als ein server-side-UI gerendert.

Tools wie Google GWT tun, was Sie beschreiben - Rendern viel von der client-Seite in javascript. Einige der grobe layout wird immer noch nach unten, die mit HTML, aber die interessanten Teile fertig sind dynamisch, client-Seite.

Aber GWT verwendet erzeugt javascript, nicht von hand geschrieben. Dies zu tun mit der hand ist schmerzhaft.

Ich denke, es ist schrecklich. Schwer zu entwickeln. Schwer zu Debuggen. Schwer zu bekommen, die Funktionalität, die Sie wollen. Ich behalte lieber web-Anwendungen so einfach wie möglich und gehen für normale GUI-Anwendungen, wenn alles komplexer wird, benötigt.

Ich am Liebsten ein hybrid-Ansatz. Wenn eine Seite zum ersten mal angefordert, es soll gefüllt werden mit so viel Informationen wie möglich zu schließen, von der URL/Querystring/Post. Und dann werden alle nachfolgenden Zustandsänderungen abgefragt werden können und aktualisiert mittels Ajax.

Viele Menschen neigen dazu, den Ansatz einfach das laden der Seite, und dann lassen Sie die javascript - /ajax-die Arbeit des Ladens. Dies führt in der client wartet auf die Seite zu laden, und dann den client zu warten, für die Daten zu laden.

Viel besser, nur lassen Sie den server tun, dass die anfänglichen Daten geladen, und füllen Sie alle UI-Elemente.

Intern verbraucht line-of-business-apps, bei denen Sie kontrollieren können, den desktop, javascript Sinn macht.

Für externe /öffentliche zugängliche apps, wo Sie keine Ahnung haben, welchen browser Ihre Kunden verwenden, halten Sie es tot einfach und so wenig wie möglich.

Wenn Sie sagen, dass Javascript funktioniert einfach nun aufgrund der Rahmenbedingungen, das stimmt nicht ganz. IE 6 ist immer noch weit verbreitet, wie ältere Safari. Auch FF 2.x, und 1.x teilweise, hat angemessenen Anteil von den consumer-Markt.

Zusammen mit, dass, nicht jeder hat high-speed-internet, das ist so ziemlich eine Voraussetzung für viele dieser frameworks. Weiter, obwohl die meisten Bibliotheken funktionieren mit IE 7, es ist ein Hund für die meisten Operationen.

Auf das Thema Bibliothek Größe, haben wir eine Reihe von .net-Steuerelemente, die wie zu injizieren, bis zu 1MB von javascript an den client. Versucht zu senden, dass zu Oma.

Schließlich, Telefone abholen-Benutzer als primären internet-Zugang-Gerät. Leider ist die cache-Größe ist klein und für die meisten Teil, diese coolen javascript-Dinge, die nicht allzu gut funktionieren.