We've recently used OOUI for Media Viewer and had to make an effort to
"keep it in its own corner" due to its size. At the moment it's loaded on
demand when you click on a button that opens the dialog where all our
OOUI-dependent UI elements happen to be.
I was wondering if there was any plan to make OOUI more modular. Or if
there's somehow an option like that which we entirely missed. It's already
relatively large (41kb gzipped on beta right now) and likely to keep
growing. While I imagine that VE needs all of it, if the goal is for it to
be reused across all projects, it seems to be like the cold cache
experience could be improved if it was available in different parts that
can be loaded on demand.
Is something like that in the works? If not, what's the reasoning for
keeping it all under one JS file in production?
Maybe it will become so ubiquitous in mediawiki code that at some point in
the future it will make sense to load all of it as part of every page. But
to me it seems like OOUI is at a turning point at the moment, where teams
likes ours are judging whether or not they should use it for their project.
Which creates an entirely different situation, because project X has to
live with the consequences of being likely to be the way through which
users will load OOUI for the first time, just because it has more traffic
that the existing places where OOUI is currently deployed. And you don't
want to be the project that people feel is slow to open the first time they
use it, due to a dependency that is quite large compared to the small
portion that is really being used in the context of that project.
With that in mind, OOUI modularity is an important factor, in my opinion,
in the decision we're soon going to have to make as a team regarding
UploadWizard.
Show replies by date
We are very open to breaking it out into submodules. We should be able to
do this very quickly. In many cases, users of OOUI are only in need of a
few base classes, and we've recently done much more to divide up the style
code to make it possible to load things a la carte. I believe this is
especially important for mobile due to both the size of the entire library
and also the number of widgets in the library that are yet to be styled or
optimized for mobile. I also suspect that a large chunk of that data is the
icon stylesheet, which embeds a large number of SVG or PNG icons. I don't
know what the solution for that chunk is, but I'm sure we can figure out
something clever.
We should talk when I get back from vacation on the 13th, or if you are at
the hackathon you can try your hand at getting Roan or Timo to move forward
on this.
We acknowledge that right now is an early adoption phase for using OOUI. We
really respect and appreciate those who are brave enough to begin using it
now, and are dedicated to supporting them. Thank you for giving it a try,
and please continue to be patient as we work through the challenges
together.
- Trevor