Working Draft

Wöchentlicher News-Podcast für Webdesigner und -entwickler

Spenden für Soundqualität!

Unsere Aufnahmen werden optimiert mit Auphonic.
Flattern oder direkt bei Auphonic spenden.

Revision 205: Perceived Performance, Ampersand.js

31. Januar 2015 | Keine Kommentare

Zur 205. begrüßen Anselm und Stefan Schrödingers Co-Host (ist er aktiv, ist er es nicht?) Kahlil Lechelt wieder im virtuellen Studio. Die (Wieder-)Entdeckung eines vielversprechenden Frameworks hat ihn zurückgerufen.

[00:01:03] News

IO.js
Node.js ohne Node.js? Ein Open Source Fork der JavaScript-Umgebung beschäftigt die Szene. Dieser Beitrag klärt auf.
Firefox 35
Allerlei sinnvolle Neuerungen in der 35er Version des Fuches.

Schaunotizen

[00:04:40] Perceived Performance & fetch()
Folgender Gedankengang: Ein Polyfill zum kommenden fetch-Befehl wird veröffentlicht und kommt gut an (in Kürze: verdauliches XHR mit Promies). Ein gewisser Steve Souders bringt seine Meinung, dass es doch ideal wäre mit diesem Standard auch Ladebalken steuern zu lassen, um dem User eine gewisse Geschwindigkeit anzuzeigen, oder im schlimmsten Fall vorzugaukeln. Hat bei eBay ja auch gut funktioniert. Wir sprechen — im Vorgaukel-Falle — von unseren eigenen Erfahrungen und überlegen, wie so ein Standard ideal aussehen könnte.
[00:26:46] Ampersand.js
Aufgepumptes Backbone.js mit saftiger Tool-Chain im Hintergrund? Kahlil hat Ampersand für sich entdeckt und schwärmt uns im Beinah-Monolog entsprechend vor. Wer damit noch nichts zu tun hatte bisher, und sich nicht irgendwelchen Hype-Frameworks verschrieben hat, sollte durchaus einen längeren Blick darauf werfen. Ebenso erwähnt: Jade als Templating-Language und das Buch der AmpersandJS Entwickler Human Javascript.

[00:55:18] Keine Schaunotizen

GitHub Cheat Sheet
Was mit Git und GitHub doch alles möglich ist. Tolle Kniffe, die oft unentdeckt bleiben.

Revision 204: Fokus, Build-Tools, Links

22. Januar 2015 | Keine Kommentare

Wer keine spannenden Themen hat, muss eben selbst spannend sein. Und so grillten Hans, Peter, Stefan und Anselm Fokus-Forscher Rodney zu seinen neuesten Forschungsergebnissen und wärmten kurz (und ohne nennenswerten Erkenntnisgewinn) die große Build-Tool-Debatte wieder auf.

Schaunotizen

[00:00:15] Neues von der Fokus-Front
Nach seinem ersten Bericht in Revision 198 meldet sich Rodney wieder zu Wort und berichtet von neuen Erkenntnissen aus seinem Fokus-Forschungs-Projekt, speziell von neuen Erkenntnissen rund um Shadow DOM, <dialog>, Canvas-Element und <video>. Letzteres ist interessanterweise je nach Browser unterschiedlich zu bedienen. Tabindex in Shadow DOM funktioniert in Chrome auf sinnvolle Weise, ist in Firefox (wie auch der Rest von Shadow DOM) noch buggy. In <dialog> wirken sich die bekannten Probleme von Image Maps verwirrend aus. Die Fokussierbarkeit von Canvas-Subtrees könnte für Focus Transitions genutzt werden. Aus Rodneys bisherigen Erkenntnissen lassen sich drei Empfehlungen ableiten:

  1. Repariert Browser-Bugs mit Rodneys Scriptsammlung
  2. niemals positiven tabindex benutzen, nur 0 und -1 sind brauchbare Werte
  3. niemals accesskey benutzen

Als nächste Themen wird sich Rodney blutige SVG-Details sowie fokus-relevante Pseudoklassen (:focus, :active etc) zur Brust nehmen.

[00:42:15] How to Use npm as a Build Tool
Keith Cirkel hat keine Lust mehr auf Grunt und Gulp und erklärt daher mal, wie man auch NPM als Build-Tool einsetzen kann (wie auch andere vor ihm). Wir mit all unseren Monster-Projekten sind nur mäßig überzeugt: große Aufgaben können durchaus komplexe Tools erfordern. Peter gibt wieder eine Theorie von den in jedem Projekt vorhandenen hässlichen Ecken zum besten und will trotzdem für sein nächstes Projekt mal Makefiles versuchen.

