It’s quite simple to implement. Every modern browser can evaluate media queries in JavaScript with window.matchMedia() and supports CSS variables.

I added the following to my application JavaScript file:

const preferColorSchemeResult
  = window.matchMedia('(prefers-color-scheme: dark)')

if (preferColorSchemeResult && preferColorSchemeResult.matches === true) {
  document.documentElement.setAttribute('data-theme', 'dark')
} else {
  document.documentElement.setAttribute('data-theme', 'light')
}

The script will set the data attribute theme on the document element (html) with the possible values dark or light depending on the result of the media query.

There’s no need for a polyfill, even IE 10 supports window.matchMedia().

The stylesheet changes are even simpler, since I already had introduced SCSS color variables a while ago. I just had to replace them with CSS variables.

// colors
$c_white: #fff;
$c_dark-grey: #4A4A4A;

:root {
  --container-background-color: #{$c_white};
  ...
}

[data-theme="dark"] {
  --container-background-color: #{darken($c_dark-grey, 20%)};
  ...
}

That’s basically it. If you use SCSS, please take notice to use interpolations to map the SCSS variables to CSS variables. This change in SassScript expressions was necessary to provide full compatibility with plain CSS.

Since the theme selection is fully automated, I will provide a toggle possibility in a future release for those of you who prefer the light mode. This can be easily achieved with a flag in local storage and some minor changes in the JavaScript part.

The creators of Jest (Facebook) have found a better way: Snapshot tests!

How does it work?

Take a look at the following assertion:

it('should create a foo bar object', () => {
  const result = foo.bar()
  expect(result).toMatchSnapshot()
})

toMatchSnapshot() takes whatever you give to expect(), serializes it and saves it into a file. The next test run will compare the expected value to the stored snapshot and will fail if they don’t match. Jest shows a nicely formatted error message and diff view on failed tests.

This is really useful with generated HTML and/or testing UI behaviour. Just call the method and let it compare to the snapshot.

Updating snapshots

You added something to your code and the snapshot has to be updated? No problem:

jest --updateSnapshot

If you’re using the Jest watcher it’s even simpler. Just press u to update all snapshots or press i to update the snapshots interactively.

What about objects with generated values?

Here’s an example with a randomized id:

it('should fail every time', () => {
  const ship = {
    id: Math.floor(Math.random() * 20),
    name: 'USS Defiant'
  }

  expect(ship).toMatchSnapshot()
})

The id will change on every test run, so this test will fail every time. Well, shit? Nope. Jest got you covered:

it('should create a ship', () => {
  const ship = {
    id: Math.floor(Math.random() * 20),
    name: 'USS Defiant'
  }

  expect(ship).toMatchSnapshot({
    id: expect.any(Number)
  })
})

Jest will now only compare the type of the id and the test will pass.

For certain objects like a date, there is another possibility:

Date.now = jest.fn(() => 1528902424828)

A call of Date.now() will call the mock method and always return the same value.

Some advice

1. Always commit your snapshots! If they are missing, CI systems will always create new snapshots and the tests will become useless.

2. Snapshot tests are an awesome tool, but don’t be too lazy. They are no replacement for other assertion types, especially if you’re working test-driven. Rather use them alongside your other tests.

3. Write meaningful test names. Well, you heard that one before, didn’t you? Really, it helps a lot when tests fail or you have to look inside a snapshot file. Jest takes a test name as an id inside a snapshot file. That’s why you have to update a snapshot after changing the name.

That’s a really odd decision from my point of view. Nearly any HTTP library out there throws errors or rejects the promise in case of a HTTP error.

A Fetch response object has the property ok to determine if the server responded with an error, but that’s not very comfortable to use.

Since my team and I have decided to use Fetch in a Vue-based web app, I decided to create a little wrapper for much more convenience. Say hello to DeliveryGuy.

Usage

Well, surprise, it’s a Node module, so just use any package manager you like. My personal choice is yarn.

yarn install delivery-guy

Example

import { deliverJson } from 'delivery-guy'

const getItems = async () => {
  try {
    const items = await deliverJson('/api/items')
    console.log(items)
  } catch (e) {
    console.error(e.message)
    console.log('HTTP Status', e.response.status)
    console.log('Response Body', e.responseBody)
  }
}

