Why do you replace this "easy" pseudo-HTML with PHP? I really like the idea, but I don't like the fact, that a user have to use PHP for this functionality. in my opinion one of the strength in Joomla! is the easy templating (just take a HTML template and add sone <jdoc:include ... /> stuff), we should not go further the way down to a PHP massacre...

@bembelimen I do hate those jdoc things, but I reverted that part ;)

I agree that you should not replace the jdoc tag with PHP code. That's wrong.

I also don't think it is wise to load all scripts at the bottom of the page. Imho it should be an option like the async and defer one.

Let's face it, not all scripts work when loaded at the bottom and not all devs know how to fix that JS so it works.
There is also no real reason for this B/C breaking change except for some ideology that says scripts have to go to bottom.

@Bakual can I have an example of a script that doesn't work if loaded in the body end?

As said before, you have to deal with the fact that users input script into WYSIWYG editors, developers need to be able to dictate script location and dependencies, and our parsers need to be smart enough to move stuff around. So you would never be able to get away with default loading at least jQuery and Bootstrap in the body.

OK, scrips back to head

PS It's not ideology it's THE FACT that javascript BLOCKS page rendering, meaning that scripts need to be parsed and executed before the browser continue to the next elements.

I know it's a fact that they block page rendering, and they do also when at the bottom.
To be precise, loading the scripts at the bottom doesn't help here much. Googles suggestion is to use their funny script at the bottom which then loads all JavaScript stuff after pageload. Only by using this script, you get the "big" render time improvement. But that script is pretty much useles in a CMS enviroment.
If you care about JS blocking page rendering, there are already two flags which greatly help with that (assync and defer). Unfortunately those are only rarely used.

Depending on what the JS is you might even want it to load at the top before the page renders so that the page renders correclty and you dont get a FUAC.

Measuring things on pure numbers is not necessarily a valid measurement

@Bakual defer is canceled out by inline scripts and async could have severe effects on the ordering and fundamentally on the execution of the scripts.

@brianteeman let me explain my self here: over 60% of the web traffic is mobile devices, most of them on low price and limited capabilities androids. Blocking scripts means blocking the first paint, which degrades hugely the UX (there are a ton of articles from research conducted by amazon google etc that goes a bit further and showcases the bouncing rate)! So if we really care for the product and whom is supposed to serve and even more that we are about to release a new version that already uses outdated and not recommended technics, this is a conversation that we have to do, although it will be painful, because we all know that there isn't a B/C full proof solution here!

A system that forces all JavaScript into the end of the body without any flexibility for scripts input elsewhere is going to fail. If we didn't have a user facing admin UI but were building Symfony or Laravel applications, that might work. As long as we are talking about a system that allows end users to paste script snippets into their site, that behavior has to be accounted for.

WordPress' script enqueue functions have supported loading scripts in the footer since 2009. It's 2017, and much of their core JavaScript still defaults to loading into the head.

Nobody is denying the possible performance/UX improvements that come with changing where these things are loaded in the document. But, until we have a system where an end user can better manage this stuff in the UI, we cannot default to the core templates putting scripts in the body and telling users they can't use inline scripts with any dependencies.

Anywho, all of this is not related to this actual PR. Let's just get the PR merged through and the discussion about moving scripts can be had elsewhere. For people like Dimitris who it sounds like builds sites without any concern for scripts being randomly placed by user input or "bad" extensions, he can freely move the script to the end of the body with this PR applied. For those who don't have that level of control over their sites, nothing changes.

Inline scripts won't play nice also with CSP. I think we tend to balance our thinking here too much towards keeping B/C intact, which, IMHO at least, must be disregarded as unsafe and avoid at all costs.

Anyways this PR doesn't touch the scripts so the net result is the same as before, so let's leave this conversation about the position of the scripts for another issue...

You and I don't disagree much from the philosophical standpoint. But for our user base and their varying levels of skills, unless we're going to give Peter a massive boost in business by telling everyone to use Sourcerer so they can put their scripts into the PHP API without having to write either a module or plugin to add it in, it's too bold of a jump to make by default IMO.

This seems like a logical improvement to me