[00:55:31] Keine Schaunotizen

appcache-nanny
Soll den Umgang mit dem gefürchteten Application Cache etwas verschönern.
The 2014 CSS Report: Examining how CSS is being used in the wild
Datenpunkte zum CSS-Einsatz in freier Wildbahn.

Revision 203: AngularJS x.x

10. Januar 2015 | 3 Kommentare

Unser Peter musste sich in letzter Zeit berufsbedingt deutlicher mit AngularJS auseinandersetzen und hatte sich doch eine Meinung gebildet. Verbunden mit genereller Verwunderung über die kürzliche AngularJS 2.0 Ankündigung war das für uns Grund genug, diesem Framework noch eine weitere Episode zu spendieren. Hilfestellung bot Pascal Precht, der dem Kommentar- und Fragefeuerwerk entgegenstand.

Schaunotizen

[00:01:08] AngularJS x.x
Phase 2 des Hype Cycles erfolgreich überstanden, nähern wir uns beim AngularJS Framework in raschen Zügen Phase Nummer 3: Desillusionierung. Von vielen Seiten hört man, AngularJS soll man gar nicht verwenden (andere Frameworks übrigens auch nicht), andere meinen sogar, das Toolset eignet sich sowieso nur für Demos und ist von der Pieke auf gebrochen. Es helfe Google mit der kommenden Version, die alles umreisst, was wir bislang kennen!

Doch warum wirkt Angular 2.0 wie eine große Entschuldigung seitens Google und als wehmütiger Versuch, jetzt alles richtig zu machen? Und warum bringt dieser Versuch wieder die Gemüter zum kochen? Sollte man Angular 1.x nun komplett in die Tonne werfen? Warum braucht’s wieder eine eigene Sprache und Tool-Chain mit AtScript, und warum sagt man ständig, AtScript sei keine eigene Sprache? Frage um Fragen und ein Thema nach dem anderen. In ihrer Mitte ein tapferer Jungentwickler namens Pascal Precht, der uns die Welt von AngularJS erklärt und aufzeigt, warum alles so katastrophal und verwirrend wirkt.

Apropos verwirrend: Wir finden die AngularJS Quellen für 1.x in diesem GitHub Repository, für Angular 2.x in jenem. Man erkenne den feinen Unterschied.

Zum Schluß noch ein kleiner Disclaimer: Wir bemühten uns redlichst, etwaige Vergleiche zu anderen und anderwertigen Frameworks zu vermeiden um entsprechenden Grundsatzdiskussionen aus dem Weg zu gehen, allerdings rutscht uns das eine oder andere Schlüsselwort in den Gesprächsverlauf rein. Seht es uns nach und erkennt die Anstrengung, den Fokus wieder auf Angular zu richten.

[01:13:50] Keine Schaunotizen

AngularJS: Login und Sicherheit
von unseren Kollegen bei AngularJS.de!
Integrating Web Components with AngularJS
Unser Gast beschreibt eine laut Eigenaussage “Hacky Solution”, wie man jetzt schon Web Components in AngularJS 1.3 verwenden kann. Also noch vor der 2.0er Revolution. Diese Erklärung gibt es auch in audiovisueller Darbietung samt Kollegin Carmen Popoviciu auf der letztjährigen NG Europe Konferenz
Moderne Web-Entwicklung mit AngularJS
Robin und Phil, die ihr schon vom Podcast kennen solltet, zeigen euch ausführlich eine Einleitung in die aktuelle Angular JS Version, die sie bei der Rhein Java User Group zum Besten gaben. Sehr detailliert und empfehlenswert, sowie eine gute Einleitung für die Workshops, die sie zusammen mit Peter geben.
Thoughtram
Apropos Workshop. Auch Gast Pascal zeigt euch die Vor- und Nachteile von Angular 1.x live und in Farbe. Buchbar auf dieser Seite
vivus.js
Themenwechsel. Animierte Strokes bei SVG, einfach steuerbar per Bibliothek. Vivus macht das für euch.
The origin of the <blink> tag
Schon etwas älter, nicht minder interessant: Wie ist eigentlich der <blink> Tag entstanden? Der Erfinder plaudert aus dem Nähkästchen. Spoiler: Entsteht so wie alle großartigen blöden Ideen.