What’s going on here?

DeliveryGuy exports two main functions:

• deliver() will return a response promise like fetch() does.
• deliverJson() presumes your response body contains JSON. It’s basically a shortcut and returns the promise of Response.json().

Both will accept the same two parameters as fetch() does and pass them along.

If the server responds with a HTTP error, DeliveryGuy will throw an error.

Due to the inheritance limitations of built-in classes with ES5 I mentioned in my last post, it’s only possible to set custom properties of a custom error class.

DeliveryGuy provides two additional properties on an error object:

• response has the original response object of a Fetch call.
• responseBody contains the response body and will try to parse it as JSON. If JSON.parse fails, it will return the response body in its original state.

TL;DR

DeliveryGuy allows you to comfortably call the Fetch API without a hassle on HTTP errors. Just use try/catch and you’re done.

Please let me know on GitHub if you have feedback, a feature request or found a bug. Thank you!

Here is a little example of a custom error class:

class MyError extends Error {
  constructor(foo = 'bar', ...params) {
    super(...params)
    
    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, MyError)
    }
    
    this.foo = foo
  }
  
  getFoo() {
    return this.foo
  }
}

try {
  throw new MyError('myBar')
} catch(e) {
  console.log(e instanceof MyError) // -> false
  console.log(e.getFoo()) // -> Uncaught TypeError: e.getFoo is not a function
}

Works fine in any browser with ES6/ES2015 support, but if you transpile the example with Babel to ES5 and execute the code, you will get the results shown in the comments.

Why

Due to limitations of ES5 it’s not possible to inherit from built-in classes like Error, see the Babel docs.

Possible solution

The docs mention a plug-in called babel-plugin-transform-builtin-extend to resolve this issue, but if you have to support older browsers it may not help. In order to work the plug-in needs support for __proto__. Take a guess which browser does not support __proto__ … and of course, it’s the web developer’s best friend aka Internet Explorer. Thankfully it affects only version 10 and below.

Workaround

If it’s not feasible to use the plug-in, you can at least access properties set in the constructor. A call to e.foo in the example is possible, but e instanceof MyError will return false, since you will always get an instance of Error.

Conclusion

Nothing of this is ideal. We have to wait until it’s possible to use ES6/ES2015 directly. Yes, we all could set our transpile targets to ES6/ES2015 today, but our clients usually won’t allow it. Some customer is always browsing the web with an ancient device/browser.

Set-up Jest

Vue CLI

You are using Vue CLI? Consider yourself lucky, the set-up of Jest could not be simpler:

yarn add --dev jest @vue/cli-plugin-unit-jest
vue invoke unit-jest

Vue CLI will do the rest and also create an example spec for the HelloWorld component.

DIY

Install all necessary dependencies:

yarn add --dev @vue/test-utils babel-jest jest jest-serializer-vue vue-jest

Create jest.config.js in your project root directory:

module.exports = {
  moduleFileExtensions: ['js', 'json', 'vue'],
  transform: {
    '^.+\\.vue$': 'vue-jest',
    '^.+\\.js?$': 'babel-jest'
  },
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1'
  },
  snapshotSerializers: ['jest-serializer-vue'],
  testMatch: ['<rootDir>/src/tests/**/*.spec.js']
}

Please adjust the paths in moduleNameMapper and testMatch to your project.

You should also add a modern JavaScript preset to your .babelrc file:

{
  "presets": ["es2015"]
}

Optional step

Add the following line to your .gitignore file:

/coverage

The set-up is now complete. Let’s write a test file!

Writing tests

Here is a little example Vue component:

<template>
  <ul class="demo">
    <li class="demo__item" v-for="value in values" :key="value">{{ value }}</li>
  </ul>
</template>

<script>
export default {
  name: 'demo',
  data () {
    return {
      values: []
    }
  },
  created() {
    this.fetchValues()
  },
  methods: {
    async fetchValues() {
      const response = await fetch('/api/demo/values')
      this.values = await response.json()
    }
  }
}
</script>

The component Demo will fetch some values after its creation and display them in an unordered list. This example is quite simple, but testing is a little more complex due to the usage of fetch, async and await.

Of course, there are some tools to help us:

yarn add --dev fetch-mock flush-promises

Now, let’s write a test:

