Seriously.
It's 2011, and this is getting bad...
We have a regular javascript group who meet in Brighton http://asyncjs.com/ and i'm the only person in the group who has to use the damn thing.
Have you ever tried writing an html5 polyfill/shim with it?
Never mind a webapp...
I'm about to be completely ostracised.
Other developers laugh at me in the street.
Please help!!!
Most JavaScript libraries coexist peacefully. I know that several people have created content for Moodle using jQuery, and just this morning, I tossed some GWT onto a custom Moodle page. Unless you're trying to modify the core Moodle functionality, if you really feel strongly about using a different library, you most likely won't have any problems with it.
It's not great practice to load loads of different js libs
Exactly + a huge part of yui javascripts and css are unnecessarely loaded.
In your post 93% of loaded yui css rules are not used at all...
What developers of moodle 2.X themes did was a giant leap forward in the flexibility of themes compared to moodle 1.X themes - maybe we'll see the next giant leap in moodle 3.X themes and activities so that the structure of moodle itself, modularity and flexibility could remain but the look, feel, usability and performance could be further improved...
you can use yahoo yslow to see how slow yahoo yui is.
much loling
Agreed about the giant leap in m2 to try and tame that js beast (blogs.sussex.ac.uk/elearningteam/2011/01/17/things-we-love-about-moodle2-pt1-minify-gzip-excude/) - particularly when we have users running ie6 still, and others on mobile connections.
It is pretty obvious that when you load a page, you don't put lots of unused/unnecessary html on it to slow it down, so why people think its ok to do this with js & css is beyond me!
Lets take a look at this page - http://moodle.org/login/index.php
Can anyone tell me where exactly interaction which requires javascript is on that page?
I assuem you are running YSlow with theme developer mode off, and all the other caching settings as they would be on a live server.
Also, remember that all these files are served with caching headers that mean that each user will only download each file once per session, or even less frequently than that. When you feed a Moodle page to YSlow, it will download everything.
Having said that, the most obviously brain-dead thing that Moodle 2.x is doing is including the file-picker JS on every single page, whether it needs it or not. (This may have been fixed, but I don't think so). There was a reason why that was not very easy to fix, but I am sure it is fixable with a bit of thought.
You probably know enough to answer your own question about what the login page is doing. There is the menu bar across the top, and also the potential for block-docking on every page.
There is also the fact that there is still lots of old JS in Moodle that is not properly packaged as YUI3 modules, so you get catch-alls like javascritp-static.js included on every page.
This is acutally quite a good time to be having this discussion, because at some time all that old JS is going to have to be cleaned up (so we can drop YUI2.9.0 at least). It would be good to have a clear plan of where we want to be going before we convert all that to YUI3.
I think if you asked developers generally they would say we need to be moving away from YUI...
Tim, can you explain why in Moodle two as I see it contradicting strategies for JS and CSS loading are used?
On one side all JS and CSS is pre-processed and cached in one file to need as few as possible requests on page loading. On the other hand YUI uses lazy loading only the needed JS and CSS.
To implement one strategy or the other I understand - but why both strategies are used at the same time I don't get.
I don't really know why you are asking me specifically. This is not something I implemented.
But just by thinking about it briefly, I can see several advantages:
Stuart,
what you suggest here and what you suggested in http://moodle.org/mod/forum/discuss.php?d=186071 are such things that make old dust explode. YES!!!
A year ago many developers of moodle would have laughed here to your suggestion but times and opinions do change... see for example http://tracker.moodle.org/browse/MDL-27622 and Martin saying: " ... (In related news I hope that sometime soon we might even switch from YUI to jquery even for all the other core stuff). "
I remember also many (sad) discussions from the past where a couple of theme designers (Urs, Frank,...) were trying to point some nice features of jQuery compared to yui and response was tough, a basic answer was just that yui is the library that developers of moodle have chosen... but I believe mobile themes (myMobile with jQuery mobile 1.0RC2 ) are really going to be the first core tools using jQuery and after a couple of years people do not even remember why yui was originally chosen...
Today HTML5, CSS3 and JQuery are among the main web design tools / trends that moodle should implement as soon as possible to be at the forefront of learning environments ( - to some themes for a start - not necessarely to all core themes because moodle has always tried to support all kinds of browsers and even devices that have javascript disabled ). I did some testing about implementing HTML5 to moodle 2.0 themes last week as a part of my math tools testing and the results were very promising.
Without any particular preference, isn't YUI 3 fairly JQuerish?
They did a re-write for yui3 which tried to transform the syntax to be more user freindly/like jquery. There is a funny video of this somewhere, but yahoo seem to have taken it down
It actually ended up looking more like this - http://ejohn.org/blog/classy-query/
While I agree that YUI needs to go, I don't think it should be a top priority. Moodle's frontend is a disaster in general and there's no point in trying to put lipstick on a pig. Views need to be separated from everything else and the page logic needs to be brought into line with "m"odular "o"bject "o"riented "d"esign. Once you get separation of concerns, then it gets much easier to decouple Moodle from any particular library.
However, in all fairness to current contributers, the introduction of renderers was intended as a stop gap and I don't think developers have made good use of the new features.
Saying "the introduction of renderers was intended as a stop gap". Is completely wrong.
Renderers are the way that we "separate [views] from everything else and the page logic", and they key point is that they are a way to do that which we can get to one step at a time from where we were in Moodle 1.9.
Here is an example where the all the steps have been completed:
The page logic:
https://github.com/moodle/moodle/blob/master/mod/quiz/summary.php
and the display code:
https://github.com/moodle/moodle/blob/master/mod/quiz/renderer.php#L529
As a developer, I have chosen to break my display code down into bits using methods, but if you want, you could override the renderer and write one bit method that looks like a classic template. You could even make your renderer use a template, like
Saying "the introduction of renderers was intended as a stop gap". Is completely wrong.
Renderers are the way that we "separate [views] from everything else and the page logic", and they key point is that they are a way to do that which we can get to one step at a time from where we were in Moodle 1.9.
You've misunderstood me. By "stop gap", I meant exactly "that they are a way to do that which we can get to one step at a time." In fact, I was expecting this post, and was trying to pre-empt it. You've made this point before, and I took it to heart.
Since these conversations keep coming up, it's clear that developers are yet to fully grasp the power of the renderers. I think that's because with everything as jumbled as it is in the older parts of the code, it's difficult to see how all the pieces fit together.
Based on previous comments you've made, we agree that in the best-of-all-possible-worlds, pages such as the main index.php would be refactored such that their view and logic are separate. It makes it easier to see how all the pieces fit together and how one can use those pieces in creative ways.
Just for kicks, I refactored the main index page into an MVC pattern and it's amazing how much easier it is to understand. Not only that, but it seems to perform better. But most importantly, it gives me power to shape my application. However, I had to refactor 300 lines of code to get there. I think that's ultimately what these conversations are about: developers want to do X with the front end (in this case use jQuery), but they don't see how to implement it. I think it's a structural problem.
I think it is mainly a time problem, and to a lesser extent a knowledge problem. There are just so many things that could be done to Moodle, and we can only do so many now.
With the quiz I was lucky, the people working on the Mobile theme needed the whole thing refactored into renderers, and so did the work (and only introduced about a dozen bugs in the process ). Of course, over the years I had been progressively disentangling the quiz code, so that was probably easier code to work on than some other parts of Moodle.
I keep meaning to write a blog post or a docs page about where we have got to with renderers in the quiz, because I think it is probably good pracitice and worth sharing, but I keep not getting around to it.
Mauno - just to let you know we have been successfully using html5 in our live moodle site (90,000 or so average hits a week) at Sussex since early 2010 - mostly the form elements http://wufoo.com/html5/example/
This year only 40% or our users are on IE (but 52% of those on IE9), so for the majority its a real enhancement to their user experience of the vle, and we get very nice feedback from the tutors about how it makes their job easier.
As long as your doing progressive enhancement as opposed to graceful degradation i can say its only a good thing and we need more of this in moodle
I've been thinking of looking forward with a new "parent" theme that's basically a collection of renderer overrides to rewrite stuff in HTML 5 / CSS 3 and then passthrough to a child theme.
Rewriting the renderers isn't fun because they're such a pain, but keeping it out of the core is also nice.
Are you volunteering to rewrite the file-picker UI in jQuery? Thank you! (To put it another way, there are 1120 mentions of "Y." in 61 files. That is the scope of the work you are asking other people to undertake.)
What is jQuery's record like with maintaining backwards compatibility in each release?
What is jQuery's browser support policy? (The equivalent of http://yuilibrary.com/yui/docs/tutorials/gbs/)
What jQuery's approach to modularising code? That is, how we work so that block_stuartsweirdthingy does not interfere with qtype_timseviltest and vice versa?
P.S. why are you (who are knowledgable enough to work in either YUI or jQuery) so worried about the stupid teasing of small-minded people who only know how to use jQuery?
Not being a developer, and not being involved in using JS since before YUI was barely being discussed, I have always assumed that the primary concern of developers was optimization of code. That was drummed into me when we were learning Cobol, Fortran, then C, given processor speeds and slow and little RAM, it was critical. When we started using html, it then became critical to reduce load times, given transfer speeds then. One Fortran instructor told us, "If it is loading things it does not need, then you have not properly written your code." If YUI is now loading things it does not need, then its useby date has been reached, I would suggest. Have developers become lazy because there are fast processors, rapid transfer speeds, and size no longer matters? mm How....mmmm decadent! Yes, that is the word... Time to move on I suspect and pity it wasn't done with v2.
I never mentioned jquery ;) - but all that tight coupling of the included css stuff, js and html in YUI - it is just a joke right?
If i had to write a file picker i'd use html.
For most of your questions tim, google is your friend.
Currently we have been using documentcloud.github.com/backbone/ - its pretty cool.
Our main problems come when we try and turn off some of the YUI, or even just defer it - there are errors/broken bits galore we have to go fix tight coupling fail.
But seriously, as a small sample of js developers in the world Brighton might be fair reflection of whats happening - who likes to contribute to and use which framework - and thats important. From this small sample YUI is dying, if not already dead and a long term strategy of heavily reliance on the YUI in the core of any cms could be considered rather foolish.
Those 'small minded people' in Brighton (sebleedelisle.com, remysharp.com etc) are unfortunately the exact same people who are pushing the web, and i'd like to have contributing to the future of moodle.
Well, I am not the one who wants to force all Moodle JavaScript to be rewritten, so I should not be the one to be Google searching and making a convincing case.
Plus, suggestions of what not to do are unhelpful.
Make a recommendation what we should do; why; how much work it will be; and how much help you can give to achieve it.
YUI seems to be perfectly usable once you know it, very well engineered (based on the bits of the code I have looked at, and the design principles it seems to employ); and well maintained (judging be the fact that bugs get fixed in new releases).
It also seems to attact a lot of ranting, but I can live with that, becuase I don't see anyone with time to rewrite all the core Moodle JS.
Can you give a simple example of "that tight coupling of the included css stuff, js and html in YUI" and what problem it causes? I don't recognise the problem you are referring to from that description.
http://developer.yahoo.com/yui/
"The YUI Library is a set of utilities and controls, written with JavaScript and CSS"
I'm sure i'm not the only one to spot whats wrong with this statement? I think, like most devs, i like my js and css separated, but find that this just isn't the case with the YUI. You even get html and images thrown in for good luck Now that is tight! I can get more specific if necessary.
Moodle is not helping itself by sticking to the YUI for core. The core should be library agnostic. Using libs should be optional, and not a requirement.
Lots. Lots of work stripping out all the lib js, just as it was/will be stripping out bad php, html, css or poor user interface designs - but in the end moodle will benefit from it - probably more then from spending time on a moodle android app, another api or any more functionality bloat.
Sticking with YUI will cost moodle a lot. Currently it actively encorages more YUI code in the core, plugins, mods etc - which, as we know, leads to greater difficulties further down the road. While the primary methods of interaction/core are tethered to any js lib we limit what can be brought to moodle. There was a great opportunity for m2, so it is a shame to have missed it.
This is a decision i feel will benefit all moodle developers, users and moodle as a community. By untethering moodle from a single library we can open up moodle to take advantage of new developement in js, ui design and interaction to bring it into the modern age.
We don't need to do it tomorrow Tim - but at least allow us an open discussion about it, with the idea of developing it as a requirement for the future of moodle, without being shouted down quite so rapidly.
OK, I'm very interested in this whole issue, particularly as I want our core team focussing heavily on usability and interface in 2.3 and 2.4.
The main reason I'm looking at jQuery at all is because every single developer that walks in here for an interview has already used it. It's more efficient to be working ith a mainstream product (in terms of users). I think at this point a switch from YUI to jQuery is fairly possible using rosetta stones etc, if we do it soon, although it's a lot of work for core and contrib devs.
I don't understand how we can be library agnostic in a practical way. Are you saying that every developer can just pick whatever library they want, and we will just load more and more per page? Won't this kill efficiency? How will developers communicate effectively and share code and review each others code? Can you explain this?
Thanks for jumping in Martin.
I'll try and clarify, but about to go on holiday so have to be quick...
This is what you want, as good web developer employed to tailor Moodle to your institution's needs. A blank slate that you can build on.
If you look back through these forums, you will find many delighted comments when people discovered the built-in navigation menu and so on that comes as standard in Moodle 2.x. These users are important too.
I would also argue agains using any old lib in any old plugins. We need standard things like in-page pop-up windows througt Moodle, and it would suck if we all use different libraries to generate them, so that they all look different. Do not suggest that I should use TinyMCE in the quiz, and you should use HTMLArea in your block, do you?
OT @tim - re:dialogue box (in-page pop-up windows?).
This would appear to be quite a fundamental misunderstanding of what a dialogue box is. A dialogue box is simply a div or other dom element on the screen. As with any dom element, we use css to control what it looks like/where it is displayed etc.
Have a look at this example -
http://jsbin.com/obofoh/6/edit
It is a standard html element with css. There is no magic. No js. No lib. No ui lib.
Using a js lib and a UI lib to control how interface elements on the page looks is a valid paradigm (see jquery mobile) normally applied to closed source or products with a single look/feel. I don't think i have seen this paradigm used in the user facing core of any open source products which allows users to build/apply user themes.
I'm pretty sure that Tim knows how to construct something that looks like a dialog box using HTML and CSS. But to make the dialog box do anything useful (including popping up when needed), you need JS. As well, JS libraries do a lot more than just creating something that looks like a dialog box; they add things like: making the dialog box draggable, making them modal, laying out the contents, making it pop up in a sensible location (e.g. if you're scrolled half-way down the page, it needs to pop up so that it's visible) etc. And they do these things by structuring the dialog box's DOM tree in a specific way. And they probably all do things slightly differently.
The thing is, Moodle already has inconsistent dialog boxes: there's the YUI style, and then there's TinyMCE's dialog. To see them both at the same time, start composing a forum reply, click on the "Insert/edit image" button, and then click on "Find or upload an image".
Yes, it's all DOM elements, and they can be styled similarly, but it's harder to make two different dialog styles look similar (and look good at the same time). And there will still be differences that you can't get around (e.g. if you drag TinyMCE's dialog, you get a semi-transparent placeholder that indicates where the dialog will go, whereas if you drag a YUI dialog, the whole dialog box follows the mouse).
And then there's all the other UI widgets as well.
Hubert - somtimes i'm a bit naughty so appologies to yourself and tim ;)
Your right in that libs can add lots of fun stuff to your standard dialogue, but most of what they do you can do with css.
for your model - try adding a semi transarent bg to that overlay div in the example. for your positioning - again, just try messing with the css (fixed etc). laying out the content is a simple as any html, and i'm sure you know how to make a dialogue apear without a js lib - either with standard js or just a clever html structure.
I'll make a another (hopefully) final post in this thread, which should hopefully explain my reasoning behind which i think using such tightly coupled js ui elements is not a great idea for moodle, which i hope you understand.
cheers
stuart
Sure, you can add your own semi-transparent overlay, calculate the correct position of the dialog on your own, etc, but they you'd be reinventing the wheel, and creating your own JS library, which is exactly the opposite direction that everyone seems to want to go. Everyone wants to use a JS library that is more commonly used, not less.
And I never said that you needed a JS library to make the dialogue appear. I said you needed JS. And again, why would you write your own JS when it's already been written already (and re-written, a dozen times)?
Hubert - At the previous london js conference there was an interesting talk by one of the microsoft IE team (i think?).
He discussed how many pretty simple websites load large amounts of js libs and how over-reliance on js and libs to do things that are trivial in html and css is a bad trend, and i'd tend to agree.
He showed some rather large sites (cnn or bloomberg maybe?) and using firebug and other tools demonstrated the amount of js from libs being loaded either to do things that should really be done with css or html, and lots of js from these libs never being used at all. He talked about how using standard css and html makes things much easier to understand or debug, makes them more accessible and faster to load, and is just a whole heap nicer.
The IE developer was talking about the exact same thing as Colin says - "Have developers become lazy because there are fast processors, rapid transfer speeds, and size no longer matters?".
In the example i posted the transparent overlay and positioning can easily be done with two lines of css :
http://jsbin.com/obofoh/17/edit - no js.
Just for fun, here is some triggering of the dialogue to open and close - no js.
http://jsbin.com/enaren/4/edit (i wouldn't recommend copying this code, but it was fun!)
I find it odd if you think using html and css is re-inventing the wheel - but i'm sure you don't really.
The same goes for using a js lib to do things that are trivial with standard js.
take the example -
document.body.onclick = function (e) { // when clicks occur, do stuff };
By using a single event handler i can capture all my page events and handle events based on the elements that trigger them.
I love js libs - don't get me wrong. I just think over-reliance on them, and using them badly is a modern trend we really don't need.
document.body.onclick = function (e) { ... }
is a classic mistake, particularly in a system like Moodle where a page is made up from mulitple plugins. Think about what happens when your block does document.body.onclick = yourfunction, and my block does document.body.onclick = myfunciton.
The right API design for this is
document.body.addEventListener('click', yourfunction);
which is why they designed the DOM API standard that way.
But then you get the problem that not all browsers support the DOM API flawlessly (at least not when YUI started out, perhaps the situation is better now), which is why you want a JavaScript library that deals with crappy browsers for you, so you don't have to.
Which is what we do in Moodle.
tim - i'm not advocating any pattern for moodle in the comment for Hubert, but trying to illustrate that using standard js isn't re-inventing a wheel.
I'm glad you recognised the pattern i used in the example
document.body.addEventListener('click', yourfunction) is indeed another great example of a simple js pattern which is understood by all js developers, independent of whether they know a lib or not, not your own js, been written already (and re-written, foo* times) and faster for the browser to execute and less code for you to write a than any lib.
This is getting rather silly now
I'm really more interested in your comments on http://moodle.org/mod/forum/discuss.php?d=188627&parent=822687
Thanks for the HTML popup example. I didn't know about the :target pseudo-class, and I probably wouldn't have thought to use it that way. Nevertheless, I don't think such an implementation would be used in real life, for a few reasons:
But it was certainly a neat implementation, and a nice example.
Regarding the semi-transparent overlay, you probably also want to add in a z-index, to make sure that it appear over any other element. And you'll either want a dynamically-generate z-index (because you never know what other z-indexes are already used), in which case you need JavaScript, or else you'll have to say that nobody will ever use a z-index of, say over 1000, and cross your fingers. And yes, you'll need to use a semi-transparent image for old browsers that don't support rgba colours (not just IE, but also older versions of any other browser). You certainly don't want to use both rgba and the image, so you'll probably need to use JavaScript browser detection. And ... does IE6 even support semi-transparent images as backgrounds? I don't know. And that's one of the great things about the JS libs, is that I don't need to worry about these things; the library is supposed to take care of it for me transparently (no pun intended).
I certainly agree with you about over-reliance of JS libs. And I'm happy about Moodle's requirement that things should work without JS. But I don't think that Moodle's usage of JS is an example of over-reliance of JS libraries.
hubert - glad you like the code - as i said, don't use it - for all the reasons you mention.
i'd say it's worth you taking a look at the uncompressed code for some of the js libs - specifically for functionality you might think they 'take care of'. The way they handle it is sometimes good to learn from, and other time they don't do any of what your actually describing. It's worth knowing they are not magic, or how to do the things they do you might currently think are magic.
as for moodles tight coupling with libs with ui in its core - let us just agree to disagree
I failed to respond to your point about coupling of JS/CSS/HTML before, because I had other things to argue about, but it is an interesting point.
I think there has to be some coupling, but it only needs to be one-way.
That is, the JavaScript code has to depend on the static HTML code that was served by PHP. That is, if you want to do progressive enhancement of a particular HTML page, then the JavaScript needs to go and find certain DOM elements.
Of course, the JavaScript may end up generating more DOM nodse.
Then, the CSS exists to style the HTML that is there (both the static HTML from PHP, and any DOM nodes that were added by JS). So, the CSS is coupled to the HTML and JS.
Of course, in Moodle, for a particular page, all that depends on the current theme.
I don't think I explained that very well, but the summary is: The theme generates the HTML; the JS must serve the HTML; the CSS must serve the HTML, including the HTML generated by JS; therefore the JS and CSS also need to be generated by the theme.
I don't think it is helpful to say 'everything is a div'. You might as well say "everything in Moodle is a row in the database". It is true, but unhelpful. What is helpful is to invent higher level abstractions: "Stuart is a user", "This is a forum post", a quiz is made up of questions. This languages of higher leverl abstractions is what lets us build (the back end of) meaningful educational experiences.
Similarly, rather than thinking "this UI is a lot of divs with CSS", we need ot think, "This is a form with these elements"; "this is a navigation bar"; "this is a dialogue box"; "this is a warning"; ... It is only be creating the right language of UI elements that we can build a consistent experience for our users across all the different activities and other parts of Moodle.
Finding the right language will be hard. It is a mixed blessing that over the last 10+ years moodle has evolved into what it is today. That means that there is a lot of existing UI that can be catalogued and classified; but also the evolution has happened without much direction. I suppose I am saying that Moodle's UI languagle is currently English (a hodge-podge of many different things) rather than Esperanto (designed). We need to find our Dr Johnson.
* looks for fb like button *
Some slides on how to do mvc & library agnostic js from Nicholas Zakas of Yahoo.
http://www.slideshare.net/nzakas/scalable-javascript-application-architecture
Martin, the discussion at MDL-28198 will shed some light on the state of the Moodle user interface awareness and how Moodle developers handle the Moodle UI.
Some aspects which hopefully help to enforce you to use jQuery in Moodle:
With jQuery and jQuery UI the actual UI situation would not have emerged as it did with YUI
With jQuery and jQuery UI we would already have consistent dialogs all over Moodle and could use the jQuery Roller to make the dialogs fit in the design. YUI offers one standard UI theme and hardly anybody has managed to create alternatives for it.
YUI is more difficult and you need to write more code
From my experience trying to write code in YUI again and again I learned YUI is more difficult and you need to write more code yourself. Which leads to more errors and a higher rate of different implementations.
Some persons in this discussion say it doesn't matter if you use YUI or jQuery
That's wrong. jQuery know-how you need in many projects - YUI know-how mainly in Moodle.
Many other projects changed their JS libraries to jQuery with great benefit for their users
It's good to know, that others have successfully thrown out their JS they have worked with and switched to jQuery (for example Drupal, Joomla, Wordpress).
The UI JavaScript needs to be rewritten anyhow
As described in MDL-28198 the dialogs need to be rewritten. Why write lots of code with YUI? Take jQuery UI and write the content code and fill it in - all theme designers and most users will thank you for the resulting consistency. And with jQuery much less code needs to be written as a bonus for the developers.
Some quite personal aspects
I am very frustrated in the moment with the possibilities to design the Moodle 2 interface. With the change to 2 I hoped visual Moodle interface design would become more easy. I am very sad to say that this is not true. In some areas you can do more, but in several areas inconsistency and strange development decisions make my live more difficult than with Moodle 1.9.
For example it is a hell to change the look of the custommenu. Digging through the CSS, fighting with IE incompatibilities etc. makes it a nightmare. And I think the basic decision to use a JavaScript generated menu system was wrong. The better way is to use a CSS menu system with JavaScript enhancements. Whenever possible I use the Superfish menu system.
For example why is the theme folder structure hard coded? JS must go into the "javascript" folder, images must to go into the "pix" folder, CSS must go into the "style" folder. Theme designers need the freedom to structure the folder according to their project needs - I feel treated like a child and what for?
Hopefully this long lasting discussion about the Moodle JavaScript library will come to a good end by using jQuery in Moodle.
Urs
While I agree with what you say about using css/html as much as possible and js for the progressive enhancement I do take issue with your point about theme designers needing freedom to structure folders/files.
I find it refreshing that I know that stylesheets are in styles/ and js are in javascript/ You only need to look at Moodle 1.9 themes and the variety of ways that different things were pieced together: includes, requires, calls, hard coding, etc... etc... Moodle2 fixes a LOT of that.
Is it more complex than it needs to be? Probably, is it maybe a little too restrictive? Probably again, but some order is very refreshing. Because at the end of the day, you're themeing a webapp that's designed to be an LMS - it is designed to function a certain way. And function always takes priority over fashion, e.g. this isn't WordPress (as much as I love WP).
I agree pretty much with everything that Urs said in that previous post and find this kind of discussions very useful
There are many good new features in the new theme system http://docs.moodle.org/dev/Theme_changes_in_2.0 and in most cases we do not actually need to /have to do exactly like the guide says. We don't need to use the recommended way to add javascripts to javascript folder, we can for example use layout files like web pages do and add normal script tags there - or add css file tags to layout files - and these files can be even outside moodle itself.
It's good to have consistency to be able to keep main features like headers, main block styles, dialog boxes etc similar looking - like http://tracker.moodle.org/browse/MDL-28198 tries to achieve (in the future when all the yui 2 things are gone...)
What typical cms themes like WP, Joomla or Drupal themes handle better than moodle is still modularity - core moodle is growing all the time like core YUI since people try to build all new features inside the core files while cms systems add optional plugins.
In moodle the capabilities to add/drop/change themes, filters, activities (modules, blocks) and finally in moodle 2 also editors are just great - although partly unfinished.
The main goals for moodle 2 theme changes (set by developers) were:
1) easier theme customisations - both CSS and images
2) simplify core and themes code
3) significant performance improvements
4) solve majority of browser caching problems
5) use YUI CSS foundation
6) allow themes to be stored in separate directory without www access (such as dataroot)
Now when I look back to those goals performance was partly improved by many good changes to caching etc but at the same time YUI css and other YUI stuff spread all over moodle and I actually never wanted to use YUI css in themes and I was wrong in
http://moodle.org/mod/forum/discuss.php?d=131219#p574615
We can select many things in moodle 2 themes but yui javascripts and css are loaded in any case - you can just override the code you don't want to use.
After all there should not be so much difference in designing themes to cms or lms systems. They all have pretty much similar activities (forums, poll/survey blocks/modules, image galleries, repository plugins,...), they all use Wysiwyg editors for editing data and database for saving data. They all are used by different user groups (educational/commercial/...) and they all try to be the best available systems on earth
So you could as well turn that old mantra "Moodle isn't WordPress" to "WordPress isn't Moodle". Moodle has many things that could be improved if things were as freely pluggable as they are in WordPress, Drupal or Joomla. I have used them all
I suppose that our main problem in implementing KISS principle to flexibility of modern web 2 systems (no matter what they are called) was that everything in moodle 1.X was originally so inbuilt that building the new and glorious, fully pluggable Modular Object-Oriented Dynamic Learning Environment took too much developers time with so many old and new features pushing and pulling moodle to different directions... and now we are stuck in situation where developers are tired to even talk about changing some core features to optional features
For example it is a hell to change the look of the custommenu.Second that.
Martin,
since there is clearly one area that yui3 handles worse than jQuery - mobile UI - could some core team start testing at least mobile jquery framework in addition to mymobile theme?
See http://jquerymobile.com/blog/2011/10/28/announcing-themeroller-for-mobile-beta/ and the actual mobile theme roller
http://jquerymobile.com//themeroller/
or
https://github.com/jquery/web-jquery-mobile-theme-roller
It is great to get mymobile theme to core http://tracker.moodle.org/browse/MDL-27622 but it might be even better to make mymobile editable with mobile themeroller ?
Well, YUI3 can in fact offer basic ScrollView for mobiles
http://yuilibrary.com/yui/docs/scrollview/scrollview-base.html
if somebody has time to implement it to themes of moodle 2...
On the other hand companies like Adobe, Google and Microsoft are working in co-operation with jQuery developers to create ready-to-go applications - see for example http://blogs.adobe.com/adobeandjquery/
YUI developers are still discussing about YUI Mobiles - http://yuilibrary.com/forum/viewtopic.php?p=28522 - and at the same time jQuery folks can say:
jQuery mobile framework takes the "write less, do more" mantra to the next level: Instead of writing unique apps for each mobile device or OS, the jQuery mobile framework will allow you to design a single highly branded and customized web application that will work on all popular smartphone and tablet platforms.
Tools like http://jquerymobile.com/themeroller/ make editing of themes available for such people who can't write code or don't know even basic css but have visual talent to design something beatiful - like mobile themes for moodle ( ... and nothing prevents using mobile theme jQuery UI / css classes for desktop themes as well - mobile themeroller is open source and downloadable from GIT )
You may have a look at " "
A screencast from Urs Hunkler on Vimeo.
Dan,
if you check for example the homepage of Moxiecode - the creator of TinyMCE - you get a link to http://www.plupload.com/ that is open source and http://www.plupload.com/example_jquery_ui.php has the Theme switcher button (using the old desktop jQuery theme roller css)
In most cms systems file managers and and image managers are separate applications and you can select different core or commercial plugins for uploading/managing files - like http://www.tinymce.com/js/tinymce/jscripts/tiny_mce/plugins/filemanager/pages/fm/index.html - but moodle 2 is of course a special case since it has a custom way to "store" files.
I was testing 2 days ago implementing https://github.com/jquery/web-jquery-mobile-theme-roller directly to moodle 2 themes and it can be used to add any styles to any activities or tools like file picker if we have certain classes (either the standard mobile-ui css classes or we can use some core moodle classes) with tiny modification to mobile theme roller files. You can check how changing styles of defined classes works in http://jquerymobile.com//themeroller/
Since this is all open source it is actually easy to modify the code to use it even for yui css classes if you want - it just takes some more work to compare yui css and mobile jQuery css classes and implement them to mobile theme roller ui.
Since mymobile theme is coming soon to core themes I would start from that part and create a really functional mobile theming system to moodle 2 with simple core classes (that support consistent look) and ids and customizable additional classes (that support flexible custom css). Then I would continue with simplifying the core javascript stuff like dialogs that Urs mentioned in another post and Sam H had already collected some mixtures of YUI2/YUI3/custom dialogs - if it has to be all yui3 the let it be... and after that I might start looking optional tools for file picker, docks and navigation bars, tool tips etc.
Tim and Sam mentioned that TinyMCE might be the bottleneck of javascript performance. That's partly true if you implement quiz code to init and load 10 separate editors with full init code (with all tinymce buttons, plugins and toolbars) on the same page. TinyMCE supports also jQuery and you could as well implement tinymce to render editor only when needed - when clicked on editable field - and it does not load unnecessary stuff. Furthermore normal pages of moodle that do not use editor should not need editor code (unless you are editing something) and pages of moodle do never need YUIRTE - still if you look at source of this page you can see code including ... yui_combo.php?2.9.0\build\editor\simpleeditor-min.js ... and lots of other unnecessary js and css. If they are loaded why not use YUIRTE instead of tinymce in quizzes and implement the yui file picker to YUIRTE?
I am one of the big fans of TinyMCE and it is the most powerful and flexible open source editor available - CKEditor is the other option - but moodle could use different configuration options that TinyMCE offers in much more flexible way all over moodle. You could for example use different init code based on activities, user selections or create switchers to toolbar of editor or create different skins/editor themes for mobiles (latest versions of tinymce already support contenteditable) etc and if you check for example http://wordpress.org/extend/plugins/tinymce-advanced/screenshots/ they had already a couple of years ago a plugin for managing editor toolbars and buttons with easy to use drag and drop method... a jQuery plugin.
The biggest difference between moodle and some common cms systems UI is in the administration part - moodle 2 has lots of long admin pages with lists and tables and color picker element for selecting colours in settings of themes is one of the rare javascript based tools. Many of these admin pages could be made more user frendly with tiny javascript widgets - no matter if they are yui3 or jQuery...
This is now terribly long discussion already but I add some more data about Tim's and Sam's suggestion about TinyMCE being a bottleneck of javascript performance (in quizzes with lots of editors on the same page). I made a test on my test site and started adding editors to quiz keeping Chrome audits enabled and checked what was going on. The non-logical time serie of one-run test gave results
6 editors 2.87s
9 editors 8.45s
12 editors 5.72s
15 editors 8.44s
18 editors 10.35s
21 editors 5.79s
24 editors 7.29s
27 editors 18.63s
30 editors 19.20s
33 editors 13.03s
36 editors 11.05s
39 editors 22.70s
42 editors 14.58s
45 editors 8.69s
48 editors 22.65s
51 editors 29.23s
In the last (51 editors) case the main file is loaded once but tinymce (tiny_mce.js) calls 51 times "about:blank" so there are 52 document http requests.
There are 160 css file http requests because
- lib/editor/tinymce/tiny_mce/3.4.2/themes/advanced/skins/o2k7/content.css is loaded 51 times
- lib/editor/tinymce/tiny_mce/3.4.2/plugins/spellchecker/css/content.css is loaded 51 times
- theme/styles.php?theme=nameoftheme&rev=193&type=editor is loaded 51 times
Other 7 css files are loaded once.
In all cases there are 12 yui javascripts, 28 editor plugin javascripts (all these plugins are not even used in toolbars but they are still all loaded in init code), 4 other tinymce javascripts and 6 other javascripts used by moodle itself.
So it makes 50 javascript http requests.
And finally there are 38 image http requests.
Total number of http request with 51 editors on page rises to 300
No wonder why loading times are growing (variation is caused by different waiting times). TinyMCE itself is not at all slow as you can see for example in
http://fiddle.tinymce.com/eaaaab or http://fiddle.tinymce.com/baaaab
Martin, what's the state of your plans. Did you decide to switch to jQuery?
If you may need some more info how mainstream jQuery has become you may have a look at the Adobe Fireworks CSS3 Mobile Pack - no more Flash at all but HTML5 and jQuery.
And the O'Reilly classic "JavaScript: The Definitive Guide" added a chapter about one JavaScript framework in the sixth edition: jQuery.
Hi Martin,
We at Ballistic Learning have a steady stream of JavaScript freshers for the next six months. If somebody is ready to mentor our fresheres (2-4 people), I think we may be able to achieve this migration from YUI to jQuery.
Do let me know if this is feasible.
Vikram Solia
(Just to clarify here: what I say here are my current beliefs about what is best for Moodle. However, I am still learning here.)
Why do we use any JS library in core?
Becuse, you cannot do write-once / run-anywhere with JavaScript (yet). Browser support is sufficiently inconsistent that using a JS library that covers most of the worst inconsistencies is a huge saving for developers.
(In answer something Colin said above, Software execution time is not the only think you want to optimise. One is also interested in optimising Software writing time or developer productivity. If it is quick and easy to write new Moodle features, we will get lost more good features.)
Why do we want to try to limit it to a single JS library in Moodle core?
Well, you can change that to "a single ... Moodle core". Consistency is important to keep the software maintainable.
And we don't have consistency with JavaScript yet. We have really old JS that has never been cleaned up. We have YUI2 code, and we have YUI3 code.
We have had a policy for at least the last 18 months that the direction we would head in to get consistency is to try to move everything to modular YUI3 code. That is still not a bad plan. Where we have done that, it leads to code that is better than what we had before.
However, if there is a better plan we can adopt, then we can change direction yet again. Especially since, as Martin says, there is about to be a lot of UI work.
Some thoughts about where the JS belongs in the Moodle code
Here are some observations based on both making core changes to the quiz module display, and then also trying to make ou-specific customisations to that display for the OU in our theme and renderer:
Hi,
I've just been mucking around with jQuery and the Masonry plugin for a course format which I found useful and was brought to this thread by Colin Fraser. I chose jQuery because of its simplicity, cross browser compatibility (If IE died things would be much better for the world) and experience of using its AJAX capabilities with a bespoke Java web server.
However, the YUI lib works and has done so with Moodle for many years. So, what are the benefits of moving to jQuery? Does it do everything and more that YUI does? If the answer to the last two questions are so overwhelming that the refactoring (in a Martin Fowler sence) would be worth the effort. If the answer is not the case, then can the jQuery library be included and only incorporated (from a single URL for browser caching purposes) when required by the developer?
If Stuart you are talking about webapps as new possibilities, then are you considering Java Server Pages for servlets? And therefore Moodle would be written in the same language as its arch enemy Blackboard? Or am I a little out of date with webapp technology?
Coding takes time, testing tasks time, re-coding after refactoring takes even more time - so 'if it isn't broken, don't fix it'. Unless with a major release you decide to perform a total rewrite and get contributors to rewrite their code just in the same way as theme developers experienced when moving from Moodle 1.9 to 2.0.
Cheers,
Gareth
I vote you useful only to cause consternation in the antipodes.
I think that most of us agree that:
I believe that it'd be too difficult to make Moodle completely JS-library agnostic - I'm not sure if it's worth doing it. With 2.2 coming out soon, maybe it's a good time to think about transition from YUI to jQuery? In 2.3 we could have both libraries included by default and advice everyone to start new development in jQuery only. YUI could be dropped at later stage (say in a year). As long as we have some reasonable transition plans, I think everybody should be happy.
Tomasz (Tomek) Muras
I am by no means a developer but I do maintain a small ~10,000 user K-12 Moodle website. I have been watching the developer forum looking for clues as to where Moodle is going.
I am encouraged by Martin's emphasis on UI improvements for upcoming releases. I won't pretend to have an opinion one way or the other on JS libraries but I do hope that whatever version is used that it is consistant and makes things easier for the end user.
Our teachers are raving about the simple Drag and Drop block that has recently been added. These types of improvements to the UI will go a long way with the community. Building Drag and Drop into the core would be most useful especially with the file picker which students and teachers complain takes 3-5 more clicks compared to Version 1.9 to add a file. They have yet to see the opportunity the new file picker presents.
Another big improvement would be a course format that has a web2.0 social feeling such as what http://edmodo.com has where it operates much like facebook/Social Format allowing a teacher to quickly update the class with homework and assignments via an in-page posting form. Add Drag and Drop to the file uploader for adding a post and you have a winning combination! (We might be able to fund this if there are any takers)
I am sure the Moodle Coding Gurus will make the best decision based on a variety of criteria. Whichever lib is chosen, make it sing with enhanced user interactions!
I would use the name Moodle - the framework for the second thing.
It is really a matter of degree. I mean, if you want total flexibility, take PHP + MySQL and build your own LMS outputting whatever HTML, JS and CSS you like.
Of course, you are using Moodle because you want a lot of the work done for you automatically. The question is, how much should be done automatically. You are a web disign expert, so you would like lots of control there, but don't want to worry to much about writing the back-end code.
Someone like me is probably more insterested in the back-end, and just want to be able to easily output a UI that looks good and fits in with how the theme styles other parts of Moodle. (That is an oversimiplification. Quite like UI design.)
Anyway, together, the Moodle plugin system and theme system gets both of us a lot of flexibility, and mostly lets us work together, so there is a lot of good in the framework.
Obviously, Moodle, the framework exists to support Moodle, the product, or to put it another way, Moodle, the product, and all the things we know that people want to do with plugins/themes drive the requirements for Moodle, the framework.
Anyway, I think that one of the key points from this discussion is that in Moodle, JavaScript code should only be output (requried) by the renderer that outputs the HTML the JS affects. Really, I think that simple change solves the problem (once all of Moodle has been properly converted to use renderers).
The only problem with renderer-outputs-JS is where the JS needs a lot of heavy back-end-lifting, for example the filepicker. The work of contacting the repostiory plugins on the server to get lists of files is a fair chunk of code. In these cases, we should aim to restructure the JS so that it splits into a filepicker-ui module and a filepicker-lib. Then you can write a theme-stuart-filepicker-ui module that also uses filepicker-lib. This is a situation where the YUI-loader (Y.use) infrastructre seems to be exactly the kind of infrastructure we need.
You might hope that code modules like filepicker-lib could be independant of any givein JS library, and just use standard stuff, but then in almost all cases, they will want to make AJAX calls to the server, which differ between browsers, so you are back to wanting to use Y.io.
I'd like to add my thoughts here, I'll try to keep them as concise as possible.
I develop a lot of Moodle plugins, and use Javascript wherever I can to provide an attractive and responsive UI. I use YUI, becuase it's included with Moodle and I don't want to be loading a second framework alongside one that's already there for me. I had to learn YUI to do this, having only used Prototype and a little JQuery before. It wasn't a big deal.
I'd be up for any change which would improve the Moodle UI. However, I'm not convinced that moving to JQuery is necessary to achieve that. Some things moving to JQuery would achieve:
So the pertinant questions are:
If the answer to all of the questions is demonstrably "Yes", I'd be for it. Otherwise, I see no compelling reason to abandon YUI3 which is, after all, pretty nice to work with.
One thing I think's worth adding to this discussion is that JQuery is already in Moodle. It's all over the place.
https://github.com/search?q=moodle+jquery
It may not be in core, but it's in contrib. A lot. And it's not going away.
Also: serious security holes may not be in core but are in contrib. A lot. And they're not going away.
Your point?
IMO this whole discussion is ridiculous - YUI3 and JQuery work almost exactly the same, remain current/supported, and it's trivial for any developer who knows one of them to use the other one. If you're developing in Moodle core you can use YUI3. There's no problem. Switching would be a pointless waste of time.
And if somebody wants to use another JS library in contrib they are welcome to do so, just like they're welcome to add their own security holes and critical performance problems and whatever else...
If we're switching APIs for things let's switch an API that actually needs switching. For example the simpletest unit test framework isn't really supported any more and needs switching.
--sam
I've just bumped into this -> http://docs.moodle.org/dev/Using_jQuery_with_Moodle_2.0#Potential_problems <- and it appears that jQuery should only be included once. So, therefore should the main jQuery file be in core with a 'require once' type method call to facilitate choice between developers in using the right tool to solve their paricular problem?
I have no problem with using any different language in the development of a product. It should be the ability of the developer to adapt and use the different tools at their disposal. However, there should be the availability of choice to pick the right tool for the job as with any engineering discipline - except where there is no disernable functionality difference between the estabished and new tool. I also appreciate the need to maintain a standard when dealing with cohorts of separate developers.
So as this argument is sure to persist, I believe it is time to have a 'competition' to see what can be best created, therefore allow jQuery in core to be 'required once' and run along side YUI and see what develops from there. A pragmatic long term decision could always be made to remove jQuery from say Moodle 2.5 and have an upgrade path. But by then who knows what could happen to web development, we could have a complete unified language that does away with the separation of html, css, php, javascript, xml and xslt as they are all different but designed to facilitate the completion of the same task. And we will all be dropping jQuery and YUI like using Java instead of COBOL'83 (no offense intended to COBOL programmers or 'Rear Admiral Grace Murray Hopper').
Cheers,
Gareth
As has been asked of others in this thread: How much of Moodle's existing JavaScript are you volunteering to re-write to use jQuery instead of YUI?
Dear Tim,
I'm not advocating the removal of YUI, I'm suggesting that jQuery should be in core so that it could be included once if a plugin developer wished to use it and then multiple plugins that do use it would not clash with the issue which is raised in the documentation of multiple inclusions.
And indeed I fully realise the implications of rewriting huge swathes of code for no fully justifiable reason. Unless it was proven that the benefits completely out weighed the refactoring effort.
To be honest I'm far more skilled at Java than anything else, so therefore if the argument was to re-write Moodle in Java and have its own embedded web server then I would be happy to volunteer. As for current developments, I spend enough time already with what I have already contributed - proving to me that it is quite an effort just keeping a relatively small piece of code afloat and 'user friendly'.
I'm not 'dissin' YUI at all, I just think that there should not be closed doors to new technology. As long as it is carefully thought out and considered, which is what I'm getting at with my post in suggesting the provision of an environment where qualified comparisions can be made between the two frameworks in a scientific and measureable manner.
Cheers,
Gareth
Sam,
IMO this whole discussion is not at all ridiculous
It is possible that contrib code has some serious security holes and even core code can have some serious security holes but they are not caused by jQuery or YUI, they are caused by those people who wrote that buggy code...
The main reasons why so many web sites are interested in using jQuery instead of YUI3 can be found with google - try for example searches like "best jQuery" - "best HTML5" - "best CSS3" ... and finally "best YUI" or "best YUI3".
When you click some of those jQuery/HTML5/CSS3 links you should find lots of exciting new stuff, inspiration for design, free and downloadable widgets, demos, ideas. Millions of them. When you click the YUI links they give pages written mostly by yui developers - best practises, theory and a couple of widgets
But it's not only a question about adding some flash like animations or button effects - most of all it's a question about designing a nice looking and interactive user interfaces with simple steps. And a couple other reasons like http://blogs.msdn.com/b/dorischen/archive/2010/08/27/top-8-reasons-why-jquery-is-so-popular.aspx
As part of my job I teach Javascript. To make things more interesting I like my teaching to include a pre-written library so the students can do some fancy stuff without huge amounts of programming. I was highly motivated to use YUI for this purpose as I have a great interest in Moodle development. However the degree of support and code for jQuery meant I have been teaching jQuery.
This weekend I bought a popular magazine with a jQuery feature on the cover. I recently downloaded YUI with the intention of learning it for moodle development purposes. I did not get around to it, as it would have required hours of additional learning. I have a finite amount of time to learn new technologies. jQuery seems to be winning the popularity wars.
To answer Tims question I'll do the rewrite of all the code, can you wait till 2050 for it to go live (grins).
Interesting Frank - this led me on a quest on Amazon (rather like navigating the real amazon rain forrest) and I discovered the 'Moodle Javascript Cookbook' by 'Alastair Hole' (http://www.amazon.co.uk/Moodle-Javascript-Cookbook-Alastair-Hole/dp/184951190X/). It covers YUI 3 and indeed in 'Chapter 9, p148' according to the contents preview there is a section called 'Adding the jQuery framework. The book appears to get good reviews at the time of posting.
Cheers,
Gareth
I was one of the reviewers of Alastair's Javascript Cookbook and it does give some basic examples about using core javascripts and adding custom examples but "Adding the jQuery framework" is perhaps a little missleading... "Adding jQuery scripts to moodle" might be a better title there. The book does not explain any pitfalls of using several javascript libraries at the same time.
For example http://docs.jquery.com/Using_jQuery_with_Other_Libraries tells that
The jQuery library, and virtually all of its plugins are constrained within the jQuery namespace. As a general rule, "global" objects are stored inside the jQuery namespace as well, so you shouldn't get a clash between jQuery and any other library (like Prototype, MooTools, or YUI). That said, there is one caveat: By default, jQuery uses "$" as a shortcut for "jQuery"
and as a general rule jQuery scripts in moodle might need to use always "jQuery" - not "$" - in scripts or override the $-function http://docs.jquery.com/Using_jQuery_with_Other_Libraries#Overriding_the_.24-function
Why? For example because Prototype is not the only conflicting library using $:s as well - for example MathJax, LatexmathML and some math filters can use $:s to render mathematical notations and if filters are used before javascripts or if custom math scripts are used before custom jQuery scripts $:s can be filtered from body source and all the rest javascripts can be broken - which usually leads to a blank page or other strange effects.
Or timing issues (scripts do something when some event is ready - or wait... ) / event handler conflicts (for example scripts try to use the same event) can cause odd things. For example in moodle 1.9 JSXGraph scripts had a conflict with core overlib library in IE - moodle 2 is no more using overlib.
It is easy to understand why back-end developers like Tim, Sam or Petr might want to keep YUI3 as the main core library as long as possible and it is just as easy to understand why most front-end designers might prefer jQuery. Writing new code is always slow - no matter if it is done with YUI3 or jQuery.
Personally I would like to see an option to disable YUI scripts/css with some switch - not necessarely remove YUI or replace YUI with jQuery all over moodle. One interesting thing is that all the yui script tags, body classes and css are loaded even when javascript is disabled in browser (FF).
Moodle has a clever way to add body class "jsenabled" with
<script type="text/javascript">
//<![CDATA[
document.body.className += ' jsenabled';
//]]>
</script>
so I started to wonder if moodle could have some switch to load yui tags or part of yui tags only based on some body/html class, some setting like $CFG->useyui or $CFG->usejquery etc ?
For example the editor selector code is just great and allows changing editor on the fly with code like
if (mytheme_get_editor()=='myeditor') {$CFG->texteditors = 'myeditor,textarea';} ...
and context based filters are very useful, you can change language, user/course/site themes (if allowed) and so on. If some activity or theme (mymobile etc) could use some custom tools instead of yui tools the easiest thing to start might be to disable loading yui scripts when some setting is enabled - or to not load yui scripts unless some setting is enabled (see the no-javascript-enabled-case) ...
For now the only option in moodle 2 is to add new scripts on top of core YUI and to override huge amount of YUI css. Reset & base css of YUI spoils some default behaviour of html elements and a couple of "bugs" have been "fixed" in tracker by overriding yui reset code in base theme when elements have elements inside elements but all of these fixes are only partial fixes since there is no way to continue adding rules for elements inside elements inside elements... it never ends. The only way to fix "reset bugs" permanently is to avoid changing standard html elements css and to use only classes and ids in core files to specify custom css in themes.
The navigation appears on essentially every page. The navigation has JavaScript that uses YUI. Therefore any sort of use YUI flag would be redundant, it would always be true.
I think my previous 'rule':
"Require the JavaScript from the renderer code that outputs the HTML that the JS will affect."
achieves the affect we want in a neater, and finer-grained way.
I did not want to but I can't help myself and I'm stepping into this arena As well as Mark Johnson in the parent post, I am pretty happy with YUI. Moodle UI has a lot of issues, but I do not think they are caused by any particular framework chosen.
What I really like on YUI3 in Moodle 2.x is how it integrates with the rendering machinery, how plugins can easily inject their own JS module into the page and how YUI takes care of loading all dependencies in a pretty performance-effective way. Unless someone is able to demonstrate that jQuery is able to fit this design too, there is not much to talk about imho.
Dear Frank,
Very, very interesting .
It has prevoked the thought about the old bad metric of 'lines of code' where 'useability' and 'fitness for purpose' should have been used instead. Therefore as users do not care on how much code is required to complete the task but always want it to work and work quickly, is it possible to re-run the tests but with say 'Firebug' to see how much time is expended in each implementation? As, after all Moodle is written for the users to use and not primarily for developers to learn new skills (but it helps ;) ). Speed and user experience are the metrics to hit.
Cheers,
Gareth
This is harder to do for YUI3 and jQuery though - at least if you want to make it into a hatchet job.
The reason is that the DOM/selector part of YUI3 is basically identical to jQuery (see the rosetta stone link somebody posted) whereas YUI2 was (a) quite a lot different, and (b) sh**. Coincidentally, this is also the same reason why this entire discussion is pretty much a waste of time.
(And if you're wondering why I'm posting in it - glances at CPU meter - yep, I'm still analysing useragents from a week's worth of weblogs... really ought to make my analyser app multi-threaded...)
--sam
Sam,
as a performance expert you can surely explain why jQuery 1.7 is 40 times faster than yui 3.4.1 in selector tests - http://moodle.org/mod/forum/discuss.php?d=188627&parent=825393#p825420
Check my test case in http://jsperf.com/yui3-vs-jquery/6 - edit it if there is something wrong in YUI code (some faster way to use selectors) - save the test as a new case and run the new test with a couple of browsers. If it is possible to use moodle.org test servers you could as well load the latest jQuery 1.7 file from http://jquery.com/ to a moodle.org server (the same server where yui 3.4.1 is) and change the paths in preparation code of http://jsperf.com/yui3-vs-jquery/6
<script src="http://yui.yahooapis.com/3.4.1/build/yui/yui-min.js">
</script>
<script src="http://code.jquery.com/jquery-1.7.min.js">
</script>
to moodle.org script paths.
The code that you write with YUI3 and jQuery may look almost identical but the libraries running that code are not at all identical. You can see it when you really compare the loading times of similar looking scripts with complex yui 3.4.1 and fast and simple jQuery 1.7.
And if you think that this kind of discussions are ridiculous and pretty much wast of time ... have you ever thought that yui might actually waste both our time and loading time of moodle?
I'd be very interested to see this too. A lot of the pro-JQuery arguments seem to rest on the fact that JQuery is significantly "easier" or more concise than YUI3, of which I'm yet to be convinced.
I might try writing code to convert a couple of my blocks to JQuery when I've got a spare moment, I'll post a link to my working. Who knows, I might even be converted myself!
I am not sure if it is "easier" but at least it is fun to test different alternatives - in some cases "normal" javascript can be "easier" than jQuery or YUI...
I have been testing all kinds of mixtures of code that is mostly written by others (originally) and in most cases all the scripts run peacefully. Just as an example why the option to be able to select different kind of tools can be useful you could check one of my test sites on my test server http://korpelainen.net/m2math/mod/book/view.php?id=12&chapterid=13
The theme is far from optimal code but I have used there a sort of "prototype of responsive design" so that when you scale the page sidebars should fall down and go to 100% width when screen width is less than 640px - ups - expect in old IEs but by setting sidebar width the site is somehow readable with all possible devices including mobile phones (hopefully). In some cases all designs however break and in this example page I have a JSXGraph that is set to 600px width and it does not scale. TinyMCE has similar problems in some parts of moodle - it is hard to scale it without creating a special editor skin or editor theme for small screens. To the top of this demo I placed a "Switch View" button for toggling page layout - it uses jQuery to set content width to 100% and sidebars width to 100% so that they drop down also in old IEs - with 2 fadeOut/fadeIn effects.
If you try the top right user preference box (normal javascript dialog box) it is using user preferences of moodle with yui and reloads pages with moodleurl and variable containing userpreference which is a painfully slow method to change settings but that way settings are stored to database and found from database when user returns (logins) back. Page layout switcher setting is used only on that page where the jQuery button is used so if you move to some other page original layout is used.
If you check the source about 1/10 of code is page content - the rest is page layout and javascripts... in this case a combination of YUI, jQuery, basic javascript, MathJax, AsciimathML/AsciiSVG and JSXGraph.
My test server has a minimal amount of RAM for running moodle 2.1 so the site may be slow sometimes but it serves the need for demoing things like running multiple javascripts at the same time in moodle 2.1
Ok, I've done a quick example: http://docs.moodle.org/dev/User:Mark_Johnson/Javascript
If anyone can suggest improvements to either the YUI or jQuery they're most welcome. I may have missed something which would radically sway me towards one or the other, so please feel free to add your opinions/optimisations on the discussion page.
Hi Mark,
i'm afraid i don't seem to be able to add comments on the discussion page
at sussex we are using the html datalist http://www.w3schools.com/html5/tag_datalist.asp for our autocomplete (with jquery ui autocomplete as the fallback - similar to this https://github.com/martindrapeau/Backbone-Widgets). I'm sure the fallback could be improved but, as always, we had to get it out there fast.
interested to know what you think about using this native html autocomplete functinality of the datalist as the base, then providing the fallback?
Cheers
Stuart
I agree with the priciple of doing as much as possible with static HTML(5). There are various examples in HTML5 that would allow us to replace Javascript/Flash enchancements in supported browsers with appropriate fallbacks in others.
There are a few reasons why the datalist wouldn't be appropriate for my specific example:
It occurs to me that datalist is more of an alternative to <select> than a replacement for Javascript autocomplete.
Agreed
Where we deploy this is on a fairly small set of options - a bit too overwhelming for any select list - but not too large to effect the initial rendering time.
It was also relatively trivial to use the autocomplete as a quickjump to urls - as you can probably imagine.
It wouldn't be ideal for the example case you have, but its good to know other moodlers are interested in using these things!
[OT] IE - Do you keep any stats on visitors browsers? We currently only provide IE8 or 9 on all staff & student machines, but stats show us IE is only 35% (and dropping) of visitors.
Modern browsers represent the majority (over 60%) of our desktop visitors - with the rest from the ever growing mobile visitors.
So even though we officially only support IE7-9, its nice to be able to develop for the long term (mobile), for IE10 (probably on the desktops next year?) and the current majority of our users.
Cheers
Stuart Lamour
Cool. I didn't know about the new datalist tag.
For more no-JavaScript-needed niftiness, you can also check out Eric Meyer's pure CSS menus: http://meyerweb.com/eric/css/edge/menus/demo.html
David,
it's a similar issue like selecting the best cars for us ... most people drive happily with car type A and some people want to try type B or type C for various reasons. Designers clearly tend to test good looking modern types and developers obviously like to tune the good old type as long as possible. Both aspects are acceptable
No, seriously, YUI3 and jQuery may be almost identical in many parts of code - jQuery has just been used a lot more for different kinds of variants of most common design ideas.
See for example http://flowplayer.org/tools/
and
http://flowplayer.org/tools/documentation/performance.html
and check next http://yuilibrary.com/yui/widgets/
So basic examples look pretty much the same - still there are some differences in the user experience ... found from front-end, not back-end
As a random example the future Web 2 style moodle (3?) could look for example like http://www.discoveryeducation.com/
Nothing fancy there - a little jQuery used for making the navigation effects, dialogs and design look good and surely it can be done with YUI3 as well.
Take a look, click some links, check boxes etc.
It is a perfectly well performing busy site with lots of content but no YUI.
Sorry to interrupt this discussion, but, I am trying to keep up with it. Mauno, to me you are pointing out the obvious. There was a recent discussion, well one of several dozen actually, where the UI has been ... ummm... critiqued shall we say. So, what you are suggesting here is that there really needs to be a design overhaul of the UI? Would the question then be does it matter really how the UI gets there, as long as it is in a "reasonable" time frame. So should that not be the main criteria for determining the tools used? If I am reading it right, JQuery is actually a quite small scaffold and would that not make it more desirable? Or does the inital compact nature of JQuery belie the bloatedness of repetitive loadings? Or does using YUI actually maintain a consistent speed for loading subsequent pages? ...
Yes, most UI issues can look obvious but different user groups can have different needs, consider elderly generation, many of whom can still today be logging on for the first time in adults education compared to young kids ... or different cultures...
Typically men value a website's speed, while women value its ease of use.
Speed and simplicity are important for most users so it really matters how long it takes to load all the available scripts, css files and images. For example children won't explore a Web page until it fully loads or they can expect to instantly see some kind of picture when they hit a button. According to usability studies mobile Web users over the age of 45 are more impatient than any other age group when waiting for sites to load.
Best practices for child-friendly websites include:
- Keeping the UI clean (children get distracted by visual clutter)
- Using iconography (they identify with experiences that are recognizable)
- Using vivid, exciting colors
- Avoiding integrated advertisements (kids find it harder than us to distinguish content from ad banners, which quickly lead them away)
- Consider using animation and sound (this is the only age group for which video seems ideal)
- Relate content to characters they know (like from TV)
- Provide games that educate and attract their attention
- Reinforce their actions through emotion (telling them that they did a good job encourages repetition)
and if you look some examples of popular kids sites
http://www.smashingmagazine.com/2011/07/06/best-practices-for-web-design-for-kids/
http://uxdesign.smashingmagazine.com/2011/09/02/designing-global-applications-for-children/
they use often either javascript effects, flash, java - or nowadays more and more HTML5.
On the other hand if you check best practices for designing for elderly users they include:
- Making websites highly visible and highly memorable
- Text should be large and easy to read
- Links should be easy to click
- There should be little animation or movement that might be distracting
- Website navigation should be straightforward
and javascript can be used for totally different purposes than on kids sites - for helpers, validation of input, consistant layout, zooming etc.
And finally some users may want to use "special scripts" like MathJax that are quite heavy to load alone without Yuis or jQueries and in some cases it would be optimal for performance to be able to disable all such (yui) scripts and (yui) css files that are not needed on page to load only essential content in a minimal time...
long thread. After all the interesting stuff it seems to now be just about jquery vs yui.
no one else used backbone.js yet?
no one seemed to bite when i sugested it.
Any other devs working in moodle have an opinion on it?
Maybe Moodle should take a step back from the YUI and concentrate on having a general solution to the Javascript library problem. What I'm thinking of is a way to detect when specific libraries are needed and to load only the libraries needed for a particular page.
I'm thinking of potentially a system much like the one currently used with $PAGE to load yui libraries, but which could load jQuery or YUI as required. On a page that used neither, neither library would get loaded but when one or the other (or both) are needed the necessary libraries would be added to the page.
One potential advantage is that it would allow Moodle developers to migrate from one library to another without having to a complete rewrite of all the javascript at once. And this isn't restricted to jQuery and YUI. Two years from now we could be discussing a very similar issue about migrating from YUI (or jQuery) to gObject (to invent a new library).
I think that perhaps, as suggested above, we might even want to look at having the YUI dependent code moved entirely into themes. That suggestion seems to have been dismissed as being a "developer" desire and not an end-user desire, but I think there might be merit in the idea. THe YUi code should probably be handled by the renderer, this would allow the creation of a jQuery and/or a YUI based theme that could be used as a parent by other themes which want to use one or the other.
The JS library handler would seem to me to faciliate this type of radical theming, without putting the onus entirely on the core developers to create new jQuery replacements for all the YUI functionality. Rather it would help push some of the more pernicious aspects of these presentation issues to the presentation layer, where they belong.
One major issue with loading js libraries or parts of libraries as needed is that you don't get the performance boost of caching that library.
I like the idea of enabling a mechanism in which any framework could be loaded. If no js is loaded, the site should still function as prescribed (http://docs.moodle.org/dev/JavaScript_guidelines#Moodle_should_be_usable_without_JavaScript).
Each theme, module etc. could 'register' available js, which could be centrally managed (turned off/on and matched to available framework and version). Having a good description of the available js functionality would also go a long to helping people determine whether it is useful to include or not.
Another thing to consider, a lot of people think that loading js libraries (especially jQuery) from a CDN is a good idea. I think it depends on which version you using. The trade-off of breaking out your framework into a separate call could at least be an available option.
For those who weren't in yesterday's developer meeting:
A suggestion was made that jQuery should be packaged as a local Moodle plugin. Using the new ability to allow plugins to depend on other plugins, you can write plugins that need jQuery without having to package a copy of the lib yourself, instead relying in local/jquery being in place. You can also specify a version number of jQuery that's required.
By the number of +1s in the chat, this suggestion was widely liked, and seems to suit everyone's needs rather well. jQuery support for plugin devs, and no need to overhaul all the core JS.
Some good suggestions there - still somehow that developer discussion sounds like the old HTMLArea discussions, it took years to find out why TinyMCE and (F)CKEditor are better tools than old non-supported HTMLArea and why the option to change editor is better than non-changable core editor. What happens if YUI has a similar future as HTMLArea, Netscape, Adobe SVG player, ... ?
Furthermore - what's the main benefit of "local_jquery" compared to current situation... doesn't it still mean that you need to load all yui code no matter if you load local jquery to plugins with $plugin->dependencies = array('local_jquery' => ANY_VERSION) , even when javascript is disabled
It had been bigger surprise if somebody had suggested packing necessary YUI widgets to local plugins so that you could use them if required (if some plugin requires YUI widgets).
But obviously moodle 2 trusts so much to the capability of cache that it can waste hard disc space with unnecessary files and code. One example:
All browsers have pretty similar default css - see
http://mxr.mozilla.org/mozilla/source/layout/style/html.css
http://www.iecss.com/
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/css/html.css
and most HTML elements have similar default behaviour (usually only old IEs have custom rules) :
http://css-class.com/test/css/defaults/UA-style-sheet-defaults.htm
Still in moodle we have non-optional YUI reset css https://developer.yahoo.com/yui/3/examples/cssreset/cssreset-basic_source.html that overrides browser css with some stuped rules that must be overridden / rewritten AGAIN first by
https://developer.yahoo.com/yui/3/examples/cssfonts/cssfonts-basic_source.html and yui grids css and https://developer.yahoo.com/yui/3/examples/cssbase/cssbase-basic_source.html and then base theme css and canvas theme css try to "fix" part of these self-created "css issues". And finally custom themes NEED to use all yui css - or override it once again.
Several people have discussed about advantages and disadvantages of reset codes and many people consider particularly global reset code harmful - see for example http://csscreator.com/node/34411#comment-145634
and for example HTML5 boilerplate is using no reset code, it is using https://github.com/necolas/normalize.css that
Preserves useful defaults, unlike many CSS resets.
Normalizes styles for a wide range of elements.
Corrects bugs and common browser inconsistencies.
Improves usability with subtle improvements.
Explains what code does using detailed comments.
And if different elements of moodle have proper ids and classes no html element default css needs to be changed - you can add custom styles with ids and classes.
Testing any other grid system, any other javascript library, HTML5 templates etc by overriding core code does not make much sense if all those things need to be added on top of yui things.
Ah yes, such a hindrance. Due entirely to YUI, it's been so incredibly difficult to create the complex style required by the Open University's custom theme (which looks dramatically different from normal Moodle) that I've occasionally been tempted to storm all the way to Yahoo's offices and ... WAIT JUST A MINUTE!
We've built this incredibly complicated theme (as well as lots of CSS, variant options in database to set a colour and picture for each course, etc, it also has many overrides to change standard behaviour using renderers) and we haven't ever had a problem caused by YUI. In fact we haven't even noticed that YUI had any impact on any of the theming work we did at all!
As for people saying they like YUI - I don't like it, it's faintly horrible, but so is JQuery, and switching libraries sounds about as much fun as a hole in the head. Do you want HQ to spend the next six months switching javascript library to another one that is almost identical only with a slightly different syntax, or do you want them to spend it improving Moodle?
I'd be very happy for Moodle to switch to JQuery if somebody was funding this and doing all the development to convert all core code (including all the crap that isn't even using YUI at all, or is still in YUI2) to JQuery and fully test all of the changes. (As long as it also supports YUI for legacy plugins, please, at least give us one version to change.)
Unless that happens, please let's leave the bike sheds green...
--sam
@sam - agreed we need the powerplant first.
what did you think of Nicholas Zakas of Yahoo's mvc library agnostic approach?
http://www.slideshare.net/nzakas/scalable-javascript-application-architecture
A very clear slideshare presentation!
That's exactly what
M - O - O - D - L - E
might look like!
( not YUIDLE, JQUIDLE or OUDLE )
Thanks for the link Stuart!
Great slideshow. +1
Personally, I can't wait for jQuery to at least be available in Moodle core. Reasons (in rough order of importance):
These are mostly social rather than technical factors, but I think they matter a lot. Long-term, no one is likely to care very much which library we use, but the end-user benefits that are secondary outcomes of the above will really count.
Some usful jQuery/YUI feature comparison i found on the net:
I just created a new feature tracker issue for this
http://tracker.moodle.org/browse/MDL-31162
Please vote (if you agree)
Dear Juan,
Interesting issue, I had another thought on how it could be implemented and placed that comment in the issue - even though it is now closed.
And in writing this had the thought that users could just add an inclusion line in their theme php file for jQuery thereby only including it once. This could be instructed in any third party contrib plugin if required.
And Tim (Hunt) before you drive down from Milton Keynes and bludgen me to death with a blunt keyboard 'Thomas Becket' style - I am NOT advocating rewriting all of Moodle in jQuery rather than YUI - that would be 'broken pencil' territory as Blackadder would say ;). Rather just asking for Moodle to be more 'Open' in respect to flexibility such that different vibrant plugins could be written that enhance the user's experience .
Cheers,
Gareth
If Tim is Thomas does that make Martin King Henry? (I'll get me coat)
Dear Marcus,
Sorry, I'm referring to me as 'Thomas' and Tim as 'Henry' as Tim works for the OU in I beleive Milton Keynes and I live in Canterbury .
Cheers,
Gareth
Hi, All.
It would be great if someone was willing to create and share the JQuery local plugin.
Michael d;
My two pence for what they're worth,
Having come from a more bespoke development background where I developed small web pages and user interfaces (see Awesomium) I had become familiar with JQuery and very happy with its community support, speed and flexibility.
Since starting development with Moodle 2 about a year ago I have to say that working with YUI has been, without doubt, the worst part of the experience.
It may be a lot of work to get rid of YUI, but in order to climb a mountain you have to take a first step. There needs to be a clear decision made on this (one way or the other) and some kind of strategy formulated in order to send the right message to the community.
I'm not sure we are comparing like with like. I am the world's worst Javascript developer. I find it very hard going and, as such, jQuery is appealing as even I can rattle something together that works with my Kindergarten JS.
However, YUI appears to be a different beast entirely. It is (as far as I understand) a framework of some sort for large complex development where the organisation is as important as the end result. Unfortunately, this comes with a substantial learning curve and a bit of an assumption you understand JS in some depth. I find YUI incredibly hard going.
So, I'm inclined to think that we should take steps to support both. YUI for the important core stuff that can be supported by people that know what they are doing and jQuery for those of us who just want to spice up a theme with a popular jQuery plugin. Something that would no doubt be a complete nightmare to do in YUI from a standing start.
nice article by Addy Osmani http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/
Particularly the Frameworks: When To Use What? section.
loving the fact that moodle current top theme - essential - is built with jquery on top of bootstrap while moodle hq wasted such a lot of time getting us to strip all the jquery and other nice stuff out of bootstrap base, disabling the components like http://getbootstrap.com/2.3.2/javascript.html#carousel etc that make are all making essential so popular
well done julian
