[RFC|Merged] Inclusion of jQuery

[brunoais]

@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.

K'ay, appologies accepted.

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.

You mean... Not until the jQuery is loaded all js is blocked and stopped?
I think we should use jQuery only for the hard stuff. Like an appear/disappear with animation where the animation is something like a fade in or a fold. Hard stuff, you see... Another good use for jQuery is modal windows. Those "windows" (that are actually divs) that appear above everything else, with a tab(like) thingy. That is hard stuff and jQuery is good to work with that.
Example bad uses of jQuery are:
AJAX, simple appear and disappear (just changing the class will do), control CSS in any way (except if it's part of its animations), most string manipulations, scrolling (when there are no fancy algorithms here like easing), etc... When it's simple stuff, use the API.

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

They have external access system!
http://www.prefixr.com/api/usage/
We can use php's curl system to access their server and get the correct CSS with the browser prefixes.

[igorw]

We could have the discussion of jQuery vs not jQuery, but I don't think that is a productive use of our time. We use most of the things jQuery provides: element selection, dom manipulation, ajax. As far as I'm concerned, what you are suggesting is not a bad thing in terms of performance, but it makes that code less maintainable and adds a certain amount of complexity. And I'm not convinced it is worth that. The easiest way to handle the current situation is to require jQuery for everything. It avoids having discussions about things that are not so important right now. I'm not saying they are not important in general, I'm saying we have other priorities right now.

Combining, minifying, auto-modifying scripts. As we have discussed numerous times in lots of topics previously, we'd like to use assetic for that. And it will probably not happen for 3.1. While front-end optimization is quite important, I don't think it's the most important thing for us right now. It's something we can fix later.

Now, about depending on third party services like prefixr, this is simply never going to happen. Using a PHP library that does the same thing but is within our control, that may be an option in the future. But that's not something we need to discuss now, and not something we need to discuss in this topic.

[hanakin]

You mean... Not until the jQuery is loaded all js is blocked and stopped?

no i mean remove all the JS within the templates and remove all the unnecessary inline event calls

[brunoais]

You mean... Not until the jQuery is loaded all js is blocked and stopped?

no i mean remove all the JS within the templates

Where will js go? Will all js files become global to all templates?

[hanakin]

it will all go into an external file or files based on weather or not its used in the theme or acp. We can seperat it into what ever however many we need to keep the sanity as we can always parse combine them all and minify prior to inclusion.

This was the main push for the jQuery inclusion in the first place as it has far more efficent and powerful DOM minipulation

I thought I made the RFC for this awhile(seveal months ago) in 3.2 might have to dust it off

[callumacrae]

This was the main push for the jQuery inclusion in the first place as it has far more efficent and powerful DOM minipulation

It's waaaay less efficient, it's just easier to write.

[brunoais]

it will all go into an external file or files based on weather or not its used in the theme or acp. We can seperat it into what ever however many we need to keep the sanity as we can always parse combine them all and minify prior to inclusion.

Wait... What? Are you saying that on every execution of a GET or POST request all js should be minified and included inline with the rest of the HTML? Are you mad?!?!? That destroys, rams, trashes, dumps,... completely the cache system the browsers have. I'm against it. We should minify js files on phpbb3.1 deploy. We should minify MOD's js files. We may join all minified files into 1 (MOD's .js and Core .js) each time a MOD is enabled or disabled/purged. But never every time there's a request. That's pure madness. We may also use cache-control to allow browsers to cache the .js files.
The ultimate way of doing this, in my opinion, works like this:
1 .js file for each MOD (exceptions may exist)
1 .js for each main section of the board (user's access, moderators' access, and the ACP) which makes 3 .js
1 for jQuery
1 for and each jQuery plugin.
All should be in the following order:
1º .js that do not need jQuery (probably it will be 0 but anyway, we may consider them)
2º jQuery
3º jQuery's plugins
4º Forum core .js
5º All MOD .js

All of these should be in the <head> and with the @defer attribute.

[hanakin]

This was the main push for the jQuery inclusion in the first place as it has far more efficent and powerful DOM minipulation

It's waaaay less efficient, it's just easier to write.

as far as attaching it self in the same way that js normaly does it is actually more efficent when you target advanced selectors ou use more resources but it is still more efficent that puting inline html calls for js, including script in the html, or creating hundreds of event handlers.....

Wait... What? Are you saying that on every execution of a GET or POST request all js should be minified and included inline with the rest of the HTML? Are you mad?!?!? That destroys, rams, trashes, dumps,... completely the cache system the browsers have. I'm against it.

No i am saying that all the JS should be parsed when changes are made to generate a minified version that resides on the server wwhich is what is appened to the header or footer however its managed...the way it is done by industry standards... This does not need to be dynamic the point I was trying to make is that we need to have complete seperation of JS from the template it self as iyt is an extension or plugin and not nessecarily part of the template.

We should minify js files on phpbb3.1 deploy. We should minify MOD's js files. We may join all minified files into 1 (MOD's .js and Core .js) each time a MOD is enabled or disabled/purged. But never every time there's a request. That's pure madness. We may also use cache-control to allow browsers to cache the .js files.

this is pretty much what i am saying just in an easier way for the end user as i stated in the other topic.

1. create a seperate template file only for adding what scripts we want to include in the head or footer
2. recommend or package a parser tool possibly in backend that can minify and combine all js files...these are what we include in the template file above
3. This way no matter where we include it at package release the end user can move it to header/footer based on preference, and gives them complete control over the JS and when it is loaded using template variables