import { shallow } from '@vue/test-utils'
import fetchMock from 'fetch-mock'
import flushPromises from 'flush-promises'
import Demo from '@/components/Demo.vue'

const values = [
  'foo',
  'bar'
]

describe('Demo.vue', () => {
  beforeEach(() => {
    fetchMock.get('/api/demo/values', values)
  })

  it('renders component', async () => {
    const wrapper = shallow(Demo)
    await flushPromises()

    expect(wrapper.vm.values).toEqual(values)
  })

  afterEach(() => {
    fetchMock.restore()
  })
})

What’s going on?

1. shallow from Vue Test Utils creates a wrapper of the rendered and mounted component, any child components will be stubs. If you need child components in your test, please use mount instead of shallow.

2. fetchMock will create a mocked version of the Fetch API. In this case it will return the defined values for a GET request to /api/demo/values. If you send a request that’s not defined in fetchMock, it will throw an exception and break your tests.

3. The test itself is defined as async to use await for flushPromises(). It will wait until the mocked request is finished and the values are stored in the component’s data.

4. You can now access the data property values and compare the content to the response of the mocked HTTP request.

Conclusion

Setting up Jest for Vue is easy, even if you have to do it manually.

A little warning: setting up Jest for an existing app can be tedious. The current AngularJS app of our customer can’t be tested with Jest, at least for now. The AngularJS HTTP mock does not work and I haven’t figured out the problem yet.

But enough of Angular: the real deal comes with the testing itself. Async/await is a nice and simple way for testing asynchronous behaviour. I don’t think this could be easier and it’s a reliable method with the power of modern JavaScript. Try to imagine what the demo test would look like in ES5 …

Shall we begin?

Modules

Let’s add the necessary modules to the package:

yarn add --dev vue-loader vue-template-compiler
yarn add vue

If you want to use a template engine like Pug or prefer TypeScript over JavaScript, you can add the respective Webpack loader package, pug-loader for example. Webpack will also tell you in detail, if modules are missing.

Webpack

Just add the following rule to your Webpack config:

{
  test: /\.vue$/,
  use: [
    {
      loader: 'vue-loader'
    }
  ]
}

Webpack will now be able to use import statements with Vue single file components.

If you want to have a separate JavaScript file with your Vue application, you can add a new entry point:

{
  entry: {
    'current-application': [
      path.resolve(__dirname, 'js/current-application.js')
    ],
    'vue-application': [
      path.resolve(__dirname, 'js/vue-application.js')
    ]
  }
}

Not fancy enough? How about vendor chunks?

{
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          chunks: 'initial',
          test: /node_modules\/(?!(vue|vue-resource)\/).*/,
          name: 'vendor',
          enforce: true
        },
        'vue-vendor': {
          chunks: 'initial',
          test: /node_modules\/(vue|vue-resource)\/.*/,
          name: 'vue-vendor',
          enforce: true
        }
      }
    }
  }
}

This will separate your vendor files from node_modules into vendor.js and vue-vendor.js. The property test contains a regex to determine which modules should go into the vendor chunks.

Of course, this comes not even close to what Vue CLI can do. I highly recommend to use Vue CLI when it’s feasible. It’s quite easy to configure while not being dumbed down, has an excellent documentation and is very well maintained. At least for our customer’s set-up it would be difficult to use Vue CLI at the moment, but we are eager to migrate to Vue CLI asap.

So I decided to do some tests with the above mentioned versions and the latest LTS version, 6.11.2.

Testing methodology

The Webpack build contains the following tasks:

• Building of two stylesheets with SASS and Autoprefixer
• Transpiling with Babel of a large AngularJS app written in ES2015
• Copying images and some other static files
• Chunking into vendor.js and application.js

Each test ran nine times for each Node.js version.

The tests were conducted in dev mode (no minification, no uglification) with a Debian-based Docker container on Windows 10 Pro with HyperV.

Hardware

• Core i7-7700K (the Docker container had access to all cores)
• 16 GB RAM (8 GB for the Docker container)
• PCIe SSD

As you can see, the system has more than enough power and is significantly faster than my MacBook. Docker on HyperV is incredibly fast and a joy to work with.

Results

