Since it's a fairly big change I'd love to get some input from everyone so please feel free to add your thoughts.
I've written a couple of comments explaining the reasoning and approach on the tracker issue which can be found here:
Ideally I'd like to try to keep the conversation happening in Tracker (to have a single reference point for the future) however if you don't have access to tracker then please feel free to reply here also.
I read the tracker ticket and am unclear of the benefits. The ticket just mentions that it is nicer to write in, but the downsides are huge IMHO.
Adding 30kb of JS code just makes Moodle, which is already complained as slow, slower.
Also, the development hurdle of having to run grunt and not being able to view unminified files to trace js errors is just another hurdle for development. At our university we are barely getting around to write our new stuff in AMD.
Maybe the section where it mentions a possible "build pipeline" can be expanded. Is that just a dream or is that the direction we are heading towards?
I am in favor of boring but production tested development methods than chasing shiny objects... but if it is the future and leads to more dynamic and faster/better user experiences then we should go for it.
But if the gains don't out-weight the costs, then why go down this road?
Thanks for taking the time to read the tracker issue and replay, Rex. Much appreciated.
30KB sounds like a lot however on a production system that file is heavily cached on local disk and within the browser so it really only adds to the network overhead on the first request. After that it's cached in the browser so it'll no longer be sent from the server.
With regards to debugging in the browser's development tools when running the site in development mode Moodle will send source maps back to the browser along with the minified code. This allows the browser to map the minified code back to the original unminified source file which means that you will see all of the code in the browser's source tree unminified and you can still add breakpoints, step through the code, etc as you did before.
I think the experience is actually slightly improved because now the unminified source files are actually split into individual modules and group into directories in the source tree according to their component. This makes it much quicker to find the code you're looking for because you no longer have to scan one giant first.js file.
The build pipeline section was just a set of possibilities. Personally, that is the direction that I'd like to see Moodle moving towards because currently we use quite old technology which forces us to write lots of code to do simple things. This inevitably leads to bugs, slower delivery of features, etc.
I agree that if the costs outweigh the gains then it isn't worth doing however in this case I feel like there is almost no cost at all while providing a significant gain.
I hope that helps! Thanks again for getting involved in the discussion!