Fronteers 2017

Published in

Elements blog

9 min readOct 13, 2017

Written by Luis Miguel Fernández, Luis García Estrades, Ricardo Ambrogi and Stoyan Delev

On Thursday 5th and Friday October 6th, four of our front-enders (the two Luises, Ricardo and Stoyan) went to Fronteers Conf 2017, the tenth edition of the event already, in the beautiful Pathé Tuschinski theatre in Amsterdam. In this blog post they discuss the talks they liked the most.

Ricardo

A Modern Front-end Workflow

Every front-end developer makes use of DevTools on daily basis, but just a few (or maybe just Umar Hansa) know how to make fully use of it. And because of that, Umar Hansa was in charge of speaking about DevTools at Fronteers 2017. When introduced, he was referred as the ‘one’ who knows more about DevTools than its own creators. Umar showed us a few hidden secrets that are available in DevTools and how to make most use of them. Umar taught us how to perform audits, which help us fixing and finding problems that might affect our websites, including accessibility issues.

Debugging Accessibility

Talking about accessibility, this was the subject of Alice Boxhall’s talk. Alice showed us a funny example of a website that accepted no clicks at all: navigating was triggered by hovering at determined things, which was obviously not accessible at all. Alice tried to show us how disabled people use the web and how to make the websites we develop better for them. She elaborated on Umar’s talk, by giving us a more in-depth example on how to use DevTools’ new features which can help us debug and understand accessibility of the websites we develop at Elements.

Stoyan

WebAssembly 101

This talk by Ash Kyd was about WebAssembly (a.k.a. wasm). It is a new standard which allows the browsers to “load” and “run” assembly-like code. The performance of web assembly is near-native since browsers do not need to parse, optimize and compile JavaScript. WebAssembly can be compiled from languages like C, C++, Rust and there are also experiments with Python, C#, etc. So everyone can write browser code in the preferred language and compile to wasm. But the main idea of it is not to replace JavaScript. Actually in most cases you will run both JavaScript and wasm in the same app/website. WebAssembly will open lots of doors for developers, things like image/video processing, games, and AI in the browser will become more and more common.

Caches all the way down

As we all know caching is one of the two most difficult things in software development. Yoav Weiss managed to give a great talk about the difficulties and weird behavior of caches in the browser. Starting from in-memory cache, which is the fastest, and basically store data for the same resources. For example, if you request an image twice from a page, the second request will be returned immediately from memory cache.

The next level of caching is a service worker: kind of a proxy/middleware, which can intercept all HTTP requests and put them in a cache. Server workers can be programmed, so it is up to you which request to be cached and when. Next layer is HTTP cache which follows HTTP semantics, also allows resources to be reused. So an image from page A can be cached and reused on page B. And here comes the weirdest part: there a plenty of directives and combinations with confusing names, no-store, no-cache, immutable, must-revalidate, max-age, etag, public, private. On top of that there is HTTP/2 push cache, where push resources are stored as part of a push session. In conclusion: caching on the web is not easy, but can achieve serious performance improvements.

Luis Mi

Impostor Syndrome and Individual Competence

This talk by Jessica Rose focuses on how the impostor syndrome and the Dunning-Kruger effect work to undermine our estimation of our individual skills. In short, the impostor syndrome is a concept describing individuals who are marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud”. Or, to explain it plain words: “Your brain uses bad data to build worse conclusions, and then becomes attached to those.” This usually means that you have a feeling that you don’t belong, that you are not good at doing something, that your boss is going to fire you and you will end up living under a bridge.

This can seem like a big deal for the average developer, but in fact is something widely present in the nowadays society, present in most working environments and it’s -usually- rather harmless, though it’s more common for minorities, because the feeling of not belonging could prove to be more relevant. In this talk Jessica Rose tells us that there are studies that point out a couple of issues that impostor syndrome creates for you:

Feelings of inadequacy
Avoiding displays of target skills.

But in the other hand, it boosts soft skills:

Use of charm to improve social mitigation
Increased diligence and dedication, to compensate for your feeling of lack of skill

Unluckily, the imposter syndrome, as most of cognitive biases, is something that it’s not really fixable. One of the things that you can do to improve is getting better data to compensate the “bad data” your brain is gathering. For example things like getting a certification on your skills, or start a new project that is more compelling.

