Fronteers Conference 2017 – Dag 1 – Ochtend

Op 5 en 6 oktober 2017 was de tiende editie van de Fronteers Conference. Fronteers werd gehouden in Amsterdam in het Pathe Tuschinski theater. Front-end developers over de hele wereld komen bijeen om naar een line-up van sprekers te luisteren die praten over het vak. Dit jaar werd de conferentie gehost door Sara Soueidan. Ze is een award winnende freelancer en front-end web developer uit Libanon. Samen met mijn collega Pim Godding konden wij vanuit Techtwo de Fronteers Conference 2017 bijwonen.

In de ochtend heeft Niels Leenheer het gehad hoe het web zich de laatste tien jaar heeft ontwikkeld en praat Jessica Rose over het Imposter Syndrome. Umar Hansa laat ons de vele verborgen voordelen, tips en tricks van de Chrome DevTools zien en bespreekt Yoav de mogelijkheden van Caching.

Don’t Panic – Niels Leenheer

Niels Leenheer, front-end developer en CTO bij Salonhub opende dit jaar Fronteers Conference. Hij sprak over de laatste tien jaar van het web. Niels liet verschillende browsers zien en sprak over de browser diversity en compatibility. Hij sprak over de term ‘progressive enhancement’. Dat betekent dat elk persoon toegang moet krijgen tot de content van een website. Het diversiteit aan apparaten en browsers is in de loop van de jaren erg toegenomen. Je moet namelijk niet voor browser of apparaat ontwikkelen, maar voor het web. Daar heeft hij inderdaad gelijk in. Je wil namelijk niemand uitsluiten van jouw website.

Op Fronteers van vorig jaar was er een spreker die vertelde dat het oké is als een website zonder javascript niet werkt. Deze spreker kreeg veel slechte commentaar hierop. Niels verbeterde zijn opvatting: “het is oké als een websiteapp zonder javascript niet werkt”. Vervolgens sprak hij over fallbacks en over bepaalde technieken die niet werken op bijvoorbeeld IE. Wanneer je een fallback zou moeten gebruiken of wanneer het prima is om de feature te laten zoals het is. Het antwoord hierop was “It depends”, dat iedere developer wel vaker gebruik heeft. Inderdaad dat hangt natuurlijk af van de feature én van de gebruikerservaring die je wil delen. Een game kun je lastig laten terugvallen. Misschien op een video maar de gebruikerservaring die je wil delen is lang niet zo goed als het spel zelf.

Nog een klein puntje. Om de een of andere reden had hij ook een hekel aan Bootstrap, een front-end framework voor HTML en CSS. Hij vond het té makkelijk en dat alle Bootstrap websites té veel op elkaar lijken. Misschien was hij niet helemaal serieus maar Bootstrap kan juist handig zijn doordat het componenten bevat die je als developer niet opnieuw hoeft te maken. Daarnaast is het handig voor prototyping.

Zijn slides zijn overigens hier terug te vinden.

Impostor Syndrome and Individual Competence – Jessica Rose

Jessica Rose, werkt bij FutureLearn sprak over het Imposter Syndrome, dat gaat over een onzekerheid waarbij je weet dat je de taak die je moet doen wel kunt uitvoeren maar je hier toch onzeker over voelt. Deze zone (Zone of Proximal Development) zit tussen de zone wat je te makkelijk vindt en de zone wat je te moeilijk vind, de onzekerheid ertussenin. Het Imposter Syndrome is iets waar je niets aan kunt doen. Deze onzekerheid heeft allemaal te maken met je brein. Dit is een denkfout van je brein ook wel “cognitive bias” en betekent simpel gezegd dat je brein foutieve data gebruikt om foutieve conclusies te trekken. Het gaat dus om mensen (bijvoorbeeld nieuwe mensen bij een bedrijf) die in paniek raken of onzeker bij taken die ze moeten doen en anderen in hun omgeving zien die het allemaal wel voor elkaar lijken te hebben. Ze vertelde daarbij dat we lang niet weten hoe goed we daadwerkelijk wel zijn.