Revision 202: Sicherheitslücken – DOM Clobbering, XSS via CSS, ES6 Fallen

29. Dezember 2014 | 7 Kommentare

Wir haben uns kurz vor Heiligabend den Mario Heiderich eingeladen, um über grauenvolle, abstruse und schier unlösbare Sicherheitslücken moderner Browser zu reden. Der richtige Stoff für besinnliche Weihnachtsstimmung und frohlockende Ausblicke ins neue Jahr!

Schaunotizen

[00:00:11] DOM Clobbering, XSS via CSS, Template Injection, etc.
Mario Heiderich, ehemaliger Webentwickler, heutiger Security-Experte, erzählt uns von den ganzen, dunklen Seiten der modernen Webentwicklung, die verheerende Schäden anrichten können, ohne das wir uns richtig wehren können. So beschreibt er aktuelle Sicherheitslücken in den Template Engines von AngularJS oder KendoUI und hält auch fest, dass diese Dinge gerne von den Bibliotheksherstellern auch mal auf die lange Bank geschoben werden (wie beispielsweise Frederic Hembergers jQuery Pull Request von “neulich” zeigt). Es gibt Hilfestellungen, wie beispielswiese Marios DOMPurify, mit dem man Zeichenketten auf verdächtigen Code prüfen und gegebenenfalls bereinigen kann.

Es muss allerdings nicht immer JavaScript sein. Mit CSS kann man mit Hilfe der @-moz-document Regel und Regular Expressions im Firefox ganz einfach Session Token aus der URL klauen. Mario erklärt ausserdem, wie man die Paint-Zyklen der Browser und CSS Filter dazu ausnutzen kann, um auf bestimmte Zeichen zu schließen, die der Benutzer eingibt. Zukünftige Spaßquelle bieten SVGs im Allgemeinen und SVGs in Webfonts im Speziellen.

Ebenfalls lückenreich und angriffsanfällig ist der DOM. Mit In the DOM, no one will hear you scream gibt es einen mittlerweile sehr bekannten Talk von Mario, der uns das Prinzip des DOM Clobbering näherbringt. Der Abwärtskompatibilität von HTML sei es geschuldet, dass man derartige Dinge überhaupt durchführen kann.

Dass man allerdings auch mit kommenden Technologien allerlei Unfung anstellen kann, zeigt der Ausblick auf Template Strings in EcmaScript 6. Mario sieht sich in seiner Rolle für die nächsten Jahre auf jeden Fall beschäftigt.

Abhilfe gewünscht? Mario lässt uns nicht im Schneeregen stehen, sondern gibt auch ein paar hilfreiche Schutzhinweise. Für hundertprozentige Absicherung empfiehlt die Workingdraft Crew eine Ausbildung zum Reisbauer auf dem zweiten Bildungsweg.

Weitere Links zu den Themen, die besprochen wurden:

Zu guter Letzt gibt es noch einige Hinweise auf themenbezogene Konferenzen.

[01:35:37] Keine Schaunotizen

HTTPS Mythen
Golem klärt auf, was es mit den herumschwirrenden HTTPS Gerüchten und Mythen tatsächlich auf sich hat.
Let’s make a Firefox Extension, the painless way
Ein knackiges Tutorial beschreibt, wie man Extensions für Firefox entwickelt.
Flexbox Adventures
Schon wieder ein Flexbox Tutorial? Ja! Dieses zeigt allerdings interaktiv und ausführlich, was es mit den Properties flex-grow, flex-shrink und flex-basis auf sich hat.

Revision 201: Offline-Apps und Links

22. Dezember 2014 | 3 Kommentare

In trauter Zweisamkeit quatschten Stefan und Peter über Offline-Technologien für Webapps und verlasen am Ende ganze zwei Links.

Schaunotizen

[00:00:22] Technologien für Offline-Webapps
Stefan macht Webtech-Vorlesung an der FH Oberösterreich und hat sich für seinen nächsten Termin vorgenommen, über Offline-Technologien zu sprechen. Während APIs wie Web Storage oder Indexed DB vergleichsweise unproblematisch sind, ist der Application Cache bekanntermaßen ein etwas schwierigerer Fall. Grundprobleme sind laut Peter durch die Spec-Schreiber falsch verstandene Anforderungen, die zu hohe Abstraktionsschicht und die mangelnde Flexibilität. Abhilfe verspricht der Service Worker, der neben vielen anderen Dingen unter anderem auch Offline-Webapps ermöglicht. Am besten erklärt dies Jake Archibald in seinem JSConf-Talk. Einziger Haken ist die überschaubare Browserunterstützung, bezüglich der wir jedoch einigermaßen optimistisch sind. Chrome und Firefox arbeiten schon fleißig am Service Worker und zu welchem Implementierungs-Tempo Microsoft fähig ist, sieht man daran dass die aktuelle IE-Preview-Version die beste ES6-Unterstützung aller Browser bietet. Zum Ende darf Peter nochmals seinen Mobilgeräte-Sind-Schlechte-Computer-Rant zum Besten geben.

