It would be more appropriate to move the doc: scripts at the page bottom

It would be more appropriate to move the doc: scripts at the page bottom

Design an API that lets you move scripts without breaking inline stuff. Otherwise you're going to have a lot of creative hacks and pissed off extension developers dealing with the fact that external resources are being loaded after their scripts require them. That has always been the roadblock to having flexibility in script loading location. The fact the head and script renderers are an all or nothing approach is a side effect of that.

I have tested this item ✅ successfully on 81cf70a

Tested and confirmed that defer is added to the end of the file source and it's loaded at the end of js files loaded in the admin template. I can't see any issues with the loading of pages in the backend.

@mbabker - This is a template JS file, so it doesn't need to be called via HTMLHelper, and can simply be manually loaded as a <script> tag at the bottom.

Well ya, you can do that easily with specific resources. But as a global thing though we need to work on it. If you're using a distributed template (or framework, barf) with several extensions, you can't say with any fairness "load jQuery in the footer and everything that's broken is just crap code". Especially as users can easily input script snippets in content (custom HTML modules, com_content itself, etc.).

I'm a fan of fixing problems, not using workarounds.

Yup, I agree with resources such as jQuery or any other dependencies, but it doesn't apply for this file.

But saying "write the script tag ourselves because we can't do this with the API" is exactly the issue I'm trying to point out. We're bypassing the API to fix a problem instead of fixing the problem in the API. One day I'd like us to actually fix the problem. Is that too much to ask? If WordPress' script/stylesheet enqueuers can handle that, why can't ours?

The way I see it, there are 2 possible ways (may be more but all I can think of atm)

1. Joomla 4 if I rightly remember splits the scripts, metas and stylesheets and they can be called individually, thus you can insert echo $this->getBuffer('meta'); before the closing </body>. This will of course work fore core template, but would require template providers to make the change.

2. We deprecate <jdoc:include type="head" /> and ensure that addScript automatically pushes all scripts to the bottom of the DOM. Rewriting the buffer, or whatever the correct terminology is.

Not say it's too much to ask, I just have no idea how much B/C you're ok breaking with the fix, or if B/C needs to/will be broken at all.

Is not the aim to load it trough the helper that it can be overriden? If it makes sense is another topic.

why would you want to push ALL scripts to the bottom of the DOM?

Less of an issue on the admin side, but you still have to account for inlined scripts running before their dependencies at the end of the body have been loaded. That's why I think we need the API to be able to support scripts in either head or body, not all in one spot. We can default scripts in the body, but we should still be giving the option to put stuff in the head if need be and not take a hard nosed stance of "the only way to load scripts in Joomla is through this PHP API" (because right now every programmatic solution we have hurts users who are copy/pasting script snippets into custom HTML modules as an example).

@laoneo - can you override a template JS file?
@brianteeman - cause, performance.

To be honest I still need to move 90% of the JS to other files because it's in the wrong place

the patch by @laoneo is good, as it is.

a discussion about to split the scripts to head/bottom we can start only when CMS will clearly know the scripts dependencies

@laoneo - can you override a template JS file?

I am not @laoneo ? , but yes, I do plugin and at onBeforeHeadRender I do unset($doc->_script['template.js']) ?

@C-Lodder if ALL scritps are at the bottom then all inline scripts that users add (and boy do they) will all break

@brianteeman - When I say scripts, I mean everything, file or inline

anyway once the conflicts are fixed, just merge

@C-Lodder yes, you can override the file in your template, see here

@Fedik the benefit to load it with the defer flag is that it will be fetched async during page load but executed in sync. When you put it at the bottom of the page without defer, then it is still fetched in sync.

defer is not async AFAIK

I was mentioning the fetch process, not the execution process. It's not loaded async but it is fetched async.

The point that makes huge difference here is the existence of a listener DOMContentLoaded. This means that once this script is parsed will block the rendering till executed. Anyways these were all good tricks 5-7 years ago but in the PWA era all these basically are anti pattern! P in PWA stands for progressive and that means the critical path should have minimal scripts/styles, and once the first rendering of the page is complete all the assets should be then loaded gradually/async. Of course if you still want to support inline scripts (jquery based) then bye bye PWA. Simple as that!

not important to use DOMContentLoaded, there also load event, which dispatched last, when all css/js/images loaded/parsed/rendered, so it will do minimum blocking, even less than placing scripts at the footer ?

Of course if you still want to support inline scripts (jquery based) then bye bye PWA. Simple as that!

You as a site builder can build your site frontend in a way that embraces and supports PWA. We at a core level can do what we need to in order to support the technology. But you try explaining to a non-technical user base that they can't just copy their analytics script snippet and paste it into a custom HTML module and that to add it they have to write a full Joomla plugin or hack away at their template file (which is going to have different instructions per template or framework, ugh) to make it work.

Like it or not, the core platform is going to have to continue supporting all those things you don't like. Because not everybody is going to have the technical ability (or even care to to be quite frank) to do things the way you want them to be done.

But you try explaining to a non-technical user base that they can't just copy their analytics script snippet and paste it into a custom HTML module

TIL google analytics requires jQuery

the core platform is going to have to continue supporting all those things you don't like.

Great. In 2-3 years, a new @dgt41 will popup and try to remove all the crap that was included in J4 until they realise that it's impossible because it will break some very popular 3rd PD extensions...
Let me put it in another perspective:

• J 3.x will be supported till summer 2020 (at least)
• J 4.x needs to keep "outdated best practices" since day 1 but will not be able to drop them when support for 3.x ends.
  I guess you get the irony there...

You and I can build things with all these newer technologies without an issue, we have the technical savvy to understand them. Try to tell a user who doesn't know what HTML or JavaScript is that to insert an analytics script for any service that they have to write PHP code for Joomla to accept it, they can't just paste a script snippet into what looks like an HTML file otherwise it's going to break all the things.

That's the level of balance we're having to have here. Core might be able to default to the things you or I are able to do, but we can't tell the users who are using the CMS because they don't know how to code that to make ANY level of change to the site they have to hire a freelancer or agency. We can guide users, but the day we say "oh you can't do this even though it is an accepted practice, even if antiquated, too bad" is the day we might as well abandon the CMS and go into competition with Symfony or Laravel because clearly we're making an "end user be damned" statement.

TIL google analytics requires jQuery

I assume that was a joke - because it doesnt

@mbabker I don't disagree that web development is getting harder every day. All I wanted to point out is that J3 and J4 will overlap each other for 2 more years and 2 years and with the current pace that the platform introduces new shiny things (mostly available cross browser) is kinda frightening. All and all I'm just trying to alarm people that things might get outdated way sooner that they think (timelines are getting way sorter lately).

Anyways I'm closing this debate (there wasn't nothing here actually to debate) because random people might interpret my comments totally wrong! I just hope that Joomla's pace is in par with that one of the web.

@brianteeman that was way too obvious, wasn't it?