Wat moet je doen bij mensen met het Imposter Syndrome? Niet vertellen dat ze het Imposter Syndrome hebben, maar juist positieve en betekenisvolle feedback geven. Wanneer je het Imposter Syndrome hebt en wanneer je er comfortabel bij voelt zul je over je gevoelens en angsten moeten kunnen praten en er uiteindelijk je eigen weg in vinden en doen wat goed voelt. Het doet me denken aan de eerste keer dat ik als developer bij Techtwo kwam werken en voor het eerst Magento leerde ontdekken. Ik raakte verdwaald in de code en raakte in paniek terwijl iedereen zo rustig leek en het wel voor elkaar leek te hebben.

A Modern Front-end Workflow – Umar Hansa

Umar Hansa, een front-end webdevelop uit London, Google Developer Expert, 5 jaar bij Shazam gewerkt en werkt nu bij Sitepen als JavaScript engineer. Zijn huidige projecten zijn Dev Tips mailing list en Modern DevTools, video courses.

Zijn presentatie was voor de front-end developer zeer interessant met veel nuttige voorbeelden die ik zelf in de praktijk meteen kon uitproberen. Hij liet handige (verborgen) DevTools tips zien en hoe je een moderne development en debugging workflow creëert. DevTools (in chrome) zijn trouwens handige tools in de browser voor een developer en kun je openen door naar weergave > ontwikkelaar > ontwikkelaar tools te gaan of op “F12” voor windows of “alt + cmd + I” te klikken voor mac.

De handigste sneltoets voor DevTools: “ctrl + shift + p” opent een invoerveld in je DevTools waar je de tool kunt zoeken en direct kunt openen. Zo kun je snel en direct naar de tool die je nodig hebt. Wist je dat je via DevTools ook screenshots van de pagina kunt nemen zonder daadwerkelijk een screenshot te nemen en deze dan in photoshop te bewerken en uit te snijden. “ctrl + shift + p” en typ in “screenshot”. Klik hierop en voila, je hebt een screenshot van alleen de pagina genomen. Erg handig dus!

Hieronder een overzicht van features in DevTools waar Umar over sprak:

• Screenshots van de gehele pagina nemen via de DevTools.
• Het contrast kunnen zien van de tekst kleur en achtergrond.
• Snippets ofwel Bookmarklets van javascript kunnen opslaan en gebruiken in je browser met één klik.
• Log Management UI: het groeperen van loggings met console.context. Zo kun je makkelijk je logs selecteren en filteren.
• Het gebruik van await.fetch in je console voor het asynchroon ophalen van data.
• Het zien van ongebruikte CSS, ongebruikte javascript in je console. Zo kun je de ongebruikte bytes van je CSS en JS zien en hoeveel % er nou daadwerkelijk gebruikt wordt.
• De .cls knop in de DevTools om een element class toe te voegen. Geen rechtermuisklik op het element en het element te bewerken als HTML om een class toe te voegen
• Verbeterde audits voor performance verbeteringen, voor het zien van bijvoorbeeld de laadtijden met chrome plugin “Lighthouse”. Zo kun je zien wat er allemaal op je site geladen wordt en hoe groot de bestanden zijn en wat voor impact het allemaal heeft op de laadtijd van je website.
• Animation recorder en inspector om transities en animaties te volgen, op te nemen en te bewerken.
• Het blokkeren van requests zodat je kan zien welke script of css je site vertraagd of breekt en wat de impact en/of performance kan zijn als je een bepaalde script of css niet inlaadt. Ook third party scripts kun je hiermee blokkeren.
• Realtime editen via je inspector en het rechtstreeks daarmee opslaan in je CSS bestanden. Ofwel, niet meer renderen en compilen van je CSS en nooit meer de browser te hoeven herladen?
• Built-in-terminal!? Een terminal binnen je DevTools. Gebruik vanaf nu GIT of grunt vanuit de DevTools in je browser.
• Git style code diffs voor CSS en JS in je console in de nieuwe “Changes” tab.

Super handig dus! Meer tips weten? Bekijk ze hier.

Update: Bekijk hier de slides.

Caches all the way down – Yoav Weiss