[00:41:47] Keine Schaunotizen

Polyfill Service
Ein einziges Script von einem CDN einbinden, das per Browsersniffing nur die nötigsten Polyfills in dieses Script hineinpackt.
State of JS Implementations, 2014 Edition
Andy Wingo über die JS-Engines moderner Browser.

Revision 200: The Indie Web

14. Dezember 2014 | Keine Kommentare

Zum 200. Jubiläum luden Schepp, Anselm und Stefan niemand geringeren als Jeremy Keith ein. Viel Spaß bei unserer ausgiebigen Plauderei zum “Indie Web”. Die Episode und alle Shownotes sind dieses Mal auf Englisch!

For our 200th anniversay Schepp, Anselm and Stefan invited Jeremy Keith. Enjoy our excessive talk about the Indie Web!

Schaunotizen

[00:00:39] The Indie Web Building Blocks
Jeremy explains what’s the meaning behind the whole indie web term and why it exists. He continues to explain the technical basics: Decentralizing sources, authenticate on websites using your very own website and a social network of choice, sharing links to your blog posts to the social networks and getting mentions from twitter etc on your website and store them there. You can do this with just one requirement: if you have your own domain. It even can work on static sites and there are open source services like Bridgy that help you with concatenating the external sources.
[00:22:57] IndieWebCamps
We talk about the people who are part of the indiewebcamp thing and how it’s been created. It was created to create solutions and not only discuss stuff. We also speak about how to teach people about indie technology, how to learn to integrate it and where you can do so. Finally we talk about content ownership and the problem with external services who own your content and do what they want with it (like deleting it even if you don’t want to, thanks archive.org for storing things anyways). And Jeremy shares his first website version. If you are considering going to the upcoming beyond tellerand in Düsseldorf (which you should), be aware that there’s an accompanying IndieWebCamp happening.
[00:48:23] Useless Design Patterns
We’re talking about false assumptions of security which often have heavy impact on usability. Like on login screens when there’s only a generic error message not saying if username or password is wrong. We speak about if passwords should be shown by default to avoid the ‘confirm password’ fields and typing errors and most of the time people are in private and if not, they should be able to switch to hidden type mode. We also talk about captchas which are non-sense. In fact we should always ask ourselves why are we doing this or wait a minute, is this really a good idea? And test with real users to figure out what works and what doesn’t. Because assumptions by us is often simply wrong..

[01:13:15] Keine Schaunotizen

Responsible Web Components
In another brilliant article by Jeremy we learn how web components can be used as a means of extending existing elements rather than replacing them. See web components as an enhancement!
Multiplexing with SPDY and HTTP/2
Guy Bedford talks about multiplexing with SPDY and HTTP/2 in his talk.
FiyMyJS for Sublime
Can’t remember your team’s coding guidelines? Use them automaticlaly with Addy Osmani’s Sublime plugin.
HTTPs and web performance
Dean Hume explains how HTTPS influences the performance of your website.
Iterators gonna iterate
Iterators are a new JS language feature which appear in the recent Chrome releases. Jake Archibald describes how they work.
24 Ways
In its tenth year 24 ways is till one of the online christmas calendars which you have to visit.

Revision 199: Simplifizierung und Code-Refactoring Methodik

13. Dezember 2014 | 3 Kommentare

Schepp, Peter, Hans und Anselm haben in dieser Revision zwar keinerlei News oder Links zu vermelden, geben aber dafür ihr bestes, um ein bisschen in die Zukunft zu sehen und Methoden zur Refakturierung von Code zu analysieren.

Schaunotizen

