From IRC conversation with @Mooeypoo

•mooeypoo> I think it would be good to split them up a bit. It will also make it easier to peruse AND make it easier to conditionally load (or load in the background)
14:07 <Volker_E> as I said, I don't see any reason why the library should carry widget with when it's bad UX and only used in one place
14:07 <Volker_E> mooeypoo: yeah, splitting up was also mentioned by Bartosz
14:07 <Volker_E> that seems like a “rather” easy way out, although I have to say, I like the widgets overview
14:07 <•mooeypoo> re PopupTag* I agree, but if we deprecate it, I want to make sure it's not destroying the api sandobx. I think I commented on that task asking brad for the example of how it's used so we can see how to not break it
14:08 <Volker_E> Layouts seem like a clear thing to be split out
14:08 <•mooeypoo> and re the demos, I actually think splitting would be a good solution regardless of performance. That page is huge, and I always skip the buttons and icons because I never need them -- I always go to certain specific pieces anyways, so it's a useless load for me, and I assume for many others
14:09 <Volker_E> hmm
14:09 <•mooeypoo> we can even split it up not by pages like icons and dialogs, but like... tabbed or something, and load the non-active tabs on demand
14:09 <•mooeypoo> but I really think that page is getting so big that UX wise it's smart to split, and incidentally, it'll also help performance
14:10 <Volker_E> yes, tabs do sound interesting
14:10 <Volker_E> when there are not more than 7 of em
14:10 <•mooeypoo> It would be best for everyone, imho, if we had that page with the sections and like 1 example, then a collapsed "more examples" or something that you open up to reveal the rest
14:10 <Volker_E> b/c another problem with the demos related is, that the other pages/views are kinda hidden away in the dropdown on top
14:10 <•mooeypoo> that way, you can skim through to see what you need and delve deeper if you need to
14:10 <Volker_E> mooeypoo: but for beginners it's a great showcase of what's possible
14:10 <•mooeypoo> tabs or collapsed areas, either way works, as long as when we link, it's showing the right tab / expanding
14:11 <•mooeypoo> Volker_E: but they don't necessarily need to see everything immediately
14:11 <Volker_E> currently we load everything, like the complete library
14:11 <Volker_E> unminified
14:11 <•mooeypoo> we have a lot of "this is widget x" and then a billion iterations of some of the widgets showing several options
14:11 <•mooeypoo> the options can be collapsed or in a tab or on a separate thing
14:11 <•mooeypoo> obv' we need to minify too
14:11 <Volker_E> mooeypoo: the collapsing is for me a second step
14:12 <Volker_E> as it needs a lot of thinking through what would be the right widgets to start with
14:12 <•mooeypoo> but I think UX wise we should reorganize that page, and if we do it with lazy-load, it'll help performance anyways on top of the "regular" performance things we'll do
14:12 <Volker_E> is one normal and one frameless button enough
14:12 <•mooeypoo> sure
14:12 <Volker_E> or do you show toggles
14:13 <Volker_E> so that discussion seems to imply a rat-tail of discussions
14:13 <Volker_E> providing tabs with more than just widgets, like widgets, layouts, icons, toolbars sound like a good first step
14:14 <•mooeypoo> we can talk about this, but I dont think it's that horrific to figure out. Probably one button with "you can add x y z to it, see more examples" and onwards
14:14 <•mooeypoo> it's like an index to a book/demo more than a "see everything you can do"
14:15 <Volker_E> sure, but it will get nasty soon, I promise this to myself
14:15 <•mooeypoo> Volker_E: we could also, honestly, split the demos up in terms of "showcasing what is possible" to "examples of how things can look" ... like... showcasing a couple of buttons and a couple of types of widgets that you can start from
14:15 <Volker_E> how many TagMultiselectWidgets do you show
14:15 <•mooeypoo> but then also have a page with some mock interface that uses a bunch of those widgets, to showcase what you can do / how it looks like
14:16 <•mooeypoo> Also, right now we use this page for testing as much as anything else, which is a second problem
14:17 <•mooeypoo> Volker_E: aaaand we could experiment with having the widget ONCE but allowing the user to dynamically change configs.
14:17 <•mooeypoo> Say, have a buttonWidget and things like label: [___input___] / [x] primary ...

Thanks for posting this discussion @Volker_E and @Mooeypoo 👍🏽

mooeypoo: and re the demos, I actually think splitting would be a good solution regardless of performance. That page is huge, and I always skip the buttons and icons because I never need them -- I always go to certain specific pieces anyways, so it's a useless load for me, and I assume for many others.

Me too, I mostly just search for the widget that I need.

Volker_E: mooeypoo: but for beginners it's a great showcase of what's possible

Yeah, it is a great showcase indeed. But sometimes I feel it is more repetitive and less useful. 😞

Volker_E: is one normal and one frameless button enough
Volker_E: or do you show toggles
Volker_E: how many TagMultiselectWidgets do you show

You're right @Volker_E this could lead to a lot of yak shaving. I am hoping that we can figure out a single solution though, for example: only one demo per widget plus a See more link that expands in place. This might be good for the showcase too.

Change 479968 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] demos: Don't showcase 'indicator' only buttons explicitely

https://gerrit.wikimedia.org/r/479968

Change 479968 merged by jenkins-bot:
[oojs/ui@master] demos: Don't showcase 'indicator' only buttons explicitly

https://gerrit.wikimedia.org/r/479968

Change 481239 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Update OOUI to v0.30.0

https://gerrit.wikimedia.org/r/481239

Change 481239 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.30.0

https://gerrit.wikimedia.org/r/481239

Light enough now?

Moving 'layouts' out to explicit page would reduce DOM nodes of widgets from more than ~6300 to around ~5100.
Sounds like a useful next step. Edit: That's T178950

In T210039#4879725, @Volker_E wrote:

Moving 'layouts' out to explicit page would reduce DOM nodes of widgets from more than ~6300 to around ~5100.
Sounds like a useful next step.

If you want to split the "Widgets" demo, another useful way would be to split the "core" widgets and layouts (those that only require oojs-ui-core.js – or equivalently, those that we also have available in the PHP version) from all other ones (that require oojs-ui-widgets.js).

Although I think that you'd get the most performance improvement by generating the demo page through some kind of a minifier (Webpack?). Loading each .js and .css and .svg file individually is convenient for local testing and hacking, but just terrible for performance.

I have a radical suggestion here... since the demos were written in what the IT universe defines as "generations ago", I think that instead of thinking about how to fix performance for what's built, we should reassess whether the demos -- in general -- need to be rewritten.

I know that there is some magic done here with embedding code, using templates, etc, but a lot of the cheats we made to load things were making assumptions that were true to 4 years ago, and may not be true anymore.

If we're alreayd thinking about this, let's challenge the status quo. Can we rewrite the demo page completely, at least the initialization fo it? There are some lazy-loaded CSS that have nothing to do with templates that maybe shouldn't be lazy loaded, and there's some DOM we create in JS that we can output directly in the HTML so it doesn't jump.

@matmarex thoughts? can we rethink some of this?