The improvement between version 8.2.1 and 8.4.0 is a big deal. V8 6.0 does a great job. Node.js 6 used Crankshaft as JIT, Node 8.0 to 8.2 used a combination of Crankshaft and Turbofan (V8 5.9). As of version 8.3.0 Node.js utilizes only Turbofan with V8 6.0.

About 10% improvement with a minor version is a really big step and I’m really looking forward to the next V8 versions and even more power.

I decided to write a replacement with Webpack 2 and to share it with you: WebCodr/design GitHub repo

First steps

The original setup used the indented SASS syntax and Jade templates. Since the indented syntax is more trouble than it’s worth, I had to convert to the SCSS syntax, a superset of the CSS syntax.

Unfortunately there was a copyright claim for “Jade” and they had to rename the project to Pug. The Jade Node module is still available but unmaintained. It’s time to use Pug.

SASS to SCSS

Don’t worry, that’s quite simple. The SASS people provide a tool called sass-convert and it’s really easy to use:

sass-convert --from=sass --to=scss -R assets/styles/

Just pass the tool the format you want to convert, the new format, -R for recursive conversion and add the directory name. After sass-convert finished, you find the new SCSS files along with their SASS predecessors. You can now delete the old SASS files, adjust your build tool and you’re done.

Jade to Pug

It depends on your templates how easy or complicated this step is. My template files are rather simple, so just renaming the file extensions from .jade to .pug and using Pug instead of Jade did the job. If you are having trouble, there is a migration guide from Jade to Pug.

Using Webpack 2

Webpack 2 isn’t finished yet. The current version is 2.2.0 RC3, but even the Beta versions were stable enough to use it for production purposes.

Here’s my package.json file with all necessary modules:

{
  "name": "WebCodr_Design",
  "version": "2.0.0",
  "scripts": {
    "server": "webpack-dev-server",
    "dist": "webpack --config webpack.config.prod.babel.js"
  },
  "dependencies": {},
  "devDependencies": {
    "autoprefixer": "^6.6.1",
    "babel-core": "^6.21.0",
    "babel-preset-es2015": "^6.18.0",
    "css-loader": "^0.26.1",
    "csso-loader": "^0.2.1",
    "extract-text-webpack-plugin": "^2.0.0-beta.4",
    "html-loader": "^0.4.4",
    "node-sass": "^4.1.1",
    "postcss-loader": "^1.2.1",
    "pug": "^2.0.0-beta6",
    "pug-html-loader": "^1.0.10",
    "sanitize.css": "^4.1.0",
    "sass-loader": "^4.1.1",
    "webpack": "2.2.0-rc.3",
    "webpack-dev-server": "2.2.0-rc.0"
  }
}

I wrote two little helper scripts to run a dev server on port 8080 and to build a production version of the assets, mainly the CSS file. Currently there is no JavaScript file for webcodr. But it would be really easy to add JavaScript to the Webpack config.

The Webpack config or where the magic happens

I can’t stand the old JavaScript syntax anymore, so I write all my stuff in ES2015 and that’s why Babel is present in the dev dependencies.

import webpack from 'webpack'
import path from 'path'
import autoprefixer from 'autoprefixer'
import ExtractTextPlugin from 'extract-text-webpack-plugin'

let extractStyles = new ExtractTextPlugin('[name].css')
let extractHtml = new ExtractTextPlugin('[name].html')

let config = {
  stats: {
    assets: false,
    colors: true,
    version: false,
    hash: true,
    timings: true,
    chunks: false,
    chunkModules: false
  },
  entry: {
    index: [
      path.resolve(__dirname, 'templates/index.pug')
    ],
    post: [
      path.resolve(__dirname, 'templates/post.pug')
    ],    
    'css/application': [
      path.resolve(__dirname, 'assets/styles/application.scss')
    ]
  },
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: '[name].js'
  },
  module: {
    rules: [
      {
        test: /\.pug$/,
        loader: extractHtml.extract({
          loader: ['html-loader', 'pug-html-loader?pretty&exports=false']
        })
      },
      {
        test: /\.scss$/,
        loader: extractStyles.extract({
          loader: [
            {
              loader: 'css-loader'
            },
            {
              loader: 'postcss-loader'
            },
            {
              loader: 'sass-loader'
            }
          ]
        })
      }
    ]
  },
  plugins: [
    new webpack.LoaderOptionsPlugin({
      minimize: false,
      debug: true,
      options: {
        postcss: [
          autoprefixer({
            browsers: ['last 2 version', 'Explorer >= 10', 'Android >= 4']
          })
        ],
        sassLoader: {
          includePaths: [
            path.resolve(__dirname, 'node_modules/sanitize.css/')
          ]
        }
      }
    }),
    extractStyles,
    extractHtml
  ]
}

