All theme JS loaded in AMD's first.js.

All theme JS loaded in AMD's first.js.

by Gareth J Barnard -
Number of replies: 10
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Hi all,

Moodle 3.0.1 with TDM on and debugging.  I've noticed that the 'first.js' file when examined in the browser network tab contains 'all' the AMD modules for 'all' the themes installed.  Thus on my M3.0 installation I have one copy of BS2.3.2, two BS3 and one BS4dev because of the themes installed.  Can anybody verify the same sort of thing please?  If so I would have thought it very inefficient to load everything despite only having one theme selected.  Thus breaking the purpose of a modular system.

Cheers,

Gareth

Average of ratings: -
In reply to Gareth J Barnard

Re: All theme JS loaded in AMD's first.js.

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

All AMD modules are loaded via first.js, to improve browser caching and reduce the number of http requests needed. If you want a module to be loaded on demand, rather than being in first.js, then add '-lazy' to the name of the module/js file.

If there are multiple themes installed, then that would imply that per-course or per-category themes are in use (otherwise you should uninstall the other themes). In which case there is a good chance that any given user will encounter more than one theme on a site, so it makes sense to include the js for all the themes in the first.js file. The alternative would be one first.js per theme, which would be even worse if a user encountered multiple themes and had to download all the js each time.

In reply to Davo Smith

Re: All theme JS loaded in AMD's first.js.

by David Scotson -

Will it be possible to alter this behaviour when serving over HTTP/2? In that situation prefilling the browser cache can be done in a much more granular way.

In reply to Davo Smith

Re: All theme JS loaded in AMD's first.js.

by Guy Thomas -
Picture of Core developers Picture of Plugin developers
Shouldn't we be checking for allowuserthemes, allowcoursethemes and allowcategorythemes to decide whether to load all theme JS? Also, it would be nice if themes could be flagged as disabled (even if they are installed) so that the JS isn't loaded unnecessary. Some hosting models will require lots of themes to be available even if the client only wants one to be used.
In reply to Davo Smith

Re: All theme JS loaded in AMD's first.js.

by Gareth J Barnard -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

But Davo with 'https://docs.moodle.org/dev/Javascript_Modules#But_I_have_a_mega_JS_file_I_don.27t_want_loaded_on_every_page.3F' I do want all of my JS loaded, I just don't want other themes' JS loaded too! smile

And I don't have per-course / per-category themes enabled.

In reply to Gareth J Barnard

Re: All theme JS loaded in AMD's first.js.

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
If you do not have per-category or per-course themes, then why do you have other themes installed? In what situation are they used on your site?


In reply to Davo Smith

Re: All theme JS loaded in AMD's first.js.

by Richard Oelmann -
Picture of Core developers Picture of Plugin developers Picture of Testers

Well, it may not be necessary on a production site, other than I don't think we have ever previously had the habit of telling people to remove unnecessary themes if they have tested them and moved on to another - there hasn't ever been a reason previously. But for those of us who either develop themes or more particularly those of us who answer queries on the themes forum (Gareth, myself, Mary and others) will frequently have a dozen or more themes installed on our site - Its far easier than creating a fresh new site for every theme being tested.

The implication of what you are suggesting is that if someone is using a theme created by cloning Clean, they should then delete both Clean and More because they are not needed - what about Base? Or if someone is using a BS3 theme based on Bas' bootstrap as a parent - or even a theme that is built from scratch with no parents - they should delete all other themes because they are not being used? That is certainly not something we have been advocating before.

Average of ratings: Useful (1)
In reply to Davo Smith

Re: All theme JS loaded in AMD's first.js.

by Darko Miletić -
Picture of Core developers Picture of Plugin developers

You can have themes based on other themes for example, or have saas model where all your clients use identical code base. Both valid and used cases.

In reply to Davo Smith

Re: All theme JS loaded in AMD's first.js.

by Gareth J Barnard -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Hi Davo,

Indeed as Richard implies, I do have development sites with many themes.  But that is not the point.  So if I install a Bootstrap version 3 theme then why is all of 'bootstrapbase' JS downloaded too with the redundant BS2.3.2 JS?

And to be honest I've never read anywhere that states you must remove any plugin (theme) you don't use.

Cheers,

Gareth

Average of ratings: Useful (1)
In reply to Davo Smith

Re: All theme JS loaded in AMD's first.js.

by Guy Thomas -
Picture of Core developers Picture of Plugin developers

Including code which is not required is going to cause problems. I've encountered issues with bootstrap 2 javascript being loaded due to the presence of bootstrap base (duplicate tooltips). I can't really remove bootstrap base because clean relies on it. Removing clean sounds like a bad idea to me.

Do the benefits of clumping all the js together really out way the benefits of downloading less javascript in separate files (getting just the javascript you need)?

With HTTP2 being the future standard protocol for all web sites, Moodle should have the capability to serve up separate files according to what the user needs at the point of use.