Front-end Dev Meeting — May 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 allows knowledge to spread more quickly throughout our teams. We share a summary of each front-end development meeting publicly.
This time we have a broad selection of subjects, and even a short essay from one of the other meeting groups.
Babel presets
The old babel presets compiled every language feature to plain old javascript, but these days browsers already support some language features! babel-preset-env allows you to specify which browsers you need to support, and only compiles away what is needed, giving you smaller and faster code!
Css variables
CSS variables have recently shipped in all major browsers, and now is a great time to start using them. While we’ve had variables in CSS for quite some time using preprocessors, having variables in native CSS has some advantages. One of them being that native variables are dynamic. Let me explain that with an example. Wait, I should explain the basic syntax, right?
Here you see three new things, the first one is the :root pseudo class, this is like targeting html. You could use html for this, but :root provides a nice isolation for defining global variables. Next you see a property starting with two dashes, that’s a custom property. Custom properties can have any valid CSS value like an int (10), dimension (10px), keyword (left) or string (“content”). And lastly the value of that custom property is assigned to a regular property by using the var(--variable-name) value method.
On to the example:
See that gutter variable? That variable changes values based on a media query. So, by declaring your responsive behaviour in one place, all styles adjust accordingly. Eat that Sass!
Working example of the previous example: codepen.io/guidobouman/pen/KqPjyp
Service Workers
Building progressive web-apps can be a very interesting way to provide your users with a near-native app experience. However, the web-apps had one major drawback compared to their native counterparts; Developers were unable to control their applications when the user is not online or the application is not running.
With the introduction of the new service worker web standard, this will no longer be an obstacle. As the name suggests the service worker is a ‘service’ that runs in the background, even when your website/web-app is not being visited or used. This enables the app to send notifications, cache assets and pages (so they work offline) and synchronize data in the background.
See this simple explanatory guide:
github.com/w3c/ServiceWorker/blob/master/explainer.md
There are some limitations to service workers. For starters it is sand-boxed, so there is no way to really interact between the service worker and your web-app. Basically you are interacting with the browser, allowing you to enhance the browser behaviour. Other than that a HTTPS connection is a requirement (unless you are running on localhost).
In short; The service worker is a great new web standard to make your application accessible without a working internet connection and it allows some behaviour of your app to run in the background.
Observables
The Observable pattern has been available for quite some time. The Rx (Reactive Extensions) framework makes great use of it and allows you to model promises as streams of future values allowing you to use functional operators.
For example this stock ticker:
(live code can be found here)
Rx makes it very easy to do things like only emitting values when they change and calculating the delta of the price since last emission. It is a native fit for frontend javascript because the stream pattern is easily recognisable; click events, mousemove and autosuggest results are all perfect examples. But as the bitcoin price ticker demo shows, you can also utilize Rx in NodeJS.
People who are fluent in Rx or just start using it acknowledge that the learning curve of Rx is steep. This is because it handles a complex problem; asynchronicity. Rx makes it easy to test what happens when future values arrive. It’s a powerful tool and invaluable when working with Promises in a larger application.