DotJS and DotCSS 2017
Written by Luis Miguel Fernández and Luis García Estrades of the Elements Barcelona office.
We had an awesome but short stay in Paris November 30th and December 1st attending the DotCSS and DotJS conferences again at the Dock Pullman venue. Although it snowed and we saw some hail, the conference made up for the bad weather with an astounding repertoire of speakers this year (two in a row already!) in the dotJS and dotCSS including Brendan Eich (the inventor of JavaScript), Wes Bos (well-known in the front-end community), Adrian Holovaty (co-creator of Django) and many other amazing people.
Unfortunately, we couldn’t stay until the end of the conference due our tight flight schedules, but we enjoyed it tremendously: the food was good, the people were nice, and the seats were comfy. The guys from DotConferences did a really good job again.
The talks in general managed to captivate the attendees. They even surprised us with some funny talks about tangential topics, which made us laugh a lot while teaching us new stuff. So, in this post in order to not overextend too much, we have hand-picked some of the talks to try to explain some topics more in-depth. In the upcoming weeks, most of the conferences will be available on the Dot Conferences YouTube channel.
Async + await
Wes Bos opened the conference with a talk about async and await. How by using them we can have async code looking sync and increasing the readability of our codebase. Promises are on an IOU (I owe you) basis, for something that will eventually happen in the future (like AJAX calls, webcams, resizing an image, parsing a file, etc). We start an async process and then we move on with our lives and when the process finishes, we then can take care of the code and do whatever we need to do.
We are going to illustrate a process where we want to update a view based on the shops that are inside a customer’s zip code. For that we’ll need to:
- Get the current user from a service
- Fetch their data from an endpoint (the data contains their zip code)
- Fetch the shops that are near that zip code from an endpoint
- Update the view with the shop data from the API
We can go from this:
to this:
which doesn’t look quite good enough and it can be refactored into this:
With the latter being more easy to test, read and maintain.
Most new browser APIs are built on promises (axios, payment requests, get user media, web animation API, etc.) Promises are great and we have been using them for years, but what about the `then`keyword? It’s still a callback, which is not nice. Async/await works with promises in a different and more intuitive way, it allows us to write code that is more legible from top to bottom.
As you can see, the code is more readable, maintainable and clean, allowing us to understand what is happening.
Some tips from Wes Bos on how to migrate to async/await:
- Write your new APIs in promises
- uUe async/await for flow control
- Convert older APIs with promisify
- Choose an error handling strategy and be consistent.
Working Well, The future of web testing
Trent Willis, senior FE at Netflix had a great talk on web testing.
Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test. Testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Having said so, we all know that maintaining quality code is hard, that’s why testing SHOULD give us confidence that software works (WELL), and to do that we must make sure that our code is accessible, performs well and is necessary (a.k.a. we don’t have unused code).
The talk was focused on the tools that Trent uses in his work and how everything has been evolving recently. He told us about the new Headless Chrome version, that allows us to setup automated browser processes that are able to actually render GUIs, in comparison to PhantomJS (headless WebKit scriptable with a JavaScript API), that we had to use in the past, and was lacking in features due to not being a real browser.
He also made some remarks about how great the Chrome DevTools Protocol has become, and how it makes us able to debug what’s actually happening in the browser itself. With all the new features, we can now also get more insights, like performance or accessibility remarks. The good thing is, that if we use both aforementioned technologies together, a lot of possibilities open up to us.
In this regard, Trent wanted to tell us about how this combination spawned new tools like Puppeteer, which allows you to easily do things like:
- Generate screenshots and PDFs of pages.
- Crawl a SPA and generate pre-rendered content (i.e. “SSR”).
- Scrape content from websites.
- Automate form submission, UI testing, keyboard input, etc.
- Create an up-to-date, automated testing environment. Run your tests directly in the latest version of Chrome using the latest JavaScript and browser features.
- Capture a timeline trace of your site to help diagnose performance issues.
He also took some time to explain how he used QUnit-In-Browser, which is an E2E framework he’s been working on, which apparently is better than Selenium-based tools.
But, in the end, why is this the future? Because with all the new tools we will be able to test more easily and in a more robust way. Because what matters most is that we should think less about HOW to test and more about WHAT to test. In addition, to provide a meaningful closing to his talk, he also showcased more utilities that looked really awesome and we are super eager to try them out as well, such as Axe-core (an accessibility engine for automated testing of HTML-based user interfaces) and ember-macro-benchmark, a tool for benchmarking not only ember applications, but any kind of application as long as it’s JavaScript.
Originally published at www.elements.nl on December 20, 2017.
