Hi Howard,
I am the guilty one, and this is partially deliberate. I'm trying to improve the general JS documentation for Moodle and reduce the number of options to use JavaScript in Moodle - this will hopefully simplify things in the long run.
In my opinion, a YUI module is far preferable over js_init_call() and js() for several reasons:
- YUI modules can define a set of dependencies in the JavaScript rather than PHP. JavaScript dependencies should remain in JS where the loader can handle things properly rather than separating things between disparate locations. This has other benefits when combined with the YUI loader;
- YUI modules are sandboxed and use sandboxed versions of their dependencies. This means that if you depend on moodle-core-notification; and some other third-party developer has also done so but they've changed their view of the module, you won't see their changes (this is a good thing). It means that your code is more guaranteed to work;
- From 2.5, we support shifted YUI modules - these give us linting, and also consistent and reliable minification of code;
- The move to Shifter means that we can more easily write JS unit tests (this is on the JS roadmap);
- A YUI module can have it's own CSS dependencies so you can more easily include CSS which is only used if your module is successfully loaded
- The old js_init_call has a confusing syntax (e.g. the third option should ideally always be false);
- The old js_init_call's fourth option to define an array of module information is less efficient WRT HTTP transactions than getting the YUI loader to do things;
- The old js encourages bad habits, or at least makes it easier to make mistakes (like leaving global variables and functions hanging around)
My preference as JS maintainer is to move away from use of js_init_call. It's not easy to do as a big bang approach, and it will take a long time to remove entirely, but by removing the documentation and leaving documentation for a single way of doing things, I hope to encourage people to write YUI modules which benefit from all of the above.
I can look at adding back some documentation for js_init_call, but it would be new documentation, not a direct reinstatement of the old to try and make the reasoning for it's use clear. I'll try and do this in the next week.
Hope that this clears things up a little and thanks for raising this issue,
Andrew