Attending: Volker E., Joaquin O.-H., Andrew R.-G., Dan A., Adam B., Corey, Sam, Moriel, Jan, Gabriel
Action & Code 
General discussion about issues/possibilities/needs to modularize OOjs UI
to be able to use in vue/preact.
Or alternatively: Implementing own shared UI library Important performance related OOjs UI tasks from past & present;
- https://phabricator.wikimedia.org/T113677 Make OOjs UI in MediaWiki more lightweight, so that we can load it by default on every page without issue
- https://phabricator.wikimedia.org/T160690 Be able to request a custom icon pack on-the-fly without bloating RL module registry
DA: We'd need more modularization. Something in sense of d3 modularization
JF: module code would add all these exra lines of code to OOUI
DA: but there are build systems that could make that possible…
DA for the first render, esp. on mobile we'd want smallest modules possible
ES: which part of OOUI is slowing down render?
DA: ES: is it really a bottleneck, as it's already modularized?
BD: core modules, which incl basically all of PHP
CF: Load everything and measure how big the impact is…
VE: What is acceptable/inacceptable impact?
DA: We could make an ES2016 mod by analyzing dep tree
ES: but there's a cost to this, we should be clear if it's worth
AB: Am I correct, that a lot of OOUI isn't needed in normal anonymous readers views, could we cache this and load subsequently after first render?
ES: PHP infusion is one of the example applications for this
CF: Do we know what first bytes we want to load?
AD: Many reasons why I prefer modules, one of them is to not care about modules on top of my head
structured, official dependency trees
ES: not disagreeing with it. But again, is effort worth it, splitting up in 20 modules to save 20 KBs
JH: for sizes, for example, mobile sends 9.5kb of css, oojs-ui-wikimediaui.min.css is 13.6kb itself. And CSS blocks render on first paint
BD: oojs-ui-wikimediaui.min.css includes styles for dialogs, toolbars etc - probably don't need those. look at oojs-ui-core-wikimediaui
CF/GW: let's define the problem clear and get baseline numbers in tickets async
Actions: multicomponent modules. necessary compressed bytes transferred immediately versus later. first contentful paint impacts...
Review of WMDE work so far, with either Jonas or Aleksey
We don't use a build system used in our tests
DA: vue vs. jQuery UI is as fair as cars vs horses. Yeah, when the templates get big, it can become a problem
CF: any performance problems?
>> thing works good and you don't feel anything [slugging]
we don't have used OOUI, it adds some hassle to make a wrapper, but it's possible (tested with jQuery.UI widget)
JOH: react alikes don't need precompilation either if you don't want to
ES: we currently don't have @uses tag, but we could add it to code comments, and use it for dep tree
- Create / Find ticktets fro documenting requirements for projects to incorporate OOUI (analytics / Mobile Web / Wikidata)