CSS in build process

CSS vs SCSS, currently I have come to the point that the main advantage of SASS for me was splitting the files. Since CSS now provides a solution for variable. Another benefit of SASS is nesting style rules. Which absolutely is a benefit, hence not used carefully could lead to longer selectors with increased specifity.

So currently the ideal situation for me would be able to bundle several css files in to one css file with the right order. One possible option would be to use a cli option like cat on lunix

cat scr/css/styles.css scr/css/headings.css > dist/css/styles.css

Another option which which I prefer is to keep it in webpack like this, with the help of mini-css-extract-plugin (css-loader is also required).


1. Install and css-loader and add mini-css-extract-plugin

run `npm install –save-dev css-loader mini-css-extract-plugin`

add `const MiniCssExtractPlugin = require(‘mini-css-extract-plugin’);` in the webpack.config.js

2. Add the styles in the entry section

entry: {
    styles: [
      path.resolve(__dirname, './src/css/styles.css'),
      path.resolve(__dirname, './src/css/headings.css'),

3. add the rules for CSS

module: {
    rules: [
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, 'css-loader'],

4. Always output chunks for the CSS

optimization: {
    splitChunks: {
      cacheGroups: {
        styles: {
          name: 'styles',
          test: /\.css$/,
          chunks: 'all',
          enforce: true,

5. Add the MiniCssExtractPlugin to the plugin section

plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].css',

Wrap up

I like this approach, since standard CSS can be used which will improve and extend its responsibilities over time. It will never deprecate which is a huge bonus.
And it is flexible, I can make as many bundles as I wish and even decide to leave some CSS files out of the bundling process, for example to make use of HTTP2. A downside might be that you need to remember to manually add the the css files to the `webpack.config.js` file to get the styles.

Circular menu webcomponent

I have dabbled, some 4 years ago with webcomponents, now seems to be the time to update my knowledge about it. With the circular menu webcomponent it will be possible to wrap regular links in the custom webcomponent tags, which will than be transformed to a circular menu on menu button click.

DEMO: https://www.wonderolie.nl/filebox/circular-menu/

CODE: https://github.com/jeroenoliemans/circular-menu.git

example of circular menus
the component distributes the menu items on a semi-circle

Research direction

I know bits about shadow-html and such, but for SEO perspective I want the links to be visible as child elements somehow. lets research first.

Goal to reach

The minimum component which should be able to wrap a regular list with link elements. These links will then be displayed as circles distributed along a circular path of 180 degrees. I should be optional to place the menu on the right side of the page. The component should have public methods to close and open the menu.

This is the minimal desired feature set of the component.

Experience creating the component

I really liked working with webcomponents and I think it is the way forward for the web. Just w3c and no more third party frameworks. During the coding hours I had to make lots of decisions. Mostly concerned the styling, because each instance of the menu should have its own styling and positioning. Currently I found this much easier to do with JavaScript. I tried scoping withing the stylesheet but that did not work as intended for me.

To create a webcomponent you need the extend the class with a DOM-element. My first instinct was to use the HTMLUListElement , but that did not seemed to work yet. Therefore I set on the base class HTMLElement

class CircularMenu extends HTMLElement {
    constructor() {
        this.shadow =  this.attachShadow( { mode: 'open' } );
        this.activeClass = 'menu-is-active';

For the connectedCallback a webcomponent life-cycle method it is important to understand that the dom part which contains the custom element should be available before being called. Hence the webcomponent script should be included just before the closing body tag.

The same as with React, webcomponents should be simple and expose methods to be used by the main the application. These public methods can only be called when the component is ready, as you can see in the inline script

var onload = function() {  
            if (!window.HTMLImports) {
                new CustomEvent('WebComponentsReady', {bubbles: true}));

        document.addEventListener( 'WebComponentsReady', () => {

The menu items gets inserted into the slot, these can then be styled with a pseudo selector in CSS as shown below

::slotted(li) {
            background-color: tomato;
            box-shadow: 0px 0px 5px #666;

        ::slotted(li:hover) {
            background-color: coral;
            box-shadow: 0px 0px 10px #666;

My Thoughts

In my opinion webcomponents are the best way to make future web with durable knowledge. The API’s are now being developed for a long time an have had time to ripe and are now mature.

Tough pure webcomponents are not ready for prime time usage yet when you need to support IE11 and older versions of IOS. Which is actually to bad. I think that it would be ideal if the whole web was to be written with W3C standard code. Things will be working for a long time.

My Utopian dystopia would happen when W3C will manage to come up with a standard way to bundle and optimize assets. Then all web developers will be able to use 100% of there time to create.