I tweeted a quora answer from Ryan Grove on this topic a few weeks ago which I think gives good advice in what the direction should be:

I recommend using ES6 or CommonJS modules and seeking out small, focused libraries that do the things you don't want to do yourself. Embrace ECMAScript 5 features (which all modern browsers support), and consider using polyfills or transpilers that allow you to use ECMAScript 6 features.

Like Ryan alludes to in his answer and Yahoo say in their announcement the usefulness of the big JS libraries like YUI is reducing as the language gets better - so I don't think our direction should be to look at something like jquery (argh, i said the J word! ).

In Tims response to my tweet the question comes up.. Do we do anything until ECMAScript6 modules are better supported?

I think we should - it will be a long road and we should start thinking about it now - I'm sure we could change our approach to new development to reducing our use of the monolithic YUI components and instead focus on use of the necessary needs (YUI as the polyfill..)

I'd like to see Moodle focus on a mix of plain JS and jQuery. Of course it's always possible that YUI development is taken over by a third party and revived into a vibrant community, but I don't know how likely that is. 

The current state of things right now - Moodle is one of the last users of YUI, YUI devs (outside of Moodle) are rare, the framework in now unmaintained, and new devs aren't interested in learning something no one else uses.

In any case, I'd hate to see Moodle stick with YUI in the long term (i.e. Freeze at the current version, start maintaining a YUI fork, etc) due to the existing investment that has been made. 

EDIT: I think I should clarify "A mix of plain JS and jQuery" - I think plain JS for core, critical parts of Moodle, and jQuery for less critical parts of core and as the officially supported framework available for plugins.

I also feel angularJS would be a suitable replacement and agree with David Bezemer that building from scratch is not the correct solution, resources could/would be much better distributed in other area of moodle. 

Oh no...

That was the first thing that popped in my head as I read it. Then I read the whole discussion and decided to add my two cents.

First of all, since Moodle 2.7 is here to stay for a few years there's no need for frantic coding because the YUI will still be there.

And as for the talk between pure JS vs. JS library I think the answer is pretty obvious. Looking at the PHP code in Moddle reveals various levels of coding and styles that are unavoidable due to the large amount of contributors, and in my experience many back-end developers aren't quite as "fluent" when it comes to front-end developing and the result would be a multitude of script code that will most likely cause unexpected errors.

So in short, a JS library is a MUST. The best thing you get from using a library is a standard. A library already handles some of the backward capabilities and also cross browser issues (does everybody knows Mozilla uses a different mouse wheel event? with a library no one will find out the hard way). A good library also has good components/plugins to use all across the site, otherwise we'll end up using one calendar plugin in one place and a completely different calendar in the next page.

Now, about YUI, coming from JQuery I admit not being a big fan. This showed me the difference between a code written for other developers and a code written for web designers in mind, but still I'm not calling to run straight to JQuery.

As for creating a new library or like in YUI adapting an existing library for Moodle please consider this!

Personally, while I understand the benefits of using a modified version, it does "lock" us from fully using components. For example, the date picker component is strongly attached to a Moodle form and makes it hard to use in other places.

