Minutes of DotJS 2017

Gildas GarciaAdrien Amoros
Gildas Garcia & Adrien AmorosDecember 11, 2017
#conference#js

We attended the dotJS 2017 conference, which gave a voice to some big players of the Javascript world. Here is our short feedback, conference by conference. In a nutshell, we had amazing speakers with very interesting talks!

The dotJS 2017 conference stage

Async + Await - Wes Bos

Wes Bos starts the conference with a small talk about the async/await pattern. He reminds us about the awful christmas tree callback hell, and explains that async/await is just another way to write promises.

Wes Bos with a slide behind him showing Promises usage

He gives us some examples about how to write promises, or to handle errors. For example, he uses Higher Order Function (Higher Order Middlewares) to handle async errors in express.js. At the end of the talk, he suggests using promisify to convert old apis into promises.

Check out his slides: Async + Await

The Future of Web Testing - Trent Willis

Trent Willis with a slide behind him about what is a site which works well

Testing that an application works is not enough. We should test that a site works well. For Trent Willis, a well working application is:

  • accessible
  • performant
  • necessary (only ship the code which is actually used)

We do have the tools and technics to make our sites accessible (aria-attributes, design, etc.), performant (SSR, PWAs, etc.), and necessary (Code splitting, etc.). But do we have tests to measure it?

The Chrome team, with the recent support of the headless chrome, also shipped an awesome tool: the Chrome Devtool Protocol. It gives programmatic access to every available information inside the DevTools! This enables tools like Pupetteer to do way more than just piloting the DOM.

We can use Pupetteer with other tools to test that our application works well:

  • axe-core to test accessibility.
  • ember-macro-benchmark to test performance (not limited to Ember).
  • code coverage report from the Chrome DevTools to test the shipped code for a specific page is actually used

All those tools open up a wide range of possibilities to give us even more confidence in our code than before.

Check out his slides: The future of Web testing

Using Machine Learning to Fix the Web - Suz Hinton

After a well explained history about how the U+267F character had been changed in New York, Suz Hinton tells us that too often the developers forget the accessibility when they develop websites. Suz is well known because she often does live coding sessions.

Suz Hinton with a slide behind her showing the new accessibility logo

However, she explains that it is possible to fix the web thanks to machine learning and simple examples.

First, she presents an api that can extract captions from images. This allows to add alt attributes inside an instagram page for instance. Then, she talks about the Twitch platform, and the accessibility of streams. In fact, they are not very accessible for deaf people. That's why she has developped an api that can build live subtitles from streams, and display them on screen. This plugin uses WebSockets and a Chrome extension, but Twitch has planned to offer this natively soon.

Finally, accessibility is a question of ethics more than tools.

The Annoying Site - Feross Aboukhadijeh

A super fun talk by Feross Aboukhadijeh about exploiting vulnerabilities in the new and old browser APIs, in order to create a really annoying website, and give spammers a hard time.

Feross Aboukhadijeh in front of the giant screen showing the annoying site in action

Feross semi-live coded this site, showing us all kind of vulnerabilities he exploited to:

  • Spy the browser webcam without any prompt
  • Fill the user disk with the localstorage using sub domains (limited to 5mo each)
  • Phishing user data with the Full Screen API

The end result was a site which opened a moving window playing some videos. Trying to close this window opens a new one which fills the user search history with embarassing queries then play another annoying video and so forth. Terrible!

Do You Need Frameworks? - Adrian Holovaty

Adrian Holovaty presents us an amazing responsive demo of his music partition website named SoundSlice.

A soundslice music partition

He did this without any framework of course.

Adrian Holovaty in front of the giant screen showing a picture of heavy helicopters with a logo of many frameworks on top of them

His point of view about the frameworks:

  • Libraries are called from your code. Frameworks call your code.
  • Use patterns, not frameworks.
  • Don't be afraid to think by yourself.

Getting Data From The Sky - Thomas Watson

