[RFC|Merged] Inclusion of jQuery

[igorw]

Added a brief explanation of assets to the coding guidelines.

[naderman]

First off, just so we're on the same page. That part of the JS is obviously going to be template specific and should be in the template, rather than in an asset. While generic javascript functionality can be implemented in further assets, the tying to DOM elements needs to happen on a template basis.

It'd probably be nice to have a minification & concatenation process for JS code anyway. But I'm not sure if there is anything wrong with having a large(would it really be large?) file of JS rather than js code in the middle of the HTML.

[callumacrae]

I have moved jQuery to the bottom of the page. This however means that we cannot use jQuery in any in-line javascript and that we have to stick all of our JavaScript into one huge file.

That trade-off works for me, it forces us to take a clean approach to our JavaScript and properly rewrite any of the existing code. We might want to consider some kind of compilation/concatenation though, because sticking everything in one file is kind of cumbersome in development.

Thoughts?

imo, we should have a file similar to style.php, but for js. This would also mean that nobody will have to develop that js language thing ( ), and it would reduce the amount of HTTP requests (as opposed to lots of different files) without actually having the js in a huge file.

It would also make it possible to (have the option to?) minify the js, if wanted.

It'd probably be nice to have a minification & concatenation process for JS code anyway. But I'm not sure if there is anything wrong with having a large(would it really be large?) file of JS rather than js code in the middle of the HTML.

Nothing wrong with it at all. Reduces HTTP requests, and inline javascript is bad

~Callum

[Oleg]

One file is not required with js in footer any more than it is required with js in header. Page-specific js goes in the footer after the jquery include.

[callumacrae]

One file is not required with js in footer any more than it is required with js in header. Page-specific js goes in the footer after the jquery include.

As opposed to putting it in the same file as the rest of it and caching it?

I don't really understand your post, but were you replying to the reference of inline javascript?

[Oleg]

So basically we offer no guarantees of js compatibility in patch releases?

Well, we had one patch release so far and I hope we dont ever get another one. And I'd say yes, we may ship it with an outdated jQuery in that case.

What I meant was whether, for example, between phpbb 3.1.0 and 3.1.1 we would update jquery from 1.6.x to 1.7.x if there are incompatible changes between those versions.

It'd probably be nice to have a minification & concatenation process for JS code anyway. But I'm not sure if there is anything wrong with having a large(would it really be large?) file of JS rather than js code in the middle of the HTML.

I seriously doubt we will be able to approach jquery's size any time soon. With that in mind I am perfectly fine with concatenating everything for serving js to clients. If it makes sense to keep js files separate for development, that's fine as well.

We should however avoid performing useless operations on page load (e.g. scanning the entire dom for classes that may or may not be present).

We should also make sure we have some form of js code organization, using modules, MVC or what not, as opposed to a bunch of global functions piled one on top of another.

[Oleg]

I keep coming back to versions and compatibility because I believe it is absolutely essential for us to:

1. Have a policy in place as to how we update jquery;
2. Make it straightforward for users and mod authors to determine what version of jquery is actually shipped with a particular phpbb release;
3. As a corollary to #1, make it straightforward for users and mod authors to figure out what jquery versions are going to be, or can be, shipped with the next minor or major release of phpbb.
4. As another corollary to #1, make it straightforward for developers (i.e. ourselves) to know what we can and cannot do with jquery in each development branch we have.

I looked through the current pull request and while the code looks ok, the approach continues to be "throw jquery in there and call it a day". I believe this is simply not acceptable. The points I just enumerated need to be documented in an "official" manner before I would consider any jquery pull request suitable for merging.

Even the policy of breaking jquery compatibility between minor releases, as scary as it sounds, is better than no documented policy at all.

Lastly, I would absolutely love for someone with an interest in jquery making it into phpbb to go over changelogs of recent jquery releases and figure out how often they break compatibility in minor and major versions, and how likely that is going to be a problem for us if we adopt the policy mentioned above of always updating jquery to the latest released version, even in our minor releases.

[callumacrae]

Lastly, I would absolutely love for someone with an interest in jquery making it into phpbb to go over changelogs of recent jquery releases and figure out how often they break compatibility in minor and major versions, and how likely that is going to be a problem for us if we adopt the policy mentioned above of always updating jquery to the latest released version, even in our minor releases.

I'm on it. From what I've seen recently, the stuff they've changed has remained mostly backwards compatible, and the stuff they've deprecated was either not used or the use of was frowned upon.

Watch this space, though.

EDIT:

From what I have seen, compatibility is only accidentally broken, and then fixed again in the next minor release. Any compatibility breakages are seen as bugs. It has happened more than a few times, but only with minor issues.

[naderman]

Backward compatability between which kinds of versions are you talking about? 1.6.x or 1.x?

[callumacrae]

Backward compatability between which kinds of versions are you talking about? 1.6.x or 1.x?

1.x