Using an existing library with minimal adaptations will allow us to update it more frequently and allow the full use of third party components written for the library (there was a good example in Moodle 1.9 where the dragging of elements stopped working in IE9 because YUI 2 didn't support the browser's new version and Moodle 1.9 didn't support YUI 3, so all IE browsers were forced to work in IE8 mode).

So here is my wishlist 

• A JS library with more extensive UI support
• Minimal modifications that won't create a separate version from the rest of the world
• Enabiling a modular framework that will allow calling any needed component without special requirements

My vote at this stage would be to tend towards not using a "big" framework like Jquery but looking for "..small, focused libraries.."* that meet our needs.

Frameworks are great - being able to leverage someone else's hard work related to browser compatibility etc but they can introduce a lot of bloat/overhead and browsers have got a lot better at this stuff. If we could implement something that was light/flexible and high performing it would get my vote.

Looking further at Ecmascript seems to make sense - despite the fact that we all struggle with particular browsers they do a much better job of providing similar/consistent support when it comes to JavaScript when compared with css.

But - we should continue to support those users that want to use various elements of JQuery as we do try to make the barrier to new developers low and they all seem to have some level of jquery experience these days.

* quote from Ryan Grove 

Hi All,

Typically this announcement comes when I'm away and having some Internet away-time, so sorry that I'm late to the party.

Firstly, thank you to Dan for starting this conversation. It's good to start it early and to consider the best approach.

Secondly, and more importantly, I think that the important thing to remember is not to panic. YUI is not going away. The source is still open. It is still being worked on by Yahoo! and they will still accept third-party contributions. The only change here is that new development is being reduced and/or entirely removed. Releases will still be made, but no longer on the previous release cycle.

So to start putting my two cents into the mix, here are some points to consider:

• YUI is not going away;
• AlloyUI is a maintained fork of YUI which has until now closely followed YUI -  we can switch tracks to AlloyUI to buy more security support time if required;
• we do not need to rush into any change for 2.8, or even potentially 2.9;
• ECMAScript 6 is nearing (June 2015) and many frameworks are changing the way in which they work, as others have alluded to; and
• the question at this stage should not be "jQuery or Angular or otherPopularFrameworkToday", but "what are our key requirements for now, and in the foreseeable future".

To that end, I think it's worth considering some of the reasons why YUI has been good for the Moodle project, look at what hasn't been so good, and work out what is now important to us. Clearly, something that is familiar, has good standards, is easy to use, etc. is high up there; but what are the requirements beyond that?

For me, one of the biggest features of YUI in comparison to most of the other frameworks of a similar era (and I think it's worth bearing that in mind because the JavaScript landscape is constantly evolving) is its modularity. It has an extremely intelligent loader, and container system which modules are loaded into. This may seem an unusual thing to focus on, but Moodle is also modular and we need to try and ensure that one plugin or part of Moodle does not affect every other.

I think it's also worth pointing out that if we do go down the ES6 module route (and I'm not saying that we necessarily should), the changes we initially need to make may be minimal as YUI3 already supports loading of ES6 modules and has does since YUI 3.15.0. Since we already use YUI 3.15.0 in Moodle 2.7, changes to the loader and wrapper system could feasibly be back-ported, thereby improving backwards compatibility of plugins.

So in summary:

• we need to consider our needs first;
• we should not just pick the most popular framework today - we've all seen frameworks come and go;
  
• we do not have to change today, or even tomorrow... just soon; and
• it's highly unlikely that we will be rewriting in a big-bang approach - YUI2 and YUI3 will be supported for some time yet.

I've started a discussion on the Moodle Developer Documentation to act as a breeding ground for some of the requirements that we foresee.

Cheers,

Andrew

Just when I was thinking of migrating our JavaScript to YUI...

My personal preference is to go more towards jQuery, considering it is currently included in core (although is not always available) and it widely used across the web. There is also quite a large number of plugins available. If lazy loading is required requirejs should also be considered.

I am definitely against creating moodle's own as (previously mentioned) there are a large number of browser inconsistencies (including one that I have just fixed in tinyMCE recently). Using the likes of jQuery means that, not only will we have Moodle developers (myself included) keeping an eye out for these issues, we will have a much wider community looking at it as well.

just my 2 cents.

Brian Barnes

Sad news on yui, but...

This is great opportunity - alongside the current work on a pattern/elements/ui library - to identify moodle's core requirements from js and build a better moodle long term.

For most user in their primary workflow through moodle its difficult to find use cases for a js lib (which makes sense given moodle's previous/long term it must work without js policy). 

Currently the primary flow for most users we find is : 

login - find course - view/engage in resource/activity in course

and it is quite nice when the primary workflow in a system just works without relying on a js lib.

Once you get into the admin/content creation and engagement side the use cases for js get a bit more obvious - lots of interaction with forms where we know the user experience can be enhanced with js.

In picking a js lib to use in any project i find it useful to first identify those core use cases and requirement for the js - where it would have the greatest benefit to the most users. For moodle the first place would seem to be forms. 

Moodle's core and mods are more often than not just a bunch of forms - forums, quiz, content creation etc. 

If no one is planning any radical webapp style restructure of moodle it might be good to look at improving this stuff moodle is made of - forms.

Updating the forms lib - selecting a js lib designed to provided the best user experience for forms, forms currently in moodle and those we haven't yet conceived that a good js lib may inspire

(footnote - this doesn't scream jquery to me)

Agreed that use/cases and requirements gathering is a must, but I wanted to plop this down before I forget to mention it.

Since the Moodle UI Elements Library is kicking off and there is a need for a JS library replacement, then this is a great time to work towards a new front end that can support a re-usable element library.  Google is pushing towards web components which are re-usable widgets that can be used just like regular old HTML elements that take custom attributes and can emit events.  The foundation of this is polymer (http://www.polymer-project.org).  Other projects in Google also have web components like Dart.  AngularJS has its own version, directives, but it looks like AngularJS 2.0 is going to be compatible with web components.

Basically you can make a web component can look like <mdl-core_reveal animation="rainbows">Content to reveal.</mdl-core_reveal>.  The web component is configured by its attributes and we could listen to events by doing something like revealElement.on('reveal', ...).  So why is this neat?

• The implementation is hidden.  We don't care what the developer did under the hood to make this component.  Nor do we care if the developer refactors the innards, just as long as the same attributes/events are maintained.  Basically we are decoupled from the implementation.
  
• They are re-usable just like any other HTML.  Web components can be used by other web components too because they are just HTML.
  
• Easy to document.  What does it do?  What are the attributes and their values?  What are the events?
  
• They are self contained black boxes.  One web component will not conflict with another.  This also loosely couples the components because they communicate via attributes and events, just like regular old HTML.
  
• Easy to use.  Do you know HTML?  Great, you know how to use a web component.
  
• Many more reasons, just start researching it, they are really interesting.
  

To see what goes into creating a web component, checkout the polymer docs.  This page gives you a good idea of how they are built: http://www.polymer-project.org/docs/start/creatingelements.html

In the end, the idea here is instead of picking a JS framework or library, we are picking web components and we don't care what tech is used inside of them.

TL;DR

1. Plan ahead, long term
2. Evolve | change (with an emphasis on evolve)
3. Use frameworks (front and back)

I'm also not a core member but am a Web developer. Here are my general thoughts about Moodle, from an "outsiders" perspective looking in. And the YUI discontinuation has started some good discussion.

1. Moodle needs to evolve. Even though there have been recent improvements both visually and with the core framework, Moodle still "feels" old. It needs a drastic change to make it look & feel "new" and moving to an SPA would help make this change in my opinion. Other creative ways to access and use Moodle are also needed.

2. Standards and conventions. When developing something in Moodle, it always feels dirty and hackish. The core PHP framework feels like it was hacked together rather than starting from good conventions. Yes, improvements have been made but there is still a lot left. This point leads to the next..

3. Recycle, reduce, reuse. I've always wondered why Moodle hasn't moved to a solid PHP framework. Why re-invent the wheel when you can start from a framework and quickly build-up from there? Same applies to a JavaScript framework. Don't spend time deciding and setting up / programming the mundane things. Pick good frameworks and build-up from there.

jQuery vs ** The JavaScript framework depends on the type of app being created. If Moodle decides to stick with server side rendering, jQuery will probably make more sense for DOM/visual manipulation. If Moodle goes towards an SPA (which is a bigger change), Angular or Ember makes more sense.

Plan Ahead I highly agree with Andrew's "define the needs first" approach. Everyone likes to jump on their soapbox right away (yes, me included) instead of really thinking it through. There is certainly some forethought needed on planning the end-game. It's probably time to sit down and really think about where Moodle should go in the long term.

Moodle 3.0 Here is what I'd like to see Moodle evolve into for 3.0, here come my framework opinions. It's important to keep the server stuff on PHP as that's what the greater community is comfortable with for installations. Therefore, REST and RPC API's should be build using the Zend Framework (or maybe something more API specific). A full SPA should use Ember.js as it imposes convention (which Moodle desperately needs). Building an SPA will also bring the core developers that much closer to building Apps, as you can use Cordova and such to bundle SPA's into Apps. The one unknown is the CSS framework, I'm a fan of both Bootstrap and Foundation and both have big changes coming (Bootstrap 4.0 and Foundation for Apps).

That's all for now. Take it for what it's worth.

Another random though in this area:

An intentional design decision in YUI was that YUI code did not look like plain JavaScript. This was intentional because it was part of ensuring that YUI code could not possibly interfere with other JavaScript.

So, instead of saying

document.querySelector('#myhiddeninput').value;

you would say

Y.one('#myhiddeninput').get('value');

While the keeping YUI from conflicting with anything else was a good thing, it does mean that there will be a lot of fairly mindless code rewriting involved in moving to something else, if we do. Still it should mostly not be too hard. Just time-consuming.

Another random though:

On the growing requirements page https://docs.moodle.org/dev/Talk:Javascript/Requirements, we have

Damyon has already questioned that. The point I wanted to make is that we are not consistent in this respect.

For CSS we combine all the CSS from everywhere into a single file, which means that the CSS is the same everywhere, and browsers can store it in their cache.

For JS, we load separate bits depending on what the page needs.

Does this inconsistency matter? Should be be consistent?

I don't know, but I wanted to raise the question.

When I first read the YUI announcement to stop active YUI development I thought this is a tough but wise decision. My second thought was - what will happen to »Atto«?

Reasons to stop YUI development are the much changed JavaScript support in browsers and a much improved JavaScript tool landscape.

I find reading the forum postings interesting under two aspects. One is that many of the contributors against a switch to jQuery in earlier discussions are now proposing to use jQuery with the same enthusiasm. And second is that many contributors in this discussion propose to use their momentary favorite JavaScript framework.

Not only the YUI developers see the signs of the time, many articles written lately propose to use pure JavaScript over frameworks. I find it interesting that in several articles the topic is »not to use jQuery« For example http://alistapart.com/blog/post/choosing-vanilla-javascript (And within the article the link to the »You Might Not Need jQuery

http://youmightnotneedjquery.com/« resource.)

I have the impression that if Moodle may decide to go with jQuery or another framework they are running behind in time several years - at a time when the web community seriously starts to move away from big JavaScript frameworks like YUI and jQuery Moodle may decide to switch from one to another

The actual situation may be a big chance for Moodle to start over and eventually try the vanilla JavaScript approach. There is no need to hurry. What about taking »Atto« and refactor it with pure JavaScript. Check with all relevant browsers and find out where the problems are. If that pilot project may go well the other areas in Moodle should be ok to handle the same way.

I learn more and more that a crucial factor for a programming language/tool adoption is how easy it is to start being productive with the language/tool. I see two key factors »documentation« and »real world examples« which can be taken and modified for the own projects. If Moodle would decide to take the »no framework« road with JavaScript it would be of great benefit if a certain amount of effort is put in writing good and easy to understand documentation and collecting and carefully commenting many »real world examples«. I guess development time and documenting time may be 1:1. With such a good documentation and »real world examples« it should be »easy« to start being productive writing Moodle JavaScript. The Moodle element library may be a marvelous place.

What others are working on lately »Improving Smashing Magazine's Performance: A Case Study« http://www.smashingmagazine.com/2014/09/08/improving-smashing-magazine-performance-case-study/

Analyzing the discussion contributions and taking Martin Dougiamas' contribution here and in the related tracker task and Moodle HQ member contributions I guess it is not recommended to use YUI. I guess the best would be to implement the functionality in pure JavaScript and if there might be issues with browser compatibility or functionality not offered by HTML5/Javascript to use jQuery.

What do you propose?

PS:

Pure JavaScript encapsulated in an anonymous function to avoid conflicts with other scripts in the page will be independent of any future library/framework decisions so it might be the best solution.

Just read John Resig's tweet, may be interesting for the opinion building.

@jeresig: All the talks from last week's jQuery Conference (@jqcon) are all online! Dig in and enjoy!

JS Parse and Execution Time

An interesting article and worth reading.

In the last paragraph Tim Kadlec writes:

"When you consider the combination of weight, parse time and execution time, it becomes pretty clear that optimizing your JS and reducing your site's reliance on it is one of the most impactful optimizations you can make."

http://timkadlec.com/2014/09/js-parse-and-execution-time/

I say we should take a pragmatic approach here; when faced with a choice between competing technologies, the best choice is often not about technical excellence, but about practicalities - e.g. how available are skills to work with A, B, or C?

In this case, I'd pick jQuery, simply because there are a lot of experienced jQuery developers out there, and more experience generally means fewer bugs.

FWIW, I think I can speak for most of the NetSpot crew in saying we would much prefer jquery as the direction forward.

If Moodle ends up without a framework, or builds it's own (the former leads to the latter, inevitably) then we have a higher barrier to entry for new developers, almost certainly already experienced in jquery.

There is also an established culture around this lib already, so there are many examples (yes, some not so good) to follow, and plenty of documentation, books, etc.

Building on that, I think also the other effect will be to encourage proper style and technique; if Moodle does its own thing this is less likely to be consistently enforced. While core might not be a major problem (codestyle check fixes this), it is not as certain for 3rd party code, and we really want to see the best practices there too - if only so that more 3rd party plugins etc are of a high quality, suitable to consider for integration to core and so on...

All of that is invariant whether or not a lib is really strictly necessary from a technical or code size POV.

Have decisions been made which way to go? 

For my Moodle JavaScript work I decided not to use YUI any more and to go with jQuery in new projects. May this decision correlate with the future Moodle development line?

Thanks for your answers.