@dgrammatiko could you please rebase this?

@HLeithner done

can we split this pr please, one "simple" pr that only removes es5 no other changes? is this possible?

can we split this pr please, one "simple" pr that only removes es5 no other changes?

The extra parts are the removal of the focus-visible or there are more? Can do

you removed chosen too, also I don't know the impact of changing template.js from defer:true to type:module

I don't know the impact of changing template.js from defer:true to type:module

type="module" is also embedding defer but also it has narrower scope (a good thing). The template.js is only depends on core.js so it's completely safe. type=module

you removed chosen too

chosen is dead. It was dead back in 2015 when Joomla v4 was started so at some point this needs to be removed. That said I can revert this change (although I don't quite agree with the notion of distributing dead code)

about chosen, we use it on our own site https://developer.joomla.org/joomlacode-archive/tracker-32.html with joomla 4 and the promise is that this should continue without issues. That brings me to 2 questions.

1. are templates using the es5 at the moment, you mentioned they are broken
2. is it possible to move chosen and focus-visible (if this is not replaced by something else automatically) to the b/c plugin?

is it possible to move chosen and focus-visible (if this is not replaced by something else automatically) to the b/c plugin?

Both were reverted but I have no clue how can PHP influence some static assets

are templates using the es5 at the moment, you mentioned they are broken

NO. All the methods (HTMLHelper, WAM) will only include assets (js,css) only if the files exist

Looks good to me.
I would trash chosen, but if people still want it we can keep. Good that it not used by core anymore :)

are templates using the es5 at the moment, you mentioned they are broken

All es5 files is loaded as dependency in j4, all should be fine here.

only final comment do we still not want to use rollup in most cases against the code so that we can use modern js syntax like async/await or similar if we want

Async/await is covered by the existing browserlist: https://caniuse.com/async-functions All versions are either lower. or the exact version (safari) for both modules and async/await

@wilsonge tbh I'm not sure if you're asking that rollup should do or NOT the bundling of every script. If you're asking for using it everywhere then it's already like that with only requirement that the source files end with .es6.js (the .es5.js could also handled by rollup, currently they are NOT, but that will require some changes (rollup will use the iife mode so the scripts should not be wrapped in an iife). If you're asking to opt out the .es6.js from rollup then that would break already a lot of scripts (everything that has an import) and cannot be done until import maps are universally supported (and still you need a polyfill, it exists). That said if the idea is to support import maps then there are changes that need to be done to the Web Asssets Manager so it could render the importmaps script, feature detect the US support, etc. Also keep in mind that unhandled scripts are slower due to their nature (the script will queue more fetches for all the imports...).
Ok, that said the idea, since we decided to move to codebase to es6, was to at some point utilise importmaps. Maybe for Joomla 5 some groundwork could be done so J6 could roll with importmaps as the default option (someone needs to do this work)

OK I will merge this, can you write a explaination in the Manual in 44-50 b/c break section for people like me what the impact means for atum and for cassiopea?

Especially for extension developer? at the moment we load es5 and "es6" version (most of the time). Could there be some strange hacks by 3rd party which would be effected?

thanks

@HLeithner joomla/Manual#85

for people like me what the impact means for atum and for cassiopea?

There shouldn't be any change on the core templates

Especially for extension developer? at the moment we load es5 and "es6" version (most of the time). Could there be some strange hacks by 3rd party which would be effected?

Practically with this PR we remove support for IE11 (or other UA that don't support ES2018). If anyone needs to add support for anything older than 2018 they need to ship their own scripts (and all the related dependencies)

seems the build script is not ready?

https://ci.joomla.org/joomla/joomla-cms/63089/2/2

[Error: ENOENT: no such file or directory, lstat '/******/src/build/tmp/1678611982/media/plg_multifactorauth_webauthn/js/webauthn-es5.min.js'] {

didn't investigated further yet

hmm the build folder is full of 'es5' references maybe they should all get removed?

hmm the build folder is full of 'es5' references maybe they should all get removed?

Done

I was expecting a bigger reduction on the distributed zip file but it is what it is

2mb compress javascript is really mich.

In the build script is also full of es5 stuff

In the build script is also full of es5 stuff

Do you mean this:

The build scripts still handle -es5.js as there are still some scripts that are not yet ES6, eg https://github.com/joomla/joomla-cms/blob/59d23bed3d8c61172bd755c24c3415bacd9d8c44/build/media_source/com_associations/js/sidebyside.es5.js, https://github.com/joomla/joomla-cms/tree/59d23bed3d8c61172bd755c24c3415bacd9d8c44/build/media_source/legacy/js, https://github.com/joomla/joomla-cms/tree/59d23bed3d8c61172bd755c24c3415bacd9d8c44/build/media_source/plg_editors_tinymce/js/plugins/dragdrop, etc

Therefore this script cannot be removed before someone puts some effort to do the conversion

OK thanks, we still have code jquery code^^

OK thanks, we still have code jquery code^^

One file, one administrator view is not that bad...

Any chance you our maybe @Fedik has time to fix this?

the we may move jquery to the BC plugin. (Maybe a bad idea)

then we may move jquery to the BC plugin. (Maybe a bad idea)

You mean registering the HTMLHelper::jquery through a legacy plugin?
What will be the benefit?

Getting rid of jquery ;) but yeah not much more

While developing the b/c plugin I noticed some deeper problem with the deprecation already done for JTable and HTMLHelper...

Moving htmlhelper for jquery to the plugin isn't hard, keeping the functionality is questionable, for example the HTMLHelper for jquery also has a token function which sets the csrf token for the jquery ajax call.

I would like to move this to a Webassetitem, but not sure if this this makes it better and how it have to be changed base on the Joomla own fetch function using the csrf token only for the current domain...

Not sure if its relevant but dont forget the debug plugin uses jquery

Not sure if its relevant but dont forget the debug plugin uses jquery

Back in 2018 I was about to offer converting it to vanilla js but the author wasn't really interested: maximebf/php-debugbar#368

I would like to move this to a Webassetitem, but not sure if this this makes it better and how it have to be changed base on the Joomla own fetch function using the csrf token only for the current domain...

The CSRF on that jQuery script has the same exact issue (leaking) as the Joomla.response. But there are other issues with the Joomla.request that are also valid for $.ajax() (this is not a good place for this discussion).

BTW moving the jQuery to WAM is a B/C break (unless you have a dummy HTMLHelper::jquery that calls the WAM.

For anyone following the jQuery discussion I would like to mention that the maintainers have a plan for jQuery v4 with a bunch of B/C breaks all due to security:

• https://github.com/jquery/jquery/issues?q=is%3Aissue+is%3Aclosed+security
• https://github.com/jquery/jquery/issues?q=is%3Aissue+security+is%3Aopen
• https://github.com/jquery/jquery/milestone/7

Not sure if its relevant but dont forget the debug plugin uses jquery

not planning to remove jquery from joomla, only want to reduce HTMLHelpers because they are not the way to go (if possible).

but completely irrelevant to this pr at the moment. I plan to do multiple Pr for the b/c plugin, if you are interested you can look at my repo.

BTW moving the jQuery to WAM is a B/C break (unless you have a dummy HTMLHelper::jquery that calls the WAM.

HTMLHelper::jquery already already calls the WAM, so no b/c on this, and as sad I would move the jquery htmlhelper to the plugin (not removing it in 5.0). will be an one pr.

regarding jquery 4

if it comes in time I would add it to joomla 5.0 not sure in which form yet.

In case when people worries about b.c. break due to removed assets. We can keep the asset definations, but empty, with flag "deprecated". And remove all es5 js files.

Example for bootstrap,
Before:

{
  "name": "bootstrap.es5",
  "type": "script",
  "uri": "bootstrap-es5.min.js",
  "dependencies": [
    "core"
  ],
  "attributes": {
    "nomodule": true,
    "defer": true
  }
},

After:

{
  "name": "bootstrap.es5",
  "type": "script",
  "deprecated": true,
  "uri": "",
  "dependencies": [
    "core"
  ],
},

This dummies will save the site when some template use it in unknown reasons.

We can keep the asset definations, but empty

I was thinking about that as well, so maybe I should update the PR to eliminate any B/C considerations

@Fedik could you review this? I added the deprecated attribute and nullified the src on the es5 scripts

Looks good.

You reverted your original changes or? Because I see that es5 assets used as dependencies

I tested this with one of my customer sites with my own template using joomla bootstrap and works as expected, I merge this for now and hope for more real world testing for alpha2