Auch wenn die Vertreter der Client-Seite den Kampf um die Frage, wo Views künftiger Web-Applikationen gerendert werden, schon lange gewonnen haben, so bleiben doch einige Diskussionspunkte offen. Was wird aus Suchmaschinen, Javascript-Verweigerern und den Nutzern von schwacher Hardware oder alter Browser? Der Schritt zur Client-Side-Web-Application ist an Konsequenzen geknüpft, die nicht jeder in Kauf nehmen möchte. Ich halte immer die Augen nach Projekten offen, die das Rendern sowohl auf Server als auch Client mit möglichst wenig Overhead ermöglichen.
Das Pakyow-Projekt erfüllt diese Anforderung nicht, zeigt aber einen interessanten Ansatz für Views. Sicher nicht der erste oder gar einzige seiner Art, aber einer mit konkreter Umsetzung. Zudem scheint eine weitere Entwicklung in Richtung Client- und Server-Seite möglich, da Entwickler Bryan Powell bei dem Thema recht euphorisch wirkt.
<article data-scope="post"> <h1 data-prop="title">My First Post</h1> <div data-prop="body">Lorem ipsum dolor sit amet</div> </article>
Das einfache Beispiel führt dabei zum selben Ergebnis wie das folgende HAML-Beispiel, nur dass die obigen Data-Attribute für spätere Updates erhalten bleiben.
- @posts.each do |post| %article %h1= post.title %div= post.body
Man beachte die Each-Schleife: Das obige Template erzeugt das Article-Element für jeden Post der Datenquelle.
Das obige Beispiel hat gegenüber der HAML-Notation entscheidende Vorteile.
Der Template-Entwickler kann die Templates mit beliebigen Inhalten befüllen (siehe oben „My First Post“) und ohne Backend-Logik ein sinnvolles Ergebnis sehen. Template und Backend sind besser getrennt.
Der wesentliche Vorteil ist aber, dass das Template mit einfachen Datenstrukturen, üblicherweise einem JSON-Dokument, bestückt werden kann. Eine solch relativ einfache Template-Engine ließe sich für Server (z. B. in Ruby) und in Javascript für den Client realisieren. So kann der Server den mit korrekten Werten befüllten View ausliefern. Weitere Updates würde er nur als JSON schicken, welches der Browser anhand der gegebenen Data-Notationen ins DOM einbaut.
Der Backend-Entwickler muss sich somit nur noch um die JSON-Struktur sorgen. Ob die Response als HTML oder JSON ausgeliefert wird, ließe sich weitgehend im Framework abstrahieren.
Für mich als Rails-Gefangenen ist das Hauptproblem mit Pakyow, dass es Rails ersetzen statt ergänzen würde. Einen Ansatz zur Integration konnte ich bisher nicht finden, so dass hier eigene Überlegungen notwendig wären.