Front-end standards group/2017-06-28

GWENDOLIEN         Brunr         Naderlands        Zoeken      Toevoegen           LIP  BALM            ?123      ABC

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 Aleksey: http://github.com/wmde/php-vuejs-templating 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

Follow-up

 * Create / Find ticktets fro documenting requirements for projects to incorporate OOUI (analytics / Mobile Web / Wikidata)