Page 1 of 1

Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Mon Apr 01, 2019 10:12 am
by darb
Hi Joomlers,

I see this blog post by dgrammatiko and just want to know why the reason still to use mootools for this user consent and privacy plugins? Is this not possible to change and use bootstrap & jQuery instead? its impact for many Joomla sites is obvious like test of dgrammatiko..

The user consent and privacy plugins both have a modal that is not using the already loaded libraries of Bootstrap and jQuery but they are loading yet another library (Mootools) and another modal script. Total size cost: around 200kb. Performance cost per page: over 1-second delay on top of the known delay due to Bootstrap and jQuery of more than 2 seconds (values reflect 3G emulation on Google's Lighthouse).

https://www.dgrammatiko.online/the-hidd ... f-frontend

what you think?

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Tue Apr 02, 2019 3:16 am
by Webdongle
Probably because the devs come and go and each have their own approach ?

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Tue Apr 02, 2019 6:28 am
by Per Yngve Berg
Mootools was deprecated in 3.0

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Tue Apr 02, 2019 7:15 am
by sozzled
So, basically, this discussion topic is just a promotion for someone's blog / personal opinion that hasn't been peer-reviewed or supported by any independent research. In my opinion, the article is a baseless load of garbage.

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Tue Apr 02, 2019 10:45 am
by Webdongle
Now this is interesting ... Is deprecated code actually being used?

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Tue Apr 02, 2019 7:54 pm
by frostmakk
@sozzled
Dimitris Grammatikogiannis is definitively not just a someone, and naming his opinion as baseless load of garbage is immensely disrespectful towards a contributor that has been waist-deep in developing Joomla for years.

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Tue Apr 02, 2019 8:18 pm
by sozzled
As I wrote before, this topic is just advertising for someone's personal blog. There is little information in the article that's mentioned in the opening post that is either based on fact or that has been peer-reviewed. The article states that using jQuery and Bootstrap adds additional load time for people viewing Joomla websites. This assertion has not been confirmed by independent testing/benchmarking. Until that peer review has been undertaken, until extensive benchmarking by independent researchers has established the facts, the article consists of a number of vague assertions and speculation.

If we were to permit discussions on this forum that take one person's op-ed piece (written on their own website) then we could extend it to using the forum to critique just about anything.

The OP asked for comments and feedback. I've given my comments and feedback. I've read other "lounge" topics from the OP in the past and I don't feel that they really help. If there was a performance hit, in terms of using Bootstrap and jQuery, then it pretty much negates all the good work that was done in J! 3.x and the future for J! 4 going forward. So, what are we to do now? Are we to change mid-stream and abandon jQuery and Bootstrap in favour of going back to Mootools? Is that the purpose of this discussion?

Perhaps someone can clarify what is the problem and what we might do about it, please.

In my opinion, the best place to alert the development team to a problem with the new privacy consent features of J! 3.9, is to use the Joomla Tracker. If that's not done then, I have to say, the argument put forward in the article is baseless (at best) and garbage (at worst). Has this matter been reported to the dev team?

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Tue Apr 02, 2019 8:36 pm
by sozzled
Further to the discussion, I tested the privacy consent feature on a test site and, indeed, the privacy notice modal is powered by Mootools (it seems) on the Protostar template. While that's curious, I did not find it to have created any appreciable lag in displaying the consent form. Yeah, it's probably that the consent feature uses some legacy code instead of using a jQUery call.

It's not, however, a "big problem" (as claimed in the article) but it may be worth discussing why the feature was designed that way. Cheers. 8)

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Tue Apr 02, 2019 9:22 pm
by Webdongle
sozzled wrote:
Tue Apr 02, 2019 8:36 pm
... and, indeed, the privacy notice modal is powered by Mootools (it seems) on the Protostar template. ...
Wonder if it's the Privacy modal calls mootools or the Template? If the former then it begs the question 'why does a new feature use deprecated code'?

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Wed Apr 03, 2019 5:10 am
by frostmakk
sozzled wrote:
Tue Apr 02, 2019 8:18 pm
Has this matter been reported to the dev team?
I believe you're missing the point here. Dimitris is part of the dev team, and this is a dev team discussion.

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Wed Apr 03, 2019 5:41 am
by sozzled
I believe, as a member of the community with the right to provide input to GitHub, that if this matter was actually important then the item would have been flagged as something to be actioned. It hasn't. QED

Re: Why use mootools instead of bootstrap & jQuery user consent and privacy plugins?

Posted: Wed Apr 03, 2019 6:34 am
by Bakual
This blog post of Dimitris seems to be quite old then.
Consent uses BS modal since 3.9.1 (https://github.com/joomla/joomla-cms/pull/22926)

If there are still Mootools based modals used, please open an issue on GitHub and it will be fixed.

As for what deprecated means: It means it is planned to be removed (likely with 4.0) but can still be used currently. It's recommended not to use it, but technically there is nothing wrong with using it.