export default config

Explanations:

• stats: Webpack 2 is really verbose, this options will help to make it shut up. ;)

• entry: I defined three entry points for Webpack. Two for Pug files and one for my SCSS file. The property name is the filename for saving the finished file and the array item points to the source file.

• output: Defines where to put the files and how to name them.

• module: The module rules tell Webpack what to do with different file extensions. Since Webpack 2 is a JavaScript module bundler it creates JavaScript files and we have to use a plug-in to get HTML and CSS files. The extract text plug-in looks for the content of the defined loaders and extracts it into the file you want.

  To convert Pug into HTML I had to use the Pug HTML loader and the HTML loader. The extract text plug-in now knows what to extract of the generated JavaScript files.

  The same goes for SASS. The SASS loader converts SASS into CSS, after that the PostCSS loader applies the Autoprefixer and finally the CSS loader tells the extract text plug-in what to do.

• plugins: webpack.LoaderOptionsPlugin contains the loader config for Webpack 1 loaders. Webpack 2 compatible loaders can be configured directly with the loader definition. As you can see, PostCSS loader and SASS loader are not compatible with Webpack 2 yet.

  After the configuration of the legacy loaders, I just had to add the extraction plug-in instances and that’s it.

When Webpack is started, it will iterate through the entry points and apply the appropriate rules based on the regular expressions in the property test. Each rule applies the loaders in reverse order, so the last loader will be applied first. The loaders themselves obtain their configs from the query as the Pug HTML loader does or from the loader options plug-in, only the extract text plug-in is an exception as it needs two configurations: the loaders and where to put the extracted content.

After Webpack is finished, the files are located in the output directory. There are two files for each entry point: a HTML or CSS file and a JavaScript file. As mentioned above, Webpack 2 is a JavaScript module bundler and can only create JavaScript files without help from plug-ins. Without extraction, these JavaScript files would contain the HTML or CSS code as a Webpack runtime module and could be used within JavaScript.

You could now open one of the HTML files in your browser, but there’s a better way. You would have to manually start Webpack for each change to make … meh.

yarn run server

This will start the Webpack Dev Server on Port 8080. It watches for changes and re-builds all affected files. You just have to reload the browser tab. Not comfy enough? There is a possibility of auto-reloading and even hot JavaScript module replacement which will be explored in a future blog post.

Adding JavaScript support

What do you think? Is it complicated to create JavaScript files with a JavaScript module bundler? Of course not!

Add the following rule to your config:

