Mein Kollege Roland Jülich hatte sich vorgenommen, dieses Jahr auf die Devoxx zu fahren. Und wie es so ist, wenn man selbst in spannenden Projekten ist, hat sich bei uns ewig kein Zweiter zum Mitfahren gefunden. Da ich Konferenzen immer gern nutze, um mir neue Sichtweisen und Techniken nahebringen zu lassen, und da die Devoxx einen sehr guten Ruf hat, waren die Vorfreude und natürlich auch die Erwartungen sehr hoch. Im Beitrag wird auf die Inhalte der zwei Vorträge des ersten university days eingegangen: Play und HTML5 and JavaScript Web Apps.

Play Framework – Crash Course

Technical stuff

In diesem Slot bekamen meine Erwartungen gleich mal einen derben Dämpfer. Ich habe ihn besucht, weil ich null Ahnung von Play habe, aber gehört habe, dass es sich lohnt, es sich mal anzuschauen und weil ich natürlich wissen wollte, warum es jetzt noch ein Framework mehr gibt und wozu ich es einsetzen könnte.

Genau diese Fragen wurden mir in der ersten Hälfte des Slots von Peter Hausel nicht beantwortet. Er fragte zwar nach, wer denn schon alles Play nutze und wer komplett neu war (ich war nicht allein), stieg aber gleich in die Technik ein und erzählte, was man beim Deployment (Code Balancer, Jenkins, automatisch etc.) und beim Projekt-Layout beachten sollte. Danach wurde kurz über project templates, plugins, global setting, client-side technology support und effective testing gesprochen.

Ich habe kurz bereut, in den Slot gegangen zu sein und sah mich schon bei einer der Parallelveranstaltungen, die Java-Entwicklern iOS-Entwicklung beibringen wollte.

Zum Glück wurde der dreistündige Vortragsslot in zwei Teile mit kleiner Pause gesplittet

Realtime web

Nach der Pause betraten dann Sadek Drobi und Guillaume Bort die Bühne und beantworteten genau die Fragen, auf die ich Antworten erwartet habe.

Was?

Sie wollen mit dem Pay Framework einfacheres Entwickeln von Web Applikationen erreichen. Mit dem Fokus auf Einfachheit und Leichtigkeit, basiert auf einer leichtgewichtigen, zustandslosen, webfreundlichen Architektur.

Warum?

Klassische Webanwendungen wurden mit dem Fokus ein User = 1 Thread entwickelt; dies entspricht so aber nicht den Anforderungen an eine moderne Webanwendung. So sprechen sie bei Play von einem reaktiven Model in dem sie mit futures arbeiten. Sie können also z.B. 500 Requests in 500 Frames machen und sobald eine Antwort da ist, diese an alle 500 kommunizieren – „work happens when it needs to happen“.

Play ist folglich nichtblockierend und reaktiv. Interessant ist dabei, dass sie bewusst nicht sagen, dass Play asynchron ist, da ihrer Meinung nach für den Nutzen der Asynchronität auch immer ein hoher Preis gezahlt werden muss und nicht entscheidend ist, ob man asynchron ist, sondern welche Werkzeuge den Entwicklern dazu zur Verfügung gestellt werden. Ihr Werkzeug sind futures.

Realtime web?

Realtime web bedeutet eine kontinuierliche Interaktion zwischen Servern und Clients. Dies kann durch long polling, comet, web sockets und server sent events erreicht werden.  Nützlich ist das Ganze z.B. bei der Realisierung vom Peer-Austausch von Daten z.B. in einem Chat, um Informationen zu streamen (z.B. für ein Monitoring und für MapReduce). Play nutzt für dieses Streaming Web Sockets.

HTML5 and JavaScript WebApps

In der  zweiten 3-Stunden-Session führte Wesley Hales den Browser als Plattform ein – interessanter Ansatz. Nachdem er auf die Nachteile von Web Apps versus native Apps auf mobilen Endgeräten einging (kein Adressbuch, keine Kamera), gab er einige gute Gründe an, warum man sich um Web Apps mit JS und HTML5 Gedanken machen sollte. Es gibt wohl schon 2013 mehr mobile Endgeräte als stationäre, in einigen Schwellenländern sind die Menschen fast nur mit mobilen Endgeräten online, und selbst im Office legt man jetzt Wert auf performante Browser-Applikationen, sofern man natürlich eine „office capability“ hat.

Was ändert sich jetzt? Erst einmal, „Android default browsers suck“, denn Android Browser sind der neue Internet Explorer 6 in der mobilen Welt und „code quality matters“. Das sollte jetzt zwar eigentlich keinem Entwickler neu sein, aber da gibt es ja unterschiedliche Ansichten… denn die Qualität des Codes z.B. des CSS entscheidet über die Batterielaufzeit oder einfachere Payload, und guter Code fördert auch gute SEO. Neu ist auch, dass es neben unterschiedlichen Browsern und unterschiedlichen mobilen Betriebssystemen (Android, iOS, Firefox OS etc.) auch unterschiedliche Funktionsweisen von Browsern gibt. So arbeitet der eine, Opera (Mobile vs. Mini), mit HTML5  und der andere rendert voroptimierte Seiten, auch Amazon macht es so auf seinen Kindles. Bei dieser Vielzahl von Optionen rät Wesley, nicht jede Plattform und jeden Browser unterstützen zu wollen und bei den Browsern stets nur eine Version zurück zusätzlich zu unterstützen.

Er selbst hat jetzt den Begriff HTML5E eingeführt. Na, wofür stets das E? Es gibt ja genug Leute, für die das Wort Enterprise der heilige Gral ist, Wesley machte aber nicht so den Eindruck, auch wenn er schon bei JBoss gearbeitet hat.

Innerhalb seines HTML5E hat er eine ganz nützliche Library zur Verfügung gestellt, slidfast.js, mit der man spaßige Sachen wie network detection, AppCache Zugriff und link prefection machen kann.

Nach einem kurzen Ausflug zu den Werkzeugen, die HTML5 und die W3C API zur Verfügung stellen (WebSockets, WebWorkers, Orientation, WebStorage), kam Hales auch auf das Thema Performance zu sprechen. Dabei gab er die üblichen Ratschläge, wie CDN, JSON und WebStorage zu nutzen. Bei CNN konnte er so die Daten, die über das Netz fließen, auf 17% reduzieren, und CNN lädt nun in 6,3 Sekunden komplett. Schaut man sich da Seiten anderer Nachrichtendienste an, ist das ein akzeptabler Wert. Um die Performance zu messen, stellte er Phantom.js vor.

Fazit

Allein der erste Tag hat sich schon gelohnt. Ich weiß nun, welches MVC-Framework ich mir auf jeden Fall anschauen werde, wenn ich irgendwo große Datenmengen streamen muss und habe einmal mehr richtig Lust bekommen, mich weiterhin intensiv mit HTML5 und JS zu befassen. Am zweiten Tag schaue ich mir an, was Java Social bringt und ob ein Mensch von Google mir Neues zum Thema Web Performance sagen kann.