jQuery free #

In Drupal 8 we are still enjoying the availability of having jQuery at our disposal. This luxury puts us as frontend developers on an island if we look to the outside community. jQuery has had it’s use in the past, but to ship it on all projects nowadays, is more of an option than a rule.

Living on our jQuery island, creates a steeper learning curve for adopting other JS-framework out there. It distanciates us from learning the core principles of JavaScript itself.

A component in Compony should stay as close as possible to the core principles of the web: HTML, CSS and JavaScript. jQuery is an anti-pattern that if avoidable, should be avoided.

Drupal Behaviours #

Behaviours give us the ability to anticipate Drupal's Ajax-capabilities. Even if you are not using Ajax in your project at the moment, it doesn’t hurt to use behaviours. It will be the difference of your JavaScript breaking or not when more development happens.

Cutting-edge #

We encourage using the latest standard of JavaScript. The Compony Gulp will compile it to JavaScript that is understood by all recent browsers. (more on this in the Gulp-chapter)

JavaScript in custom modules #

Having JavaScript in a custom Drupal module is now also considered an anti-pattern. Contradictory to the recommendation followed by the Drupal-community. Having JavaScript in modules might be a logical decision while creating the module, but it doesn’t make sense at all in a frontend workflow.

In custom modules, there is no Gulp-setup, so it means that these files won’t get linted, browserified, uglified and minified. All the processes that we have to unify our Frontend workflow is bypassed by having JS in custom modules.

Instead, create a new folder in the Compony theme and give it the same name as your custom module. Put the JS in that folder and attach the theme-library to it. You or your frontend-colleague will be thankful for when the client starts browsertesting.