Front-end Dev Meeting

At Q42 we organize internal meetings on different spectra of (web) development. Meetups about iOS, RX, accessibility and also about front-end development. This stops wheels getting reinvented multiple times and knowledge also spreads more quickly throughout the teams. But why not publicly share the notes of these meetings?

So, here we are: a first!

Below are the notes of the most recent front-end dev meeting.

Map and Set

Using Javascript objects for key/value maps, and arrays for sets, is far from ideal. Happily there’s also Map and Set (and WeakMap and WeakSet), which properly implement these collection types. They are already supported in all major browsers (even IE 11, except for a few methods) and Babel can fix it for older browsers if needed. Node.js has full support as well. So there no reason not to use them!

The future of imports

Dynamic imports will land in the ES spec soon. Currently at stage 3, the proposal is almost complete. With dynamic imports, ES introduces a way to conditionally import modules. Instead of multiple import statements at the top of your script, you can now import a single module deeper in your code when you actually need it. After a user clicks on a button for example. Or when your single page application navigates to a new page. When a module is dynamically imported, a promise is returned which will resolve with the respective module or fail with an error. This combines nicely with async/await, which has already landed in the ES draft spec.

Take the loading of a page for example:

With async/await this becomes:

Babel & Webpack already support dynamic imports, so you can use them today. For Babel you have to use the syntax-dynamic-import plugin. Webpack needs version 2.x to work out of the box. If you’re still on 1.x, you can use babel-plugin-dynamic-import-webpack. Finally we have a way to replace all facets of our own require() invention with a complete language native implementation.

Proposal:
github.com/tc39/proposals/blob/master/README.md

More information:
2ality.com/2017/01/import-operator.html

Discussion: improve quality of front-end

Just before the launch of a new websites, we have the habit at Q42 to send a message to the whole company with the news. What happens next is that we receive a lot of feedback about things that people find in the website what could be improved. From interaction and accessibility improvements to bugs in specific browsers. Sometimes the feedback includes points that should already be known & fixed, because they could be easily detected with automated tools like Lighthouse & WebPageTest.org. Apparently everyone has a different toolset to validate their website. We would like to streamline this a bit more so we can in improve the overall quality of our websites. The idea is to create a webpage with a curated list of the ‘best’ tools to easily validate your website. And if it’s possible have a field where you can input an url to validate it on all tools directly. After some time we can validate if this approach is really working to improve the front-end quality at Q.

Discussion: giving knowledge back to the community

We’re writing awesome code at Q42, but our blog is full of meta things like project go-lives. We’d like for Q to also spread technical knowledge of our day-to-day activities. Which is exactly what we’re doing during this front-end-dev-meeting. As it happens, our most read blogposts are tech details about projects we did.

How can we motivate Q’ers to spread this knowledge outside of Q? First step is to write blogposts about each meeting, including all topics no matter how small. If they’re worth sharing within Q, they’re worth sharing outside as well. This small effort could spark other groups within Q to open up their knowledge, and get the ball rolling.