{
  test: /\.js$/,
  exclude: /node_modules\/*/,
  use: ['babel-loader'],
  options: {
    presets: [
      ['es2015']
    ]
  }
}

Any entry point with JavaScript files will be processed with Babel for ES2015 support. Pretty neat, huh?

Need ES2016 or ES2017? No problem, just add a suitable Babel preset with npm or yarn to your project and adjust the config.

You’re using TypeScript or CoffeeScript? No problem, just look for a compatible loader.

Conclusion

Some say Webpack is too complicated. Well, it can be quite confusing if you’re just using it without knowledge what it really does, but it’s no rocket science.

I used Webpack to replace a rather large and complex collection of Gulp tasks to build the assets for the website of a customer. For certain things like SVG sprite maps I still use Gulp, but all other tasks are done by Webpack faster and way more easy, especially things like hashes in filenames for production purposes or automatically splitting the main JavaScript file into an application file and a vendor file with certain libraries/frameworks like AngularJS.

The same goes for Karma to run the Jasmine tests. Just add the Webpack plug-in for Karma, make some small adjustments to the Webpack config, let Webpack handle the rest and you’re done.

Compared to the old Gulp tasks, the Webpack setup is easier to understand, faster and much more fun to use. New team members do not have to dig into a bunch of Gulp tasks and related helper methods. A quick introduction to the Webpack config is mostly enough to understand how it works.

If you have about 1,000 lines of code with Gulp tasks and helper functions or some really small tasks and about 150 lines of Webpack config, what do you prefer?

TL;DR

Use Webpack 2, it’s awesome. :P

Falls ein externes Script auf einem langsamen Server liegt, muss der Browser warten, bis er es komplett abgerufen und ausgeführt hat. Sollte das aufgerufene Script gar nicht mehr vorhanden sein, wartet der Browser seine Timeout-Einstellung ab, bis er weitermacht. Sicherlich hat jeder schon mal gesehen, dass eine Website nur bis zu einem gewissen Teil angezeigt wird und erst nach ein paar Sekunden der Rest dargestellt wird. Mit sehr hoher Wahrscheinlichkeit, war dies ein nicht mehr vorhandenes oder nur sehr langsam ladendes JavaScript.

Asynchrones Abholen findet erst nach dem Rendern der Seite statt und blockiert daher nichts. Dazu lässt sich bei konsequentem Nutzen von RequireJS der Einsatz von script-Elementen weitgehend vermeiden. Im Idealfall gibt es nur noch ein script-Element, das RequireJS lädt und ein weiteres Script startet, um die gesamte JavaScript-Funktionalität einer Seite zu initialisieren.

Konfiguration

Hier ein simples Beispiel einer Require-JS-Konfiguration mit jQuery:

(function() {
    require.config({
        paths: {
            'jquery': 'libs/jquery/jquery-1.7.1'
        }
    });

    require(['jquery'], function(jQuery){
      jQuery.noConflict();
    });
})();

Zuerst wird RequireJS so konfiguriert, dass jQuery mittels des Keywords “jquery” geladen werden kann. Im Konfigurations-Objekt “paths” wird dafür als Attributsname “jquery” und als Wert der Pfad (ausgehend vom Verzeichnis des Scripts) zu jQuery gesetzt. Anschließend wird require() aufgerufen und als erster Parameter wird ein Array mit den aufzulösenden Abhängigkeiten erwartet – hier jQuery. Man kann hier ein unter “paths” gesetztes Keyword, den Pfad oder auch externe JavaScripts über die URL angeben. Falls es sich um ein Modul handelt, wird auf die Dateiendung “.js” verzichtet.

Im zweiten Parameter wird eine Callback-Funktion definiert, deren Aufruf unmittelbar nach dem Laden der Abhängigkeiten stattfindet. Als Parameter folgen hier die Rückgaben der angeforderten JavaScript-Dateien. In diesem Fall ist es ein jQuery-Objekt, das sogleich in den No-Conflict-Modus versetzt wird, um nicht mit evtl. anderen geladenen Bibliotheken zu kollidieren. Dieses Verfahren ist besser bekannt als Dependency Injection.

Module

RequireJS bietet über die Modul-Definition eine elegante Lösung, Programmbestandteile zu kapseln und Abhängigkeiten (z.B. jQuery) aufzulösen. Aktuell setze ich hier drei Module ein, die Funktionen für einzelne Beiträge (Syntax Highlighting, Lightbox etc.) übernehmen sowie das Tracking über Piwik bzw. Google Analytics starten.

Alle Module sind so aufgebaut, dass sie Abhängigkeiten in Form von Bibliotheken oder anderen Modulen erst auflösen, wenn sie gebraucht werden. Gleichzeitig stellt RequireJS sicher, dass eine Abhängigkeit nur einmal geladen wird und für jedes andere Modul zur Verfügung steht.

Ein Beispiel-Modul:

define(['jquery'], function($) {
    var exports = {};

    exports.init = function() {
        $('body').append('<h1>Hello World!</h1>');
    }

    return exports;
});

Mit define() wird die Moduldefinition gestartet. Anschließend passiert das gleiche, wie in der Funktion require(). Zuerst werden die Abhängigkeiten als Array definiert, danach startet eine Dependency Injection in die Callback-Funktion. An dieser Stelle wird ein Dollarzeichen als Parameter für die Abhängigkeit verwendet, um jQuery wie gewohnt einsetzen zu können. Anschließend wird das Objekt “exports” mit der Methode init() erstellt und zurückgegeben. Wird das Modul an anderer Stelle über require() geladen und das exports-Objekt in die Callback-Funktion injiziert, kann man in ihr die init-Methode aufrufen und damit das Modul starten. Natürlich es ist aber auch möglich, darauf zu verzichten und innerhalb der Modul-Callback-Funktion direkt Code auszuführen.

Um ein Modul an anderer Stelle mit require() zu laden, gibt man den Pfad, ausgehend vom Verzeichnis der RequireJS-Konfiguration, zum Modul an. Wie vorhin schon beschrieben, muss man hierbei auf die Dateiendung “.js” verzichten.

Zu guter Letzt muss RequireJS selbst samt Konfiguration geladen werden:

<script src="js/libs/require/require.js" data-main="js/config"></script>

Ein simples Script-Element hierzu genügt – am besten unmittelbar vor dem schließenden body-Element. Zusätzlich wird mit dem Daten-Attribut “main” noch der Pfad zur Konfiguration mitgegeben. RequireJS bindet das entsprechende JavaScript automatisch ein und startet es.

Fazit

RequireJS ist ein mächtiges Tool, das alleine schon durch die Kapselung in verschiedene Module dem Entwickler sehr viele Vorteile bringt. Durch die immer größer werdende Komplexität von Web-Sites bzw. Web-Applikationen sind andere Formen der Organisation notwendig geworden, die in anderen Programmiersprachen schon von Anfang an vorhanden waren.

Dank der Module mit ihren von RequireJS automatisch aufgelösten Abhängigkeiten durch Dependency Injection, lassen sich schnell und einfach, neue Funktionalitäten in eine Website implementieren, ohne weitere script-Elemente in den HTML-Quelltext einfügen zu müssen.

Bis auf RequireJS selbst werden alle definierten Abhängigkeiten bzw. Module asynchron geladen, ohne das Rendern der Seite zu blockieren. Da Browser asynchrone Anfragen parallel abarbeiten können, werden insgesamt alle Scripts schneller geladen und früher ausgeführt, als es bei einer traditionellen Verwendung von JavaScript möglich wäre.

Das Ergebnis ist ein großer Vorteil für alle Beteiligten. Für den Nutzer wird eine Website mit viel JavaScript deutlich schneller dargestellt, während die Funktionalitäten im Hintergrund nachgeladen werden, ohne dass man etwas davon bemerkt. Aus Sicht der Entwickler bietet RequireJS eine elegante Möglichkeit, schnelle neue Funktionen zu entwickeln, Abhängigkeiten einfach aufzulösen und durch die Module strukturierter zu arbeiten.

Abgesehen von TypeKit und Disqus laufen alle JavaScript-Bestandteile dieser Seite als Modul. Zwar lässt sich TypeKit problemlos als Modul umsetzen, nur werden die Schriften erst nach dem Rendern der Seite geladen. Für etwa eine halbe Sekunde sind die Fallback-Schriften zu sehen, erst dann werden die über TypeKit geladenen Schriften dargestellt. Da das nicht Sinn und Zweck von TypeKit ist und Euch Leser irritiert, wird TypeKit klassisch im head-Element vor den Stylesheets geladen.

Disqus ist dagegen als Wordpress-Plug-In eingebunden und darauf würde ich auch nur sehr ungern verzichten. Ich könnte das Plug-In zwar anpassen, aber damit wäre die Update-Fähigkeit dahin. Da Disqus seine Scripts selbst asynchron lädt, sehe ich auch keine Notwendigkeit, den ganzen Aufwand zu betreiben und Module zu schreiben. Allerdings habe ich andere Plug-Ins wie die Lightbox und das Syntax Highlighting rausgeworfen und durch RequireJS-Module ersetzt, die nun fester Bestandteil des Themes sind. Geladen werden sie aber nur, wenn auch Beiträge vorhanden sind, die eine der Funktionen brauchen.

Falls ich Euer Interesse an RequireJS geweckt habe, könnt Ihr meine Implementierung inkl. eines Ladesystems für Module aus dem HTML-Quelltext heraus im GitHub-Repository meines Wordpress-Themes anschauen oder auch einen Fork erstellen, um damit selbst entwickeln zu können. Falls jemand Ideen oder Verbesserungen hat, ich freue mich über jede Anregung und jeden Pull-Request in GitHub.