@C-Lodder you can do better than that, remove jQuery altogether ?

As if the powers would ever allow that

What is the logic for removing it? From what I can tell all the reasons for it being there today still exists.

I kind of know what jQuery Migrate does to help with older jQuery 1.x upgrades, but I'm not sure it actually has a purpose when you get into jQuery 2 or 3. If it does serve a purpose, we should evaluate that, but if it's useless in jQuery 3 then drop it.

@mbabker jQuery migrate does have a v3.0. It's used to warn users about deprecated or removed warnings in jQuery 3.x.

Rather than add a 752 line, performance killing script, I's suggest putting a link somewhere on JDocs, linking users to a page that displays this information

Is it polyfilling functions or just filling the console log? If it's doing the former, depending on what it is, it might be useful. That said, I've honestly never included Migrate anywhere except for Joomla projects so I don't see the need for it myself.

See https://blog.jquery.com/2016/05/19/jquery-migrate-1-4-1-released-and-the-path-to-jquery-3-0/

@brianteeman - last 2 bullet points:

• Fix any problems identified in the Migrate 3.x warning messages you may see on the console.
• Remove the Migrate 3.x plugin and ensure the page still works properly without it loaded.

You know what? We added Migrate to core because we upgraded jQuery in core knowing it broke stuff and that was mitigating things.

Since 4.0 is using jQuery 3, at this point I'd say if an extension relies on a non-updated jQuery plugin, they can handle loading Migrate themselves.

So ? to merge.

Sounds like this will take us back to the days of extensions installing their own versions of jquery and/or jquery migrate everywhere

Well they should know what jQuery migrate is for and use if for testing purposes, not production.

@C-Lodder if joomla hadnt done it itself for years that would be a valid argument. Sadly its not

@brianteeman I don't think that Joomla has to deliver code that greatly degrades performance. Here is the proof from an experiment I did earlier on today non 3.7:
Default Joomla

Joomla without jquery-migrate, the html5 shims and scripts to bottom:

That's 30% added slowlyness, to satisfy bad coders! GREAT, Let's keep the same concept in J4...

? for removal.

@brianteeman We had to add jQuery Migrate to core and enable it by default otherwise we would have been locked at I think jQuery 1.9.1 until we could break B/C. The first versions of the plugin polyfilled functionality jQuery dropped/broke in 1.10. As we're now jumping to jQuery 3, which has B/C breaks in comparison to the functionally similar jQuery 1.12 and 2.2, AND we are making our own B/C breaking jumps, I don't see the need for us to by default continue to enable Migrate.

If during the run up to the stable release it's found there's a stronger argument for including Migrate than not, we can add it back in. But right now I think we are better pushing for it to not be included.

If during the run up to the stable release it's found there's a stronger argument for including Migrate than not,

If people will test real site upgrades we will know that - sadly that rarely happens - but i guess time will tell

I've had a think about this and I'm going to reject this PR. I believe we have the right compromise already. We do not include jQuery by default in Joomla 4. For those who want it we now have a bundled copy that people can use at their own performance risk. The reality is over the years of Joomla 4 to do jQuery upgrades that will inevitably come, that we likely at some point need to re-enable migrate or be left on an old jQuery version. As a result it makes no sense to remove migrate from the API knowing at some point we will likely need to re-enable it.

I totally accept it should absolutely not be enabled by default for the performance reasons @dgt41 specifies. But I do think that there's no huge reason to remove it totally either thinking longer term.