[RFC|Merged] Inclusion of jQuery

These requests for comments/change have lead to an implemented feature that has been successfully merged into the 3.1/Ascraeus branch. Everything listed in this forum will be available in phpBB 3.1.
User avatar
naderman
Product Manager
Product Manager
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Karlsruhe, Germany
Contact:

Re: [RFC|Merged] Inclusion of jQuery

Post by naderman » Mon Sep 26, 2011 3:39 pm

I have no idea why you keep saying this doesn't work for MODs or other templates. It will work perfectly fine. It's a commonly practiced standard. You first load the page with only CSS, and then you add interactivity using javascript and jquery afterwards. Since we want to be able to provide a properly functioning website without javascript anyway, there is no reason why one would be required to use javascript before rendering the page. MODs will easily be able to add javascript files to the footer through template hooks. Why would this be any harder than in the header? And of course a template can use jquery events in a javascript file included in the footer. You shouldn't hardcode js event handlers into the HTML anyway.

User avatar
Arty
Registered User
Posts: 970
Joined: Wed Mar 06, 2002 2:36 pm
Location: Mars
Contact:

Re: [RFC|Merged] Inclusion of jQuery

Post by Arty » Mon Sep 26, 2011 3:47 pm

Never mind, jquery in footer will work. I forgot about template hooks.
Formerly known as CyberAlien.

Free phpBB styles | Premium responsive XenForo styles

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC|Merged] Inclusion of jQuery

Post by MichaelC » Thu Dec 29, 2011 12:43 am

As jQuery 1.7(.1) has been released, even though it has already been merged, wouldn't it make sense to include jQuery 1.7 as per previous discussions, also, wouldn't it make more sense to not merge it until just before the alpha for future releases of jQuery between now and then?
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
brunoais
Registered User
Posts: 958
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC] Inclusion of jQuery

Post by brunoais » Wed Feb 01, 2012 4:37 pm

jQuery and other scripts in the footer is worse for recent browsers (except Opera, it seems) than placing them in the head with these rules.
jQuery should be loaded asynchronosly if the browser allows it, same applies to the other scripts.
It works like this:
  1. We use the defer attribute.
    Under that tag, we place another with the code that checks if jQuery was loaded. If it wasn't, force the load of jQuery.
    After the load is done, we check if the load went well by checking if there were any errors. If there were errors, load the internal jQuery version right away.
    Now deliver the order to execute the js code that depends on jQuery (execute 1 function that will call all the js functions that needs jQuery).
    Onload complete.
I made some testing using firefox 3.5, firefox 3.6, firefox 9, chrome 16, Opera 11.61, IE9 and IE9 emulating IE8 and IE9 emulating IE7.
The test:
Create a page with external 3 .php stylesheets and 3 .php javascript. The 3 were served with the correct headers exactly as if they were .css and .js.
I used .php so that I could fully control the headers and simulate waiting time (sleep()) of huge files and slow internet.
I tried to maintain a constant in the headers between each browser except the cache-control and the choose of returning the status code 200 or 204which I kept changing to check how the browsers react.
The only difference in the code changes I made between tests used for the comparatives which gave these results is to write defer or not in all script tags and send the script tags to bottom or top. All in all it there were 4 test environments.
Results:
All browsers executed the js code in the correct order as the specification states.
The best option, if we ignore Opera, is to place the tags at the Top, in the <head>. If we do give a decent weight to Opera, then place the tags at the bottom.
Using defer is always a good option for non inline scripts (we should get rid of those inline scripts) no matter where we place the script tags.

Requirements of phpbb:
Get rid of all those document.write() and document.writeln() in the js code and replace it with better choices.

No defer vs Defer & script tags at top:
For all browsers except Opera:
The loading time of the page reduced drastically when introducing defer.
Initially it had a loading time of 10,?s and now it only takes 2,?s to fire the load event. This means that it can now load HTML, js and CSS and execute the js in 2s. This results in a reduction of loading time of more than 1/4 of the initial time.

For the browser Opera:
No change at all. All is exactly the same.

Who won?
Script tags with defer, definitely, even with the Opera problem.

Defer vs no defer & script tags at bottom:
For all browsers except Opera:
The loading time of the page reduced drastically when introducing defer. Still, it did took longer than having the tags in top.
Initially it had a loading time of 10,?s and now it only takes 5,?s to fire the load event. This means that it can now load HTML, js and CSS and execute the js in 5s. This results in a reduction of loading time of about 1/2 than the initial time.

For the browser Opera:
No change at all. All is exactly the same.

