Load jQuery from Google APIs

marcov

Is there any particular reason why <?php zenJavascript(); ?> in a theme loads a local copy of jQuery instead of loading it from Google which is faster and uses fewer local resources?

e.g.

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>

instead of:

<script type="text/javascript" src="/zenphoto/zp-core/js/jquery.js"></script>

This would also avoid having to distribute the jQuery libraries along with zenphoto.

For more see:
http://code.google.com/apis/ajaxlibs/documentation/

sbillard

Yes

marcov

Of course there is :-) but what is it? Is the distributed version a modified copy of jQuery? Or some other reason?

sbillard

First, what makes you believe that loading jQuery from google is faster and uses fewer resources? Have you done any measurements? I seriously doubt that would be the case unless you have an extremely lame server.

Second, we do actually try to test Zenphoto. Of course we must control the environemnt if we want to have any chance of having a stable product. Loading a jQuery from some third party source means we have no idea from point to point what version Zenphoto would be using. In case you haven't noticed, versions of jQuery (and much other software) is not always backward compatible.

marcov

It uses fewer resources because it loads jQuery from Google's server, not my host. It does not matter much for me personally, as I my site is very low volume, but it might for some other highly trafficked site.

Also, unless zenphoto uses a modified jQuery lib, you can specify what version to load from Google.

Anyway, I was just trying to find out if you modified jQuery, as I would rather load the lib from Google than my own server.

sbillard

Well, I suppose that if a site is highly trafficked it will have a server with commiserate capability.

acrylian

I also don't think that loading from an external server is really always faster. Actually I am frequently bugged by sites that do load something from other servers (be it Ads or whatever).

amereservant

Well, here I am again following another one of marcov's posts...

What I think would be a nice option is for the javascripts to be registered like WordPress does, so that way dependencies can be listed and the likeliness of duplicates can be greatly reduced.

For instance, say I would like my site/theme to utilize a newer version of jQuery for maybe performance reasons or new features, I can de-register jquery, then register a newer version or one from Google's CDN.

As far as backwards compatibility goes, jQuery is really good at keeping newer versions of it backwards compatible and as long as the script was well-written and not terribly old, it shouldn't have any issues. If someone's hoping a 5-year-old script will work forever without updating it, that's crazy.

But not taking advantage of performance enhancements and newer features because it might make break old code seems like a terrible approach to development to me.
I would think it's up to the designer/developer to test if the newer version breaks something and then to notify you guys what is happening so it can be updated.

Anywho, that's my two cents.

sbillard

Well, I guess you have had a better experience than we have with jQuery upgrades. First, there are often jQuery plugins that need to be updated in tandem. Second we have had in the past horrible problems with our drag and drop sort failing on new jQuery upgrades.

I would think it's up to the designer/developer to test if the newer version breaks something and then to notify you guys what is happening so it can be updated

I presume you are unemployed and not a student so you have infinite time to do such testing. We are a small team and just cannot spend the time to test each and every upgrade. We will never do such testing during the late phases of our release. We have enough of our own problems to deal with.

If someone's hoping a 5-year-old script will work forever without updating it, that's crazy

Now this is simply absurd. Why on earth would a piece of software stop working? I think in fact that the reverse is more likely. If you have a piece of software that has been working for 5 years upgrading it is bound to cause you problems. Surely you are familiar with the developer's quote "if it ain't brok, don't fix it."

You are, of course, welcome to override the distributed jQuery by downloading whatever and placing it in the js folders. But don't ask for help from us when things then fail.

acrylian

I agree to my collegue. Gladly our themes give you quite much freedom how to setup your theme in structure and functionality.

Also, calling scripts from external sources, even as powerful as Google's servers, can make your site slow if those servers are currently high frequented.

amereservant

Well there's two things to this...

First off, when I meant developer/designer, I was referring to the theme designer/developer who would be replacing the built-in jQuery. Then if plugins do not work with their theme, it'd be up to the theme designer to either accommodate their plugin or list which plugins have known compatibility issues with their theme.
I was looking at WordPress's wp_register_script function and I knew it had a version parameter, but it doesn't allow for specifying a version for the dependencies, which would be really nice so it loads the correct version as a fall-back.

