Simple, vanilla js through the web - should I use requirejs?

I've created a very simple bit of javascript, it has no special dependencies. Should I use requirejs for this?
Requirejs feels a bit overkill, given that I have no dependencies such as jquery.
less than 10 lines of JS.

var filter_selects = document.querySelectorAll('.portlet.collectionFilter select');

if (filter_selects.length > 0) {
    [].forEach.call(filter_selects, function(filter_select) {
        filter_select.addEventListener("change", function() {
            location.href = this.options[this.selectedIndex].dataset.url;
        });
    });
}

nowadays, for things like this I simply drop the code in a JS file and then include it using diazo, something like this:

<after css:theme-children="html head">
         <script src="++theme++the.theme/js/my-code.js"></script>
</after> 

We load all custom JS either through a global viewlet or inside the template that needs this code. We will never ever use resource registries again because they are by all means broken.

Thanks for the perspective @zopyx.
And what about requirejs. Do you avoid that too?

The majority of my JS/CSS code in templates looks like this:

Very old style, perhaps weird...but it just works out of the box for all and everything and I don't have to care about the various weird things in the context of resource registries. In particular I can add and change things easily and very fast.

2 Likes

Do you have some transform to append unique query strings to the static assets in case you ever update them, or do you not have to care?

I do not care.

Having no mechanism to bust client side caches is a pretty big loss of functionality in this context. Please do not take such approaches as universally acceptable solutions to the problem scope.

Working for 99.9% of all cases and I don‘t care about the remaining 0.1%. If there is a real need for cache invalidation then I flush my varnish. Life is too short wasting it with resource registry issues. Customers are not willing to pay me for hours and days for finding workarounds when dealing with resource registry issues. We need solutions that are robust and working. That is the case here.

Interesting views. I would have thought that something could be added to bobtemplates.plone to set up the resource registry settings (probably with compilation turned off), the bundle JS, and a template JS file with require js boilerplate.

That should be simple to operate as the diazo or template slot filling methods outlined above, and IIUC would handle caching better.

I thought the (only) point with requirejs is 'dependencies'.(?) And if this is only for one browser view (I am just guessing it is ) and the script is so small: I would say: put it in inline the template (and probably at the bottom to load faster (?).

Also: I think the script might be (theoretically) slightly faster if you can use an id as selector (since there is only one id with the same 'id' the script does not have to 'keep looking through the DOM)

@espenmn Makes a lot of sense, in the context of no dependencies.

Arguments against the resource registries:

  • a bundle can contain only one JS file (but multiple CSS files) but in many cases a bundle should bundle multiple JS files of the same add-ons (e.g. Datatables.js + some of its plugins)
  • a diazo theme is not an option since the JS/CSS that belongs to a particular add-on is usually independent of the theming