Front-end standards group/2017-06-28


Attending: Volker E., Joaquin O.-H., Andrew R.-G., Dan A., Adam B., Corey, Sam, Moriel, Jan, Gabriel

 Action & Code [edit]

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;

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