User tests: Successful: Unsuccessful:
The patch enable use of es6 code by default, and fallback to es5 when it possible.
It use "Optimistic assumption" that most of user has a browser with es6 support,
and for rest of users it has a "black list", so they will get es5 counterpart (if it available).
This need to be done sooner or later.
Note: The patch allow to serve an existing code (non es6) as usual, without renaming to es5.js, untill it get converted to es6.
Apply patch, run npm install
.
Look example in to /media/system/js
, you should notice .es5.js files (eg core.es5.js).
then
Open the site in a browser, click around, all should work as before.
Open the site in IE11, and check the source code, you should see js files with .es5.js extension (eg core.es5.js).
yeap, in 2 words: Joomla! allow to use es6 code aside with non es6 code.
But each es6 file should have es5 counterpart with extension .es5.js
(in the same folder), to use it in older browsers.
Status | New | ⇒ | Pending |
Category | ⇒ | JavaScript Repository Libraries |
Labels |
Added:
?
?
|
Title |
|
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
Title |
|
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
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-06-11 16:24:43 |
Closed_By | ⇒ | Fedik | |
Labels |
Added:
?
Removed: J4 Issue ? |
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
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