Jessica also gave us some hints to deal with people who suffer from the impostor syndrome. Although it’s mainly applicable to any professional interaction with anyone in your team, to make everything better for others, not only the ones with the impostor syndrome. So, summarizing, do not, ever, tell someone they have impostor syndrome, instead:

Give positive meaningful and actionable feedback;
Talk about your own feelings and fears when you feel comfortable doing so.

The Landscape of Front-End Testing

This talk from Alicia Sedlock covers the breadth of testing strategies available to front-end developers now, their benefits, and considerations before integrating them into your applications. She explains that you should automate as much as possible in the development cycle and points out six areas of testing that are relevant to some extent, and divides them in old school (the classical sense of testing which have been around for some time in several other technologies already) and a new school of testing:

Old school:

Unit tests are to ensure small pieces of code work as expected and independently. Most of the time, it means that given one single input, you should test that you end up with a one and single output. She provides as well some examples of big players that we can find around: Jasmine, Mocha, QUnit, Chai, Sinon and Webdriver.io;
Integration tests check that all the small pieces play well together in the bigger picture. It’s a step ahead of Unit testing and usually you should test also the side effects that might happen in that “bigger” piece of code. So most of the time you should check several inputs, several outputs, and everything that might happen in between;
Acceptance testing makes sure that we can accomplish major tasks. Most of the time this is being taken care of by a QA team, but they can be automated as well. You should check that a whole user story can be started and finished, regardless of how it is technically built. A tool that has been around helping with this kinds of testing is Selenium, but Alicia provides some more modern examples, like Jasmine-integration, Karma or Nightwatch.

New school:

Visual regression testing has recently started gaining popularity — and for good reason. In its most basic form, it’s a series of tests that run through your site, take screenshots of various components, compare those screenshots against baseline images and alert you when things change. Some of the visual regression tools that she lists are the following: PhantomCSS, BackstopJS, Wraith, Webdriver.io and Percy.io.
Accessibility tests compare your site against accessibility standards. Accessibility tests are a subset of usability testing where the users under consideration have disabilities that affect how they use the web. The end goal, in both usability and accessibility, is to discover how easily people can use a website and feed that information back into improving future designs and implementations. Some tools that might help with this, are: a11y (with grunt-a11y), Pa11y, react-a11y.
Performance testing keeps your project honest about possible performance issues. In this case you should establish a performance budget, and then, once those specific goals are set, you stick to them. Anytime you want to add something to an application, you need to ensure it stays within your budget. You can go with one of these three options if something does not fit within the budget: optimize an existing feature or asset on the page, remove an existing feature or asset from the page, or don’t add the new feature or asset at all.

Luis G

1Up Your Writing with Plain Language

Ashley Bischoff explained the importance of communicating in the simplest way possible. Often we have to document or write reports and we should put our best effort to write in a clear way. Because, the ones reading our documents might not be familiar with the subject matter or don’t have the same technical knowledge. Our goal when communicating should be that the person reading our words can understand what we have to say. To say in other words: it doesn’t matter how technically correct our writing is, our words won’t help if those reading them can’t understand what we want to share.

To help that our message is understandable, there are some techniques:

We should try to use short words in terms of syllables length. Try to stick with short words, around (3 or 4 syllables) when possible.
Use short sentences instead of long ones (maximum 24 words).
Remove unnecessary complexity:

There are some scores we should have in mind, like the Flesch–Kincaid readability tests or the Gunning fog index. The latter index estimates the years of formal education a person needs to understand the text on the first reading (the lower, the better). Some tools we can use to review our text are Textalyser, Hemingway App and Text Analyzer.

Her concluding words were: “Because no one has ever complained that something was too easy to read”.

Possibilities of WebVR and its role in the future

VR is a trending topic nowadays, typically focused on video games since it’s birth. Many companies have been introducing their VR devices to the market. The main one for us, developers, is the Google Cardboard because it allows experimenting the VR world without much investment. The browser has potential to play a big role in the future and this is where we can start developing for VR.

Ruben van der Leun opened his talk with his exhaustive knowledge of the VR history and how it can reach more users through the web. During his talk, the attendees could follow his demo progress through a Google Cardboard. He shared that with the A-Frame library we can have a functional scene in a few minutes. After five minutes we got the following result (gist):