Yoav Weiss, werkt bij Akamai (CDN en cloud services), waar bij werkt aan het sneller maken van het platform door het toevoegen van performance gerelateerde features. Hij heeft altijd al gewerkt aan het sneller maken en performance voor het web. Dit was denk ik wel de pittigste talk van de dag. Voor mij als front-end developer is caching eigenlijk een soort van grijs gebied. We hebben er indirect mee te maken, maar wat er ondergronds gebeurd en komt kijken bij caching is heel gecompliceerd.

Caching is: “A collection of items of the same type stored in a hidden or inaccessible place”.

Hij had het over het benoemen van bijvoorbeeld methods en classes, dat dit lastig is. Je wil dit zo kort mogelijk houden, want alle extra informatie en karakters zullen ergens gecached moeten worden, maar je wil dit wel zo duidelijk mogelijk houden. Uit de naam van een methode moet natuurlijk wel blijken wat de methode doet.

Vervolgens sprak Yoav over “Cache Invalidation”. Wanneer een cache uit de cache gaat en wanneer hij dus een bepaalde cache opnieuw moet genereren.

Daarnaast ging het over hardware en onderzoeken voor de snelheden voor het genereren van caches. In het onderstaande tabel zie je de bevindingen hiervan, van snelste cache naar minst snelste cache.

L1 cache	0,5 nanosec	x1
L2 cache	7 nanosec	x14
L3 cache	30 nanosec	x60
RAM	100 nanosec	x200
SSD	150 microsec	x300.000
HDD Seek	10 millisec	x20.000.000
Network	150 millisec	x300.000.000

1 milliseconde = 1000 microseconde, 1 microseconde = 1000 nanoseconde

Vervolgens heeft hij een aantal cache methodes genoemd die je kunt gebruiken:

• MemoryCache
• Service Workers
• HTTP Cache
• Push Cache

In het laatste deel van zijn presentatie heeft hij het over hoe je via de headers van een bestand de cache kunt beheren met Cache-Control. Met Cache-Control kun je bijvoorbeeld aangeven wanneer iets gecached mag worden en voor hoelang.

Enkele voorbeelden waar Yoav het over heeft gehad:

• Cache-Control: max-age=3600 < Cache vervalt na 1 uur.
• Last-Modified: Sat, 7 Oct 2017 19:45:00 GMT < Bestand is voor het laatst bewerkt.
• ETag “33a64df551425fcc55e4d42a148795d9f25f89d4” < Identifier die je meegeeft dat voor een specifieke versie van het bestand staat.
• If-None-Match: “33a64df551425fcc55e4d42a148795d9f25f89d4” < De server vergelijkt de client’s ETag (meegestuurd met If-None-Match) met de ETag van de huidige versie van het bestand en kijkt of deze hetzelfde zijn. Als deze hetzelfde zijn dan hoeft dit niet opnieuw gecached te worden.  
• If-Modified-Since: Sat, 7 Oct 2017 19:45:00 GMT < Als de Last-Modified eerder is dan de If-Modified-Since dan zal het bestand opnieuw gecached worden.
• Cache-Control: public < bestand mag door iedereen gecached worden.
• Cache-Control: private < bestand wordt gecached voor een unieke gebruiker.
• Cache-Control: immutable < bestand wordt gecached en zal nooit meer veranderd worden. Kan bijvoorbeeld alleen veranderd worden door het bestandsnaam te veranderen of door iets bijvoorbeeld een parameter toe te voegen aan de url.
• Cache-Control: must-revalidate < De cache moet eerst de status controleren van oudere bronnen.
• Cache-Control: stale-while-revalidate < Dit is een nieuwe waar Yoav over vertelde. Zodra een gebruiker op bijv. een website komt en kijkt bijv. nog tegen de oude cache aan zal de nieuwe cache asynchroon op de achtergrond in geladen worden zodat de volgende keer wel tegen de juiste de cache kan worden gekeken, of zodat later de juiste cache op de pagina ingeladen kan worden. De stale-while-revalidate is overigens nog een experiment en wordt nog niet voor productie gebruikt.
• En nog veel meer zoals Cache-Control: no-cache, no-cache=set-cookie, no-store, proxy-revalidate, s-maxage, Surrogate-Control.

Helemaal into Cache-Control en HTTP Headers? Lees hier meer.

Overigens staan Yoav’s slides online. Bekijk ze hier.

Lees hier het vervolg van Fronteers Conference.