In MediaWiki, jquery.ui is broken down into multiple modules (e.g. jquery.ui.datepicker, jquery.ui.dialog, etc.) so you only need to load the parts of it you need, with a common jquery.ui.core module for shared stuff.
We should do something similar for oojs-ui that lets you load individual widgets as needed, instead of loading everything.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Split the library into four parts | oojs/ui | master | +320 -216 |
@matmarex and I discussed this on IRC, and he explained:
Any movement on this?
I was disappointed not to get any interest/replies on my wikitech thread: http://www.gossamer-threads.com/lists/wiki/wikitech/649051?page=last
It's not clear to me what the big picture is for oojs ui with respect to this and how I can contribute. This seems like a big architecture change which needs input from the core contributors to this library and I'm not even sure if they agree right now this is an approach we should take.
OOjs UI doesn't have a dedicated team (or even a dedicated person) supporting it. The changes are mostly driven by whatever the VisualEditor or Design teams need, and what they are willing to implement themselves (and to a lesser extent, Multimedia team and random people like @Anomie or @Florian).
I am pretty sure everyone agrees this is a good idea, but no one is willing/able to get their hands dirty and spend the time analysing the current state and implementing the change.
It's disturbing to me that it was decided we needed to make our own home-grown JS UI library and want to change everything to use it, but we don't have anyone actually supporting it and it's at the point where further development by "random people" is now blocked on a task like this that apparently no one is going to work on.
Just to clear the doubt, I am going to be working on this… eventually. Someone's gotta do it and I see no other volunteers. Legoktm's summary of my thoughts above is still correct on everything else ;)
I'm currently thinking of a four-way split:
The "core" defined this way would also allow us to serve styles for HTML-only views (generated by PHP code) with very little code weight overhead (the non-PHP versions have a few additional features, but it's not much CSS to support them) and no maintenance overhead.
The OO.ui.alert and OO.ui.confirm functions, used to display message dialogs, and which are defined in core.js, would be changed to lazy-load the "windows" module when they're first called. (They are asynchronous already, so this wouldn't even be a breaking change.)
(I haven't done any implementation work yet, so feel free to take over if anyone wishes.)
Would the size/contents of the oojs-ui.styles module stay the same? Or would it shrink too?
It would shrink (it would really be oojs-ui.core.styles). The styles for non-core (=non-PHP) widgets would be included in the appropriate remaining modules (no need to split them anymore, we could load the styles with JavaScript).
JavaScript:
| Source | Minified | Gzipped | |
|---|---|---|---|
| Old (whole library) | 589 K | 198 K | 40 K |
| New ("core" only) | 273 K | 93 K | 19 K |
CSS (not counting the size of embedded images):
| Source | Minified | Gzipped | |
|---|---|---|---|
| Old (whole library) | 139 K | 118 K | 12 K |
| New ("core" only) | 46 K | 40 K | 5 K |
I did some work today and submitted some cleanup patches, I'm still tweaking the big one, but that's what we're looking at. If we need it to be smaller than that, we have to look elsewhere for savings.
Change 267288 had a related patch set uploaded (by Bartosz Dziewoński):
Split the library into four parts
The plan:
Everything is backwards-compatible. Modules that don't need all of OOjs UI will soon be able to use the new, smaller dependencies :D
(MediaWiki hasn't yet been updated to use the new distribution files. Yeah, we should've had separate tasks.)
Change 267799 had a related patch set uploaded (by Bartosz Dziewoński):
[DO NOT MERGE YET] Split OOjs UI into four parts