The second part is you mentioned updates jacking up the plugins...
Since I was speaking of front-end jQuery loading, this once again should be implemented by the developer and any front-end javascript should be applied by the theme developer and none should be automatically applied.
This way the theme developer will determine which plugins work with their themes (since most have to be manually implemented anyways) and they can also test for javascript errors during development.

This frees you all from having to deal with front-end issues and focus on the core/admin areas instead.
In my new Flickerd theme, I am using a concept idea for the stylesheets that would be an excellent feature to add if stylesheets and Javascripts were registered, which takes all of the stylesheets, compresses them, and combines them into a single file on-the-fly so manual compression isn't necessary and it also improves site performance since it's a single stylesheet that has to be loaded instead of multiple ones.

Since the browser can only load "x" number of files at a time, it's much better to combine files that can be combined so there's fewer to load. Anywho, just an idea...

acrylian

jQuery is the default libary and is actually required by some standard functionality on themes like the admin toolbox, Zenpage search results fold out and some other stuff. This is actually for the convenience of users.

Anyway, you could open a ticket for this.

sbillard

In addition, the Zenphoto version of jQuery is loaded by the front end, so pretty much means that if you want to use a different version you will have to do it on both sides.

amereservant

@acrylian,
What if things such as the Admin Toolbox and/or Search Results Options were done with standard CSS, which would be easy to do, and if the user wants to smooth the actions with Javascript, then they'd have to write the functionality for that?
This way the canvas for the developer is completely free from any default Javascript and it is only added when the designer adds it or a plugin is added.

IF Javascript is required, writing it without the use of jQuery would make for better compatibility, but this would still limit users who may want to customize the behavior of those things.

I'll gladly open a ticket if there's a reason to do so and I'd love to help you guys implement script_register functionality, but I'd recommend that for a major version update since it would be a big change in how themes and plugins are to be written.

sbillard

Again I have to ask you how you have so much time on your hands that you can re-invent the world. You are saying we should not use jQuery but (presumably) reproduce its functionality. That again is absurd.

amereservant

I'm not trying to re-invent the world. I was offering a suggestion that would help with performance and make for less maintenance on your end.
But the attitude seems to be more focused on plugging holes to keep old stuff working and not pushing towards how to tune things so the script performs better and embracing advancements in technology.
Just look at the performance increase with jQuery 1.6 and there was a substantial increase with 1.5 as well, yet ZenPhoto is still running 1.4.
The fact is, updates WILL break things such as older|poorly-coded plugins and themes, but they also open the door for even better things to be made, better performance, and the broken plug-ins and themes can be updated by the designer, ported by someone else, or it gets left behind.

Just waiting for something to break and THEN fix it is a crazy approach unless the goal of ZenPhoto is to be a script that works even on historic setups. People won't quit using old junk until people quit supporting it.

It would be like trying to embrace HTML5 and CSS3 while making it backwards compatible with IE6. At some point you've got to say "If they're using IE6, their experience on the internet is just gonna suck because that's an out-dated program." If they want to enjoy the advancements, upgrade!

sbillard

I understand your intent. Unfortunately I believe you are misinformed.

First, we use jQuery because it provides functinality/ease of implementation important to our product.

Second, current Zenphoto runs jQuery 1.5.1 so you have posted a falsehood.

Third, while there may be performance improvements in general there is no assumption that they will improve Zenphoto use in any significant way. If you are goint to be on the performance bandwagon, you had better have data to back yourself up. For instance, your nice flicker object is very likely slowing things down by trying to consolidate its two CSS files. In the performance monitoring I have done (not on your them) loading a CSS file does not show up on the radar but the filemtime function is one of the top contenders. As well, class instantiation is quite expensive with PHP5. But you knew all this, didn't you.

Your view of Software development is also quite naieve. But please do spend your time on elegance and modern techniques. They are all very nice, but they do not pay the bills.