Who won?
Script tags with defer, definitely, even with the Opera problem.

No defer & script tags at top vs bottom:
For all browsers
The loading time of the page had no significant changes. Even though the contents were available quicker with the script tags on bottom. If I tried to press a button or something it just wouldn't work because js was still not available.
The page was visible after 2s, the js functionality was only available after 10s (after the load event).

Who won?
Script tags at bottom. It's better to get some feedback that the page is loading than just knowing the browser is trying to access the page.


Defer & script tags at top vs bottom:
For all browsers except Opera:
The loading time of the page increased significantly when moving to the bottom.
Initially it had a loading time of 2,?s and now it takes 5,?s to fire the load event. This means that even if we moved the tags to the bottom, the time it took to execute only increased a bit and the loading time for the scripts was equal to the time of the longest script to load instead of being the sum of all of them which is what happens when we don't use defer.

For the browser Opera:
No change at all in the timings. All is exactly the same except that, if the tags are at the top, it does take longer to show that the page actually has content.

Who won?
Needs discussion about the weight we should give to the Opera "bastards" :D. If it weights a lot we should move the script tags to the bottom with the defer. If you think like me:
Screw Opera! It's not my fault it does not know how to work with defer. They can be happy that they see the page. As they can see the page anyway, I ain't doin' anything just for them
then placing the tags at the top is undoubtedly the best option we can ever decide.

Disclaimer:
Don't argue about these times being slow (I know 1s is slow). I just used the sleep() php function a lot so that I don't have to write a lot of code to test speeds. With the help of this function I was able to check if all browsers in the test do know how to process defer correctly and if they work correctly, also.


Note:
In parallel to my tests I also made some scripting to test if there are failures and how to react to them (create a fallback).
After throwing away 3 methods on how to work with fallbacks that work with FF, Chrome and Opera but not on IE, I found a way that works with those 3 and even with the stubborn mule IE7. This code I found is meant to fetch jQuery any way possible using the fallback style and, according to my calculations, uses very little resources and is very fast to execute, for a fallback. When everything goes well, I believe that 3ms of extra processing does not hurt at all (defer used). My fallback time increases to 9ms if defer not used as in Opera.

This post is big but I believe it's informative enugh so that you may discuss my idea and the implementation of defer in the script tags.

P.S. I have a post about using async and defer. I changed my mind studies show that async does not help here, only defer helps.

User avatar
callumacrae
Infrastructure Team
Infrastructure Team
Posts: 1046
Joined: Tue Apr 27, 2010 9:37 am
Location: England
Contact:

Re: [RFC|Merged] Inclusion of jQuery

Post by callumacrae » Wed Feb 01, 2012 4:58 pm

Those tests aren't accurate, at all. You should use the development tools in the browser, and put a specified latency on the connection, instead of testing over either a connection where the latency varies or a connection where the latency is negligible.
Made by developers, for developers!
My blog

User avatar
imkingdavid
Registered User
Posts: 1050
Joined: Thu Jul 30, 2009 12:06 pm

Re: [RFC|Merged] Inclusion of jQuery

Post by imkingdavid » Wed Feb 01, 2012 5:22 pm

Unknown Bliss wrote:As jQuery 1.7(.1) has been released, even though it has already been merged, wouldn't it make sense to include jQuery 1.7 as per previous discussions, also, wouldn't it make more sense to not merge it until just before the alpha for future releases of jQuery between now and then?
I say we wait and include the latest version at the time of the alpha release. It's just extra work if we keep merging the latest right now. If you need to test something only available in later versions before then you can download it and replace it yourself, imo.
I do custom MODs. PM for a quote!
View My: MODs | Portfolio
Please do NOT contact for support via PM or email.
Remember, the enemy's gate is down.

User avatar
brunoais
Registered User
Posts: 958
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC|Merged] Inclusion of jQuery

Post by brunoais » Wed Feb 01, 2012 7:43 pm

callumacrae wrote:Those tests aren't accurate, at all. You should use the development tools in the browser, and put a specified latency on the connection, instead of testing over either a connection where the latency varies or a connection where the latency is negligible.
I did as you told and remade without the use of code to slow down. In order to do that I had to use something heavy so I send this page HTML source code for that.
The results to this test are equivalent to the results in the previous test.
The conclusion of the test I get is also the same:
According to the tests, the perfect way of doing this is as follows:
If phpbb don't care about performance in the current Opera:
Place all the js tags at the head. And decide:
  • Placing them after the CSS can deliver some speed boost about how long does it take to the page to start rendering with the styles.
  • Placing before does the opposite. The styles may take a little more but scripts are ready quicker.
