Page MenuHomePhabricator

Split oojs-ui module into smaller ones
Closed, ResolvedPublic


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.

Related Objects

Event Timeline

Legoktm raised the priority of this task from to Needs Triage.
Legoktm updated the task description. (Show Details)
Legoktm added subscribers: matmarex, Legoktm, Aklapper.

@matmarex and I discussed this on IRC, and he explained:

  • he isn't going to work on this
  • splitting off windows and toolbars will probably get us ~50% size reduction for the main module
  • we should consider "banishing" some obscure widgets like CapsuleMultiSelectWidget or SelectFileWidget or DraggableWhatever
  • we might not want each widget to be an individual module due to startup module bloat
    • how much of an issue is that actually in practice? @ori, do we know how much we saved when GeSHi stopped registering 150+ modules?

Any movement on this?
I was disappointed not to get any interest/replies on my wikitech thread:

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.

OOjs UI doesn't have a dedicated team (or even a dedicated person) supporting it.

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:

  • "core" module, consisting of core.js file plus all the same widgets that we have implemented in PHP (essentially, ButtonWidget and all InputWidgets, plus their dependencies)
  • "widgets", containing all remaining widgets and layouts
  • "windows", including dialogs
  • "toolbars", including tools and toolgroups

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).


Old (whole library)589 K198 K40 K
New ("core" only)273 K93 K19 K

CSS (not counting the size of embedded images):

Old (whole library)139 K118 K12 K
New ("core" only)46 K40 K5 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

I know. I also filed T125292 about looking for savings elsewhere.

The plan:

  • We merge "Split the library into four parts" soon, release a new minor version of OOjs UI, and update it in MediaWiki normally as if nothing happened.
  • Afterwards, I change MediaWiki to use the new split distributions, create their RL modules, tweak the update scripts for OOjs UI we have in MediaWiki to use the new distributions, and run them to update the files, without changing the OOUI version.

Everything is backwards-compatible. Modules that don't need all of OOjs UI will soon be able to use the new, smaller dependencies :D

matmarex renamed this task from Split oojs-ui module into smaller ones for individual widgets to Split oojs-ui module into smaller ones.Feb 1 2016, 8:28 PM
matmarex added a project: MediaWiki-General.

Change 267288 merged by jenkins-bot:
Split the library into four parts

(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