A very frightening talk where Thomas uses an antenna you can buy on Amazon to listen to the informations broadcasted live by all planes: not even encrypted!

The final code displays a map updated in real time with planes around us and very detailed data about them: their identifiers, altitude, position, etc.

And then, you can make a really nice map of all the planes.

Thomas Watson in front of the giant screen showing a picture of the Pulse-Position modulation

It's of course forbbiden by law but one could easily broadcast data about a plane which doesn't even exists! I told you it was scary...

Check out his slides and the demo source code:

Webpack Internals - Sean Larkin

Sean Larkin gives us a tour of WebPack internals. He also evokes the webpack foundation: tappable, a plugin library. He also shows that making a webpack plugin is not that complicated.

Sean Larkin in front of the giant screen showing an hand drawn picture with the talk title

He finally talks a bit about webpack 5, which will have first class support for all assets (no more ExtractTextPlugin), making webpack useful not just for JS anymore. It will support WebAssembly and other languages such as Rust, Elixir, etc.

How To Fix Accessibility - Marcy Sutton

Marcy works at Deque Systems on the axe-core team. She is on a mission to convince us we can make the web more accessible.

She points out that accessibility is not just about disabilities. Our users may also be impacted by their income, their location, their reading level, etc.

She then focuses on the tools available to us to analyse, test and enforce accessibility in our applications for people with disabilities.

Marcy Sutton in front of the giant screen showing what impacts a user (disability, income, etc.)

She outlines the 3 most common accessibility issues:

  • keyboard navigation
  • focus management
  • color contrast

With a concrete application showcasing those issues, she fixes them step by step by:

  • making clickable items accessible (use buttons and don't hide the outline effect on focus!)
  • making a drawer menu accessible (don't handle focus on hidden items)
  • making navigation accessible (clicking a link should close the drawer)
  • fixing the contrast

Some tools looks invaluable if you're willing to fix those issues (and you should):

No more excuses!

Check out the demo source code: marcysutton/a11-demo-app

Glimmer.js - Tom Dale

Tom is currently working for LinkedIn on the rendering performances issues. Nowadays apps should be very reactive, but they still need to be downloaded, parsed and rendered. Theses points are time consuming but necessary.

Fortunately, the React Virtual Dom has improved perfomances issues a great deal, but there are still some pain points. First, JSX is not optimal, because of the compiling time. And that's worse if developers don't pay attention to the way they write components. For this particular point, Tom recommends to read Fran├žois' article. And the second problem is that all browsers are not the same (for example mobiles are less powerful than desktop).

From this finding, Tom introduces the Glimmer library. In fact, this lib compiles templates to bytecode that is interpreted by the internal virtual machine of the browser. It manages the updates too.

You can play now with the Glimmer Playground if you want to try it.

A Brief History of JavaScript - Brendan Eich

You probably know the last speaker. Brendan Eich is of course the creator of the JavaScript language (and now in charge of the Brave Browser). He speaks about the history of the language, and gives perspectives about the future.

  • Dynamic import()
  • Array.prototype.flatten/.flatMap
  • let {x, y, ...z} = {x:1, y:2, a:3, b:4};
  • Private methods and accessors
  • Asynchronous iteration: for await of
  • RegExp improvements

Check out his slides: A Brief History of JavaScript

Lightning Talks

We had several interesting lightning talks:

  • Beware of the Javascript plus sign and its behavior when using it with different data types
  • The Typescript Language Service is extensible and can be used to enforce best practices easily
  • GraphQL made state management librairies useless for almost all applications

Check out their slides:

Conclusion

Final dotJs thanks

At the end of the day, it was a great conference with a lot of things to keep in mind. This dotJS 2017 was not only about changes that happened in the JS world, but there were also specific talks with concrete advice to apply to our project. We can say that it was a subtil mix of technical aspects and more general thoughts.

We have the feeling that the community is willing to develop accessibility. In fact, we had 3 talks on this major subject, and that's very good news.

We will certainly not miss the next one in 2018.

Photo credits: dotJS 2017 - Flickr album