If we do care about performance in the current Opera:
Place all the js tags at the bottom of the body,
Either way, considering that we will only use jQuery
Then, place all script tags in this order:
  1. Non jQuery dependent
  2. jQuery itself
  3. jQuery dependent
The logic behind this is that most script files should execute faster than jQuery while jQuery is "registering" all that code. If they don't need jQuery, then they could execute while jQuery is still being downloaded. And then jQuery executes. In my case, I was able to save 0,5s of loading time by following that specific rule.
Note: All script tags must contain the defer attribute to boost up page load and rendering.
According to the spec, and all browsers tested follows it, when a script execution is deferred it keeps the execution order as they appear in the page. That is really very useful and allow scripts that require scripts to run in a sequence and not randomly.

User avatar
hanakin
Infrastructure Team
Infrastructure Team
Posts: 788
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: [RFC|Merged] Inclusion of jQuery

Post by hanakin » Sat Feb 11, 2012 3:44 pm

@brunoais

I am sorry forgive me for not fully reading that monstrous post I skimmed it and if I am understanding you, you are claiming better performance from header as apposed to footer includes? Is that right, if so no clue what your test scenario was but it can not be anything if not marginal. I could possibly see maybe including the cdn in the header but the JS files themselves makes no frickin sense to include in the header to hold up the loading of the content of the page.

Second you mention some issues with phpbb's current JS then fix it by all means it is a daunting task at best myself and Igor planed on working it all out in properly coded jquery while completely externalizing everything related to the theme that should not be there, when if we get time and including it in the modernized version which at said time would have to be updated to reflect the changes the styles team has been making in my absence. Any help with this would be great.

User avatar
brunoais
Registered User
Posts: 958
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC|Merged] Inclusion of jQuery

Post by brunoais » Sun Feb 12, 2012 12:34 am

hanakin wrote:@brunoais

I am sorry forgive me for not fully reading that monstrous post I skimmed it and if I am understanding you, you are claiming better performance from header as apposed to footer includes? Is that right, if so no clue what your test scenario was but it can not be anything if not marginal. I could possibly see maybe including the cdn in the header but the JS files themselves makes no frickin sense to include in the header to hold up the loading of the content of the page.
About that part I tuned bold:
Please read what I wrote before any critics. Javascript loading does not necessarily hold up the loading of the rest of the page.
Search for the @defer and @async attribute. In this case, the @defer is the best option.
hanakin wrote: Second you mention some issues with phpbb's current JS then fix it by all means it is a daunting task at best myself and Igor planed on working it all out in properly coded jquery while completely externalizing everything related to the theme that should not be there, when if we get time and including it in the modernized version which at said time would have to be updated to reflect the changes the styles team has been making in my absence. Any help with this would be great.
I'll do everything I propose with no problems at all. I just need to request it before anything is made because I don't what to do something and then get my functionality rejected afterwards. I'm not here to work and get my work rejected. I'm here to help developing phpbb and to have all my code accepted. In order to have all my code accepted I need a guarantee that what I am writing will be accepted or, at least, my code is picked up and improved by someone else.

User avatar
hanakin
Infrastructure Team
Infrastructure Team
Posts: 788
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: [RFC|Merged] Inclusion of jQuery

Post by hanakin » Sun Feb 12, 2012 3:26 am

@brunoais

as I said I did not really read it all as it was late and I was on my way to bed so appologies on the first part. As for the JS improvements anything to reduce load times and externalize the JS/CSS from the theme will be benifitial wether your code is used exactly or as something to base it off of is stil extremely benifital.

Possibly a new RFC should be made for 3.2 to completely externalize all the JS/CSS within the theme via jquery. Probably do not need to worry about the already external files for now other than to insure not to break their functionality.

Another thing I was thinking of to improve/reduce the server requests and load times is to abandon the whole whay phpbb handles the css/js files currently. That is to say instead of combining them into a dynamic file or storing them in the DB, rather we should use something similar to this http://net.tutsplus.com/articles/news/i ... version-2/ that combines and compress all the js/css files into a seperate file for loading. How to handle this is up for debate but i feel adding something that combines and compresses files is needed. Their are other features of the refered to software such as support for reading and rendering less and saas files as well as running the code through http://prefixr.com/ to fix or append all the correct vendor prefixes. Woild make creating and editing the themes alot simpler for authors exspecially if they do not have complete understanding of the CSS3 stuff

Post Reply