Mobile Performance – doch eine eigene mobile Variante?

Basecamp Mobile

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

Basecamp Next

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.

http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui

Pick Your Battles – Mature Technology is worth something

Zef Hemel von Cloud9 IDE, bzw. jetzt LogicBlox hat einen interessanten Artikel über Softwareentwicklung und Technologieentscheidungen geschrieben.

Er weist darauf hin, dass es einen Unterschied gibt, ob man eine Technologie einsetzt, weil sie dem Projekt hilft oder ob man sie einsetzt, weil man die Technologie ausprobieren möchte.

Seiner Meinung nach hat man zwei Optionen:

  • Eine geile App mit einer langweiligen, bewährten Technologie bauen
  • Eine langweilige, bewährte App mit einer Cutting-Edge Technologie bauen

Aus seiner Sicht verkraften die wenigsten Projekte beides…

  • Eine langweilige App mit langweiliger Technologie sorgt für Langeweile und Unmut bei der Entwicklung
  • Eine Cutting-Edge App mit Cutting-Edge Technologie birgt zuviel Komplexität und zuviele Unwägbarkeiten

Ein interessanter Standpunkt. Wie seht ihr das?

Der Artikel ist sehr umfangreich und bietet eine Menge Stoff zum Nachdenken.

Pick Your Battles by Zef Hemel

In summation:

  1. Don’t underestimate the value of mature technology. Things will break, and you will have to fix them. It’s bad enough if your own code is a problem, it’s worse when the problem is a poorly understood “feature” of your platform of choice.

  2. Don’t optimise prematurely. Don’t choose C because it’s faster. Don’t use MongoDB because, supposedly, it scales better. Don’t cache until you’re sure you have to.

  3. Be pragmatic. Technology like node.js and Redis have many great uses. If you hit one of their use cases: limit their scope to what makes sense. There’s no need to go all-in at all costs.