Responsive Design ist zur Zeit anscheinend das Allheilmittel, um mobile Varianten von Websites anzubieten. Zugegeben, es hat einige Vorteile, was die Wartbarkeit der Codebasis angeht und es ist auf den ersten Blick sehr charmant, nur ein einziges kombiniertes Set an HTML Templates verwalten zu müssen, das mit CSS Media Queries dann die jeweils richtige Darstellung auswählt.
Jedoch gibt es auch eine andere Sicht der Dinge. So haben 37signals bei der Entwicklung der mobilen Variante von Basecamp Next – ihrem Flaggschiff Produkt – eine parallele mobile Viewschicht gebaut, die heftig optimiert und vom Umfang her reduziert ist. In seinem Artikel beschreibt Jasons Zimdars, wie sie jeden einzelnen Screen angeschaut und für die mobile Benutzung optimiert haben, um die beste Performance herauszuholen. Er erläutert auch einige grundsätzliche Strategien und Überlegungen, die aus dem Projekt hervorgegangen sind.
Bei Basecamp Next betrifft die Optimierung auch „nur“ die Viewschicht. Models und Controller der Rails App werden weiterhin mitbenutzt. Somit hält sich der Overhead noch einigermaßen in Grenzen.
Das Ganze erinnert mich an die verschiedenen Ausgabekanäle bei Generierungs-CMS wie zB FirstSpirit, die für die verschiedenen Varianten dann auch noch statisches HTML (oder JSON oder XML oder oder oder) rauspusten und verschiedenste Anwendungsszenarien abdecken können. Hier bedeutet jeder Ausgabekanal ebenfalls zusätzlichen Aufwand und zusätzliche Templates.
Natürlich ist eine parallel zu betreibende Variante ein nicht zu unterschätzender Kostenfaktor beim Launch und auch im späteren Betrieb. Daher sollte man schon einen entsprechenden Anwendungsfall haben, in dem eine solche Optimierung entsprechend Sinn ergibt. Sollte dies der Fall sein, zeigt der Artikel, welche Performancegewinne bei einer dedizierten mobilen Variante zu realisieren sind.
http://37signals.com/svn/posts/3269-behind-the-speed-basecamp-mobile
Interessant ist auch der Artikel zur grundsätzlichen Performance von Basecamp Next und den verwendeten Technologien wie zB HTML5 pushState statt dem Neuladen von Seiten oder dem Hin- und Herschicken von JSON. Die Vorgehensweise grenzt beinahe schon an negatives „Partial Caching“ auf der Clientseite. Wobei auch die Caching Strategien im Detail erläutert werden. Viele der Optimierungen sind übrigens auch wieder in die öffentliche Rails Version zurückgeflossen.