Thanks for the feedback on this issue. As others have noted and you have may have guessed, it is far from easy to achieve this, and there's a lot of decisions that go into it.
This is something that I have been actively pursuing but, as Tim says, there are often higher priority things to do and if it ain't broke, why break it?
As an example of one place I've been working on recently to move away from YUI dialogues I've been working on MDL-68409
. With that issue I had hoped to do a bigger and more sweeping approach but after a little experimentation I discovered that this was not possible and that a number of really old code paths (10 years+) existed and need to be unpicked first. As a result I've gone for a smaller approach and I'll try and track down those other routes to the older YUI notifications separately.
Another point to consider is that we need to look at whether a 'simple' rewrite is the 'correct' thing to do - i.e. do we literally pull out bits of YUI and use ES6 alternatives? Often it isn't that simple anyway because there aren't simple translations - at least very rarely. Especially when you consider things like Events (YUI vs jQuery vs Native). Additionally you'll find that much of that old code is a minefield to unpick and it isn't as simple as rewriting it. That can be because it ties into a number of other areas - to give an example the File picker has a number of links to the File manager and Repository plugin code. The code for all of those areas is ancient - easily 10 years old, and it's extremely non-trivial to rewrite.
Furthermore in many cases the bigger question is whether we _should_ rewrite them as-is, or whether we should take the opportunity to look at whether those aras need a UI update anyway. Again, to give an example I raised MDL-68408
to look at updating mod_chat to drop all use of YUI2 and YUI3. When I looked into it further it turns out that the existing interface is not accessible, nor does it follow best practices, and needs updates in a number of other ways. My personal take on that issue is that it needs a complete rewrite of the UI where we remove it's theme-in-theme support, and we stop writing HTML on the server
-side and start doing so on the client-side.
Another example of this is in the Activity Chooser. I wrote this for Moodle 2.1, it landed in Moodle 2.3, and was written such that it could be re-used for other places - for example the Question bank chooser. In 3.9 we have completely rewritten the Activity chooser, but we've had to leave the original Chooser dialogue code in place until we can rewrite the Question bank chooser (again) and then we have to deprecate that code (not remove it).
We now recommend writing code for core as ES6 modules in an amd/src directory and we transpile these to CommonJS for use in RequireJS on the client-side. This has been a standard for some considerbale time and we are gradually eroding the older code. We no longer accept code written in other formats (i.e. module.js) with the exception of new Atto plugins.
Regarding Atto, again the question becomes do we continue with Atto, or do we look at an editor like CKEditor? It is not as simple as using a newer version of TinyMCE - the license for TinyMCE has changed for one, and we have to look at how we handle things like translations.
I feel that since we moved to using ES6 modules, and recommending _against_ the use of jQuery in core, and no longer accepting new YUI code, we have picked up pace and converted a lot more code, but there is still a long way to go.
Hope this helps,