Sick picks from Frontend Con 2018 @ Warsaw, Poland
Frontend Con 2018, thank you.
You were my first tech conference (thank you code.kiwi.com), and having only been to similar events in academia before, it was sooo refreshing (not just figuratively) to be in Warsaw, Poland: meeting so many enthusiastic, energetic and smart people who love everything JavaScript was amazing. I could even meet in person people I’ve been following online for quite some time through podcasts and blogs, and what’s more, they were so approachable, and happy to chat. Now, THAT is something to celebrate and rejoice about the tech community.
My sick picks…
The talks that piqued my interest the most were the ones about performance and testing, most notably (click on the name of the talk to get the slides):
- Testing Front-End Applications by Jakub Janczyk
- The missing piece of testing by Maciej Myśliński
- Getting your Team Passionate About Web Performance to Achieve Performant Web Apps by Nicolas Goutay
…and their takeaways
Here follow the main and general takeaways from these talks but I highly encourage you to go through the slides as well — you might learn a thing or two, guaranteed.
Test Driven Development or TDD
When you start with a fresh code base, you know where everything lives, how the pieces relate to each other, etc. You come back 6 months later and you try to refactor a small functionality, only soon to realise that with the current setup, you will need to touch dozens of files. Since you’re not too familiar with the code base anymore, you’re afraid that you may have broken something in the process.
Enter TDD.
I’ve always wanted to dive more into TDD, or Test Driven Development, and these talks convinced me I should: ultimately it saves time and gives you confidence in your code. It gives you some assurance that the application works, that refactoring did not break anything and that adding a new feature did not break anything either.
My current understanding of TDD, beyond the Red-Green-Refactor, is that you should ‘explain’ what your app does in some high-level way: staying away from testing implementation details too much is really necessary as refactoring becomes painful otherwise.
It’s important to write unit tests, namely tests ensuring a simple function does what it says it does, but integration tests should be the aim. They ensure your mega-component or your page or even your application work as intended.
Write property based tests
Coming from a math background, this idea resonates with me very much: if we agree that writing tests is a great idea, we should also be writing tests passing on randomly generated data.
Of course, example based tests are great: they are easy to write and easy to understand. They sort of tell you a relatable story, and as such document to an extent how your code works.
But they’re not enough.
Following TDD, you could create the following test
describe('capitalize', () => { expect(capitalize('warsaw')).toBe('Warsaw');});
and write the following function to make it pass:
function capitalize(text) {
return 'Warsaw';
}If this was your only test, you would assume that capitalize does what it says it does, when in reality it’s returning “Warsaw” for any string your feed it.
Even though this is a fairly simplistic example, you get the idea: you’re only testing so many special cases with example based tests; they likely don’t cover all the possible cases.
Some nasty bugs only appear after some odd steps, and manual testing would surely fail to discover them (e.g. Spotify reporting such a case here). Even 100% code coverage is no guarantee: Maciej Myśliński explained that adding property based tests to React Final Form Arrays (which has 100% code coverage), he was able to detect 10 bugs, 4 of which were already mentioned in issues. That’s an impressive 6 new bugs discovered.
Since you want your tests to pass on randomly generated data, you need to find assertions that would work in every instance, hence the name property. For example, if you want to sort an array of numbers in increasing order, you expect the result of your sort function to be as follows:
- the output should also be an array (type)
- the output should have the same length (size)
- the entries of the output should still be numbers (shape)
- each entry should be smaller than the next one (sorted in increasing order)
- sorting twice should yield the same result as sorting once (idempotence).
Using a library called fast-check to generate random data, if your test suite fails on that random data, the library provides you with a minimal counter-example of why your test failed— I find that awesome. To make sure this random occurrence where the test failed is not lost (the likelihood to have the same counter-example being generated twice is quite small…), you add it in your list of example based tests.
That’s right, the final shape of your test files should look like:
- example based tests at the top, to quickly communicate what the functionality you’re testing does
- property based tests, ensuring the tests are not just passing on the selected few examples.
A framework to approach web performance
Your application works great: all your example based and property based tests passed, and you have 100% code coverage. Job done, let’s go and celebrate! 🎉
Wait: this is on paper, and sort of theoretical knowledge. What we need now is a proof by fire and actually release the app to production.
Sacrebleu, it’s so slow!
Where do you even start to understand why it’s slow? How do we improve performance?
We need to identify what Nicolas Goutay calls the Value Stream, and he proposes the following model of all the different steps involved in getting your user to see your web-application:
This break-down of all acceptable times makes it easy to pinpoint where you need to act for your application to be faster:
- Maybe your bundle size is too big, so you might need to consider reviewing your build process: did you minify, uglify and gzipped your bundle, etc.?
- Maybe your are loading too many assets or unoptimized assets or from slow origins: consider using fewer fonts, better optimized images, and serving assets from a CDN, etc.
- Maybe your API calls are taking too long because your backend is not ready for that much traffic: either you throw money at the problem by scaling up resources or you get these database queries optimized, etc.
In addition, you also know which steps went well according to your benchmark and so any work there would bring the least value.
One other takeaway from that talk was the human aspect of building applications as a team: without proper communication, it’s really hard to coordinate and have every individual’s efforts be the most effective for the goal at hand.
The story of Nicolas’ endeavour to get his team passionate about performance is really inspiring: one person can bring about significant change within a company and drive the existing culture into another direction.
This can take the form of introducing tooling (I really like for instance the CI test checking the resulting bundle size) or methodologies like the Value Stream mentioned above. It also goes by empowering people to share their knowledge and discoveries, for them to feel comfortable asking questions freely and early, to reflect constructively on their failures and celebrate their successes. What a great program!
Just scratching the surface
There were so many things I discovered and liked at this conference that I would need more than one article to talk about them at the length they deserve. So many great resources were shared, and the broad spectrum of what’s possible with JavaScript these days is simply astounding! For example:
- playing with machine learning and AI,
- Vladimir Novick showed that AR and VR are already there in React Native,
- SoundCloud’s XBox app contains a garbage collector for Redux written in JavaScript.
Exciting times!
If you would like to get some less polished account of the conference, with links to slides and lists of resources, you can have a look at my notes on GitHub.
I look forward to attending my next conferences this year! If you have any suggestions, please send them my way! In the meantime, thank you for reading this article and I welcome any feedback you may have in the comments.
