Front End Developer Love 2020đź’–
The conference where devs come to …{❤} over coding
Last Wednesday 19th February was the new edition from Front End Developer Love, a conference that promised to be the largest conference in Europe. I was surprised by the variety of content, not only framework related but also about how the talks touched topics that we don’t discuss in our daily basis like: do you really need scrum? do you know what is serverless? or how do you make a website accessible, and not only talking about disabled people.
In this article, I will give an overview of the talks that I assisted.
The start
After parking my bike at the Amsterdam Theater, I grabbed a nice coffee and some donuts. To my surprise, the main hall was full pack, 1300 people were ready for an unforgettable experience. 20 minutes later everyone was sitting and a small film about Amsterdam started playing on the huge cinema screen, it was time for the big show!
How thinking small is changing software development big time
Sander Hoogendoorn Chief Architect at Quby kicked out probably the most inspiring and energetic talk from the conference. He started with an introduction about the story of the technology, how devices have become smaller and smaller. Compare the size of the first computer with a regular laptop nowadays. The same pattern can be applied to our daily lives at work. Sander emphasizes that people should stop doing projects and focusing on delivering smaller features.
“Stop doing projects, deliver fast, move fast and automate it.”, says Sander.
Teams can reduce their size too, instead of working in scrum teams of 7–9 people, why not to work in teams of three? Smaller teams become cross-functional, self-organized and more efficient. Also the smaller the group, the better the communication.
Sander challenges people to stop copying others, for example: Why would you use the Spotify model if you’re not Spotify? The model was created in 2015, maybe Spotify doesn’t use it anymore! Think for yourself, think about what really works for you and your company.
Svelte: the last framework we need?
Alexander Esselink (also known as Dexter) is a Fullstack Consultant at Passionate People. In his talk, Dexter gave a small introduction about one framework that introduces a radical approach for creating UIs, Svelte.
Alexander asserts that Svelte allows you to create true reactive UIs, using less code and no virtual DOM, this means blazing-fast applications. The framework uses a vanilla approach, so no need for special API’s like React Hooks or composition API.
One feature that caught my eye was how simple was to create observers in Svelte. For example, having a prop count, creating an observer for calculating the double of this value is as easy as using the following syntax:
$: doubled = count * 2;
A more detailed example:
<script>
let count = 1;// the `$:` means 're-run whenever these values change'
$: doubled = count * 2;function handleClick() {
count += 1;
}
</script><button on:click={handleClick}>
Count: {count}
</button><p>{count} * 2 = {doubled}</p>
Serverless gives you wings
“I used to work for Yubi, a platform similar to Instagram. Emily, a user of the platform, did weekly giveaways. Everytime at 10 p.m. she would anounce the winner. During that time there was so much traffic that we couldn’t handle”, says Yan Cui.
It took Cui and his team six months to refactor the whole architecture to be able to handle all that traffic.
Creating the infrastructure for an application can be tedious, according to the Developer Advocate. Setting up the network, creating and maintaining the VMS, setting up the webserver, configuring middlewares… On top of that, it’s difficult to choose the right tool for deploying/monitoring since there are too many solutions.
Serverless is a cheap solution that saves you all the boilerplate in your infrastructure, allowing you to start writing right away your business logic. You won’t pay for idle servers. 95% cost saving compared to existing EC2-based solutions. Besides that, Serverless allows you to create and deploy your own lambda functions.
Serverless means:
- don’t pay for it if no-one uses it
- don’t need to worry about scaling
- don’t need to provision and manage servers
The future of Web Browsers
“Do you want a modern and high-performance solution for cross-browser testing? — go for Playwright.” says Ana.
Anastassiia Dragich software Engineer at Booking.com gave a journey about all the solutions used for E2E on the web. First of all, Ana explained why shall we use E2E testing:
- Reduce time for manual testing
- Feeling safe to code and deploy
- Find bugs in the user scenarios
The challenging part it’s to find a nice solution for E2E testing. It all started with Selenium in 2004, Webdriver continued and improved the scene in 2006 and nowadays there are plenty of solutions out there. Ana enumerated the most relevant:
- Tescafe: A node.js tool to automate end-to-end web testing. Disadvantage: Slow.
- Puppeteer: Tool to control the browser developed by the Chrome DevTools team. Ana remarks that it only works for Chrome.
- Taiko: Developed by the creators of Webdriver, it’s a browser automation tool.
- Playwright: Developed by Microsoft, it’s the next step to Puppeteer since it works more in Chromium, WebKit, and Firefox.
Playwright seems quite easy to use and developer-friendly, an example of how to take a screenshot of the front end developer love website:
const playwright = require('playwright');
(async () => {
for (const browserType of ['chromium', 'firefox', 'webkit']) {
const browser = await playwright[browserType].launch();
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://frontenddeveloperlove.com');
await page.screenshot({ path: `example-${browserType}.png` });
await browser.close();
}
})();Practical A11Y for Web Apps
“Make your web accessible for everyone: blind, deaf, young, old, don’t discriminate anyone”, says Bob
Bob is a Tech Lead Developer at ING, a company that has millions of users daily, where accessibility is the key to a good user experience. During his talk, Bob gave us some keys to improve our website’s accessibility.
Perceivable/Operable/Robust/Understandable
Your website should be accessible, no matter if you’re an invalid person that control its laptop blowing through a straw, or if you’re using it from your refrigerator. Websites should be perceivable by your users, do not restrict to a single orientation, use sufficient contrast and represent the content in a meaningful order.
Use native HTML elements, this makes your website robust since it maximizes the compatibility for user agents and assistive technologies.
Tips & Tricks
Lighthouse is offered as an extension in Chrome which can give you some insights to improve your accessibility. For example, after doing an audit on this page, it said that most of the buttons didn’t have a recognizable name.
Another interesting tip, if you use client-side routing in SPA’s, it’s important to reset the scroll of the document, update the document title and focus on the first element of the body.
Landmarks provide a powerful way to identify the organization and structure of a web page. Landmarks can be introduced using elements like:
<nav>
<main>
<search>The last tip gave by the Tech Lead, to use aria-live to indicate to the user that something has been updated. For example, we can use the aria-live attribute to indicate that a user has been added/removed from a list:
<ul id="roster" aria-live="polite" aria-relevant="additions removals">
<!-- use JavaScript to add remove users here-->
</ul>But, you’re not Facebook
“I totally love that website because the lighthouse score is 100% and they didn’t include lodash in the final bundle” -nobody
If you have seen Kristijan Rastovski (a.k.a. Kitze) in the stage before, you might already know that his talks are full of jokes, sarcasm, and critic into the dev scene. With the title “But, you’re not Facebook”, we knew already what it was about to happen.
The talk went around how developers take so much effort in solving inexistent problems or problems that are already solved.
One funny example was the release of the AirPods Pro website. The page raised some controversy amongst developers because the Lighthouse score was not 100% and it was not a PWA. Kitze says: did those developers notice about the target audience? The people interested in buying the AirPods Pro own one of the latest MacBooks and they have 200 MB/s internet connection.
Developers lose so much time overengineering their apps and they keep forgetting that the most important part is their users. For example, Facebook might not use inline functions in their render function because it can increase in a few milliseconds the render time, or they might not use certain libraries to reduce the bundle, but you’re not Facebook and you can use that time and libraries to improve your application for your users!!
“Disney plus uses styled-components, they can handle those expensive runtime costs”, jokes Kitze
Beats, Rhymes and Unit Tests
Unit tests and hip hop, do they even go together? Tony Edwards surprised the public with one of the most unexpected and kickass talks in Front End Developer Love.
The talk started with a short introduction about the speechRecognitionAPI. This API allows JavaScript to have access to a browser’s audio stream and to convert it to text. Speech recognition is all around us, from asking Siri where is the closest restaurant to make life easier for people with disabilities.
What makes this more interesting it’s the challenge that Tony brought to the scenario: can we use the SpeechRecognition API for transcription of recorded hip hop lyrics? After setting up and running a few unit tests, unluckily it was not possible, mainly because in these songs the singers are not singing a cappella.
But here it’s the big twist, how would the speechRecognitionAPI react against a live performance? This was the funniest part of the show. Tony decided to rap in front of the public, but before that, he needed the energy and support from the audience to rap. He explained the golden rules for a nice rap performance:
- Standing up
- Clapping
- Echoing
- Divide the room
- Confirmation
In just a few seconds everyone was standing and clapping, enjoying one of the most epic live rap in Front End Developer Love. The coverage for the unit test was good enough to receive a big round of applauses and to impress the public.
The end
Front End Developer Love was an eye-opener experience. I came back home questioning why I have been using scrum all these last years, why I never heard about Serverless, when I was going to start using Playwright and asking myself why do I keep overengineering my apps? Learning and improving will stick with our lives forever, see you next year at Front End Developer Love 2021!
