Urs Hunkler

Thank you very much Petr for taking the time to write your detailed answers.

@"First you talk about performance, then you want to load two similar frameworks on each page, hmmm."

Please be careful - I do not want to load two Frameworks, I am forced to when I want to work with Moodle in a productive way. That is a big difference. Working with jQuery in many projects and being forced to learn YUI for Moodle work is expensive. Who do you think will be willing to pay for the extra time?

Have you ever spent a moment thinking about the fact that several well known Open Source projects have switched form any JavaScript to jQuery (Joomla, Wordpress, Drupal for example)? Or why several people in Moodle forums ask for jQuery?

jQuery is mainstream in the moment. The jQuery learning curve is much smaller than the YUI learning curve. You can get your job done in less time with jQuery than with YUI. There are lots of sources and books helping to solve jQuery tasks. Many people know how to work with jQuery and can get productive without an extra learning curve. That means for many people working with jQuery is less expensive than working with YUI.

Moodle's core JS framework is YUI - that's ok. What I have always been asking for is not to replace YUI by another framework but to be open and support elegantly incorporating other frameworks. The tendency among Moodle developers seams to be single minded and willing to exclude anything not part of the "Moodle way".

Moodle is not going to rule the competencies and preferences developers have - Moodle can either block out or integrate. From my point of view Moodle will suffer from blocking out and win with integrating.

Some examples about the success/failure with blocking/integrating strategies. Apple is winning by blocking. But they offer the best tools and support possible. Microsoft/Windows looses by trying to integrate anything. They have huge problems finding the right and easy way. UNIX/LINUX wins by integrating. The philosophy is open from the beginning. Not either blocking or integrating will be the right strategy by itself - but the way one or the other is handled and supported. Moodle will never be able to go the blocking "Apple way" - that's why I propose to go the integrating "UNIX way".

You have given some examples how handling jQuery integrating is possible like "2/ load it from $CFG->wwwroot/local/jquery/* local plugin (this is the right place for extra stuff in 2.0)" Ok. To get jQuery loaded with the dynamic loading (and blocking if possible) mechanisms of YUI loader would be much better than creating an extra solution. Do you have an idea how this could be done?

Another very important aspect is if the YUI loader can load jQuery and jQuery plugins in a comfortable way. jQuery is my JavaScript framework of choice. With jQuery I am able to develop within a reasonable amount of time - which means within a amount of time clients are willing to pay for.

About 2 month ago I tried to refactor JavaScript I had written with jQuery using YUI. It's just adding some DOM elements to a page and attaching some CSS and event handlers to it to handle an open/close animation - relatively easy with jQuery. I gave up after two days with YUI because I was not able to solve the task within a reasonable time. I would have needed to write many more lines of code to solve the task with YUI.

Searching the internet brought some few YUI sources to support me with my task. For jQuery I can find many sources and have access to several good books - not a least the new jQuery Cookbook.

In YUI I will not investigate again in the near future. I hope very much Moodle 2.0 will be open and flexible enough to handle other JS frameworks elegantly.

And I read form several postings in the forums that I am not alone with this opinion.

@"I disagree here, the most important thing is to cache JS (and also CSS) in browser and do not issue any extra http request to server."

Hmm. You may read the article series Loading JavaScript: Even a caveman can do it. A long an very interesting read.

Web sites I am involved with will change often because CSS and JavaScript always needs to be enhanced on different parts. It's by no means ready at any time - that's even more true with Moodle sites.

In the article series on page LABjs: why not just concat? part 2 you read:

"Sure, the user’s browser cache is not fully reliable and a significant portion of views happen with empty caches, even with return visitors. But that doesn’t mean we should throw the baby out with the bath water and completely ignore the browser cache as being irrelevant. We should intelligently try and figure out what code is less likely to change, and what code is more likely to change, and separate the two code segments into two files."

So intelligently loading JavaScript with blocking is even better than loading JS from the footer. But restricting the system to one big JS file and hoping the cache will do seams not the right way to go.

I propose to use a flexible loading system. If the YUI loader and the Moodle implementation is handling all issues then this system is ok. If not a better loader should be considered.

@theme/image.php

How do we need to link to images?

Like "$OUTPUT->pix_url('favicon', 'theme')" for images within layout files?

The tab images called from CSS are linked with "url([[pix:theme|tab/right]])". What exactly do the two parts mean?

The second part "tab/right" looks like the path within the "theme/pix" folder and the image name without extension. Can we also set the extension explicitly? May be via a third optional part like "url([[pix:theme|tab/right|png]])"?

Ok, we will see if this approach is flexible enough.

To be able to deliver JavaScript code efficiently it will be necessary to send most JS from the footer. But some JS needs to be sent from the header. How can I define in the theme which JS is delivered from the header and which is delivered from the footer?