[00:00:23] Simplifizierung
Nach Jahren des Aufrüstens sehen wir einen Trend zur Simplifizierung des Front-End Workflows. Hans klärt in seinem anfänglichen Plädoyer auf, was der aktuelle Status ist, was die Probleme und Unterschiede zwischen klassischen Präprozessoren und Postprozessoren sind und fragt sich, ob ein Tool wie Pleeease vielleicht sogar Sass ablösen könnte? Wir diskutieren und orakeln gemeinsam, wie die Zukunft aussehen kann und kommen zum Schluss, dass das Programmier-Business manchmal durchaus mit der Mode-Industrie zu vergleichen ist.
[00:30:20] Code Refactoring Methoden
Anselm fragt den Rest, wie sie an Refactoring von Code herangehen. Peter ist der festen Überzeugung, dass es hier nur eine einzige Möglichkeit gibt: Die alten Tests nehmen und darauf den Code neu schreiben. Gibt es keine Tests, müssen andere Prinzipien herhalten, wie sie Hans und Schepp pflegen. So muss man oft auf Grund verschiedener Gegebenheiten leider auf bestehende Tests verzichten und sich selbst eine Lösung ausdenken. Schepp nutzt dabei auch oft Tools wie seine IDE PHP Storm, JSHint und Code-Style-Checker für halbautomatisiertes Anpassen an Codestandards. Immer hilft jedenfalls der direkte Vergleich des alten Stands zum neuen. Auch visuelle Regression Tests mit Hilfe von Screenshots und Diff-Tools können vor allem CSS und HTML Refactorings unterstützen. Und zu guter letzt wünschen wir uns noch einen HTML Regression-Checker als Tool für Markup-Refactorings.

Revision 198: Workflow, Fokus, Shapes

7. Dezember 2014 | Keine Kommentare

Mit fast voller Mannschaft, ergänzt durch Sven Wolfermann (maddesigns.de, @maddesigns) ackerten wir uns durch drei Themen. News und Links gab es diesmal nicht.

Schaunotizen

[00:00:20] Git, Grunt/Gulp, Compass, SASS/LESS Workflow im Team
Ein Hörer hat sich gewünscht, dass wir über „Git, Grunt/Gulp, Compass, SASS/LESS und den Workflow im Team“ sprechen, was wir uns nicht zweimal sagen lassen. Rodney schlägt auf und berichtet vom seinem Arbeitssetup, bestehend aus Git, Grunt, Sass, Stash und Jenkins. Für den Workflow kommt Gitflow zu Einsatz. Rodney legt Wert auf die Feststellung, dass er Git wie von Gott gewollt mit rohen Konsolen-Befehlen bändigt, während die verweichlichten Kollegen auf Gitflow-Aliases oder gar GUIs wie Source Tree oder gar Tower zurückgreifen. Hans berichtet ebenfalls von seinen Erfahrungen mit dem Gitflow-Workflow. Man ist sich einig: die Arbeit mit Pull Requests fürt zu höherer Codequalität, weniger Bugs und besserem Wissensaustausch im Team. Die unvermeidliche Diskussion Grunt vs. Gulp halten wir mit etwas Mühe im Rahmen (denn so wichtig ist das Build-Tool gar nicht) und sprechen am Ende noch noch über Best Practices beim Code-Review und dem Umgang mit QA.
[00:33:18] Rodneys Zwischenbericht aus dem Focusing-Schützengraben
Seit Monaten verbrennt Rodney Zeit damit, in Browsern zu ermitteln, welche Elemente fokussierbar und antabbar (nicht das gleiche!) sind und welche es sein sollten. Zusammenfassung: Alles ist kaputt, nichts funktioniert. Nur wenn man auf einer statischen Webseite einfach Links/Inputs durchtabben möchte, klappt alles einigermaßen, doch alles, was auch nur etwas komplizierter ist, endet im Chaos. Browser scrollen ungefragt (und uneinheitlich), das Verhalten bei Image Maps und SVG-Elementen ist uneinheitlich und generell machen keine zwei Browser irgendwo das gleiche. Und noch schlimmer: die Spezifikationen sind zu schlecht, als dass man den Browsern daraus einen Strick drehen könnte …
[01:10:11] CSS Shapes
Sven hat über CSS Shapes geschrieben und gibt uns einen kurzen Überblick. Das neue CSS-Feature erlaubt es, Textfluss an einer nicht-quadratischen Form auszurichten. Es funktioniert zur Zeit in Chrome, Opera und Safari, für eine Firefox-Implementierung kann man seine Stimme erheben. Es gibt auch einen Polyfill, von dem Sven jedoch nicht restlos überzeugt ist – Progressive Enhancement ist der bessere Weg.

Revision 197: Responsive Images, IE 12 und Links

23. November 2014 | Keine Kommentare

Der ewig optimistische Sonnenschein Schepp und Miese-Peter nahmen für diese Revision verschiedene neue Produkte unter die Lupe, die Webentwicklern in Zukunft Arbeit abnehmen (für Responsive Images) oder (in Form einer neuen IE-Version) aufbürden könnten. Außerdem gibt es reichlich Links.

Schaunotizen

[00:00:21] Responsive Images Specification and Real-World Scenarios
Von den Machern von WURFL (einer Datenbank rund um User Agent Strings inkl. Browsermetriken): WIT, ein Service für Responsive Images. Weil die normalen Responsive Images nicht ganz einfach zu nutzen sind, erzeugt WIT ganz einfach aus einer Basis-Bilddatei mehrere Varianten für Responsive Images. Nach der Vorstellung des Dienstes debattieren Peter und Schepp, ob WIT ein Zwischenschritt ist oder eine fertige Lösung für auch die ferne Zukunft sein kann. Auch das Konkurrenzprodukt Akamai Image Converter lassen wir nicht unerwähnt.
[00:28:33] Neues aus dem Hause Microsoft
Aus einem langen Blogpost erfahren wir neues über einen möglichen IE 12. Nach ein wenig Geunke über Windows- und IE-Versionen arbeiten wir uns durch die neuen Features. So wird Preserve-3D für Transforms unterstützt, Content Security Policy 1.0 ist ebenso an Bord (in Revision 124 ausführlich besprochen) wie erste Spuren von Media Queries Level 4. Peter erzählt, wie die Gamepad API früher war und wozu man WAV-Support für <audio> würde haben wollen – beides steckt auch im neuen IE. Zuletzt werden auch Selection API sowie zahlreiche ES6-Features-Features unterstützt. Wem das noch nicht reicht: Wünsche bitte in der IE Platform Suggestion Box einwerfen. Auch nicht unerwähnt soll Remote IE bleiben, eine Art Browserstack für IE.

[00:57:37] Keine Schaunotizen

All About Angular 2.0
Ein langer Artikel beantwortet alle Fragen zu AngularJS 2.0.
Dealing With Compiled Files in Git
Einckecken oder nicht einchecken, das ist hier die Frage.
Pleeease
Ein CSS-Post-Processor mit Inlining-Superkräften!
ChromeDevTools auf Twitter
Bitte verfolgen Sie unauffällig.
Luke Wroblewski: Mobile Navigation, Conversion, Input, & More
„.. two and a half hour seminar on optimizing mobile experiences for conversion using design.“.

Revision 196: Interview mit Tim Kadlec

17. November 2014 | Keine Kommentare

Unser Freund Marc bietet uns auf seiner Beyond Tellerrand Konferenz immer einen Spot zur Aufnahme <3. Auch auf der ersten Berliner Konferenz haben wir gemeinsam mit Performance-Optimierer Tim Kadlec eine Folge eingetütet. Anselm, Schepp und Hans löchern ihn mit unangenehmen Fragen zu den Themen Cartoons, Mittlerer Westen und Reisen.

Caution for all the Haters: Diese Revision ist auf ENGLISCH.

Schaunotizen

[00:00:30] Interview mit Tim Kadlec
Wie jeder Gast stellt auch Tim sich vor und erklärt, wie es dazu kam, dass er heutzutage ein Performance-Papst ist. Tims Vortrag zum Thema Perceived Performance ist unser Einstieg in die Schnittmenge zwischen datengetriebener, entwicklungsorientierter Performance-Analyse und dem Verhalten, dass der Endbenutzer empfindet. Tim schildert seine Erfahrungen als Entwickler und wie wir Ladegeschwindigkeiten und das Erlebnis des Benutzers von Webseiten und Applikationen verbessern können. Für Entwickler ist es schwierig “Performance” als solches an Stakeholder und Manager zu verkaufen, meint Hans. Wo liegen die Business-Values, wie lassen sich diese belegen? Tims Perspektive ist es, dass Zahlen manchmal nicht entscheidend sind, sondern gerade auch das Verhalten der Applikation eine große Rolle spielt, um den Benutzer bei Laune zu halten. Ein Thema, welches wir schon öfter besprochen haben, ist das Performance Budget. Tim ist einer der großen Fürsprecher solch eines Wertes. Wir fragen, was ist eigentlich sinnvoll und wie kommen wir zu unseren Werten. Abschließend gehen wir auf die aktuellen Entwicklungen in der Performance-Optimierung ein und diskutieren die zukunftsweisenden Technologien Service Workers, HTTP2, Offline und mehr.