Front-end Dev Meeting — March 2017
Recap of our front-end dev meeting at Q42.
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
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.
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.