There are couple of things here that need to be solved before this gets merged:

• ES6 is a jargon term, in reality Javascript exist in versions: ES3, ES5, ES2015, ES2016, ES2017 and ES2018 (next year will be another version ES2019 and every year another version). Treating all the ESxxxx versions as one, named ES6, is kinda wrong. In reality the project should decide what pattern it should follow for the Javascript versions. If, let's say, you want to keep a 3 year compatibility (eg browsers that support ES2015+) then there is a need for transpiling newer features to ES2015.

• Server side sniffing has its limits. Eg in this PR you're only checking for IE, but older android default browser has a way bigger user base than IE. This effectively makes Joomla not a really good candidate for site creators in the upcoming markets. The other way to do this is like we're doing it for custom elements, client side:

  joomla-cms/build/media_src/system/js/core.es6.js

  Lines 1014 to 1023 in 0603458

  	/* Check if ES6 then apply the shim */
  	const checkES6 = () => {
  	try {
  	// eslint-disable-next-line no-new-func, no-new
  	new Function('(a = 0) => a');
  	return true;
  	} catch (err) {
  	return false;
  	}
  	};

  
  Problem with this approach is that the scripts will be lazy loaded, which will also be a boost for performance but scripts with DOMContentLoaded will never execute...

@Fedik can you please hold this till I finish refactoring the npm tools:
#23158

ES6 is a jargon term,

yeap, but main thing is a syntax break, eg new variable types conts, let, arrow functions, native classes, all else can be detected by script itself, while running

You can write code as you like, but if you have that fancy syntax, you have to provide es5 version for older browser.

Server side sniffing has its limits.

That true, that why it Optimistic assumption, but it also has pros: it detect whether the requested script has es5 counterpart, otherwise continue to use a regular one.
An existing client side solution blindly replaces an extension in a hope the file exists. I do not like that.

Another solution would be use cookie. eg es6=1, es6=0,
on first load we check if cookie exist,
if not exist, then we test for new Function('(a = 0) => a');,
if it not work we set es6=0, and reload the page.
so on further load there will be .es5.js code loaded.

That also not perfect, because gives 1 additional reload in old browser (on first visit), but will work better than mine idea with "black list".

can you please hold this till I finish refactoring

I am not hurry 😉

This PR can probably be closed as the production department have decided to adopt a browser support policy of PROD2019/005 - Change minimum version requirements for all browsers to n-2 and drop support for Internet Explorer. https://volunteers.joomla.org/departments/production/reports/1031-production-dept-meeting-may-28-2019

@brianteeman if that's the case then Joomla should use type="module" for all the js files (at least the core ones) so this PR might be still useful (of course with needed changes)

That's why I wrote "probably" ;)

Unless you're going to require every JavaScript customization to be run through a compiler, since I doubt browser support for Joomla's methods of media overrides is available, the furthest this PR can go is to just drop the ES5 fallback. If the intent is to require compiling from source to apply customizations/overrides, then HTMLHelper::script() and HTMLHelper::stylesheet() can just be dropped.

I am closing it, there a huge conflicts anyway

Joomla should use type="module"

no, only defer.
tbh, the module API is okay for server side, or when you compile everything,
but for client side it is a creepy piece of 💩