Change Details

In service of the FAWG's work to evaluate JS frameworks, we'd like to collect experiences, knowledge, useful tidbits, etc. Do you have personal experience with OOUI, Angular, Vue, React, <insert your favorite framework here (Knockout JS)>? Come share what you think the framework does well, what it doesn't, and we'll work together to communicate that in a succinct way to help our FAWG friends. * Things you like * Things you dislike * Migration experiences * Anything in between https://etherpad.wikimedia.org/p/js-framework-experience-sharing ==Outcomes== [INFO] Libraryization is important. Finding high value concepts that can stand on their own like internationalization and accessibility and separating them is important. [INFO] It's useful to stay flexible on tooling recommendations vs things we feel strongly about (true for professional and resourced engineers, but not necessarily others) otherwise we will have damage happen to gadgets. [ACTION] Talk about separating logic from View in OOUI to use in whatever the new platform. [ACTION] Explore Web Components as a common denominator across different UI component libraries. For example, if React is used initially and then is later deprecated, Web Components could persist from the old to the new solution. [ACTION] explore what the inputs and outputs of what are in OOUI widgets and what that means for separation of app logic and generic UI logic. [ACTION] explore MVVM, MVC to find a way to generalize external API dependency type things (business logic and widgets, any external thing). ==Full Notes== (disclosure: a little rough, I think following up with the attendees is probably a better way to find some of these insights. In general talking directly to someone seems to this humble humanoid to have much higher fidelity than rushed typing). Attendees: Moriel Joaquin Stephen Dan The theme we want to explore is good ideas and patterns that can inform architecture beyond "use this framework". For example, reactivity, state management, extensibility. Example libraries: OOUI, React, Preact, Vue.js, Web Components Example questions: What is this tool optimized for? What is the differentiator? Why should it be considered or not considered? Example: Preact is highly optimized for size (3kB) and React API compatible Dan: what we do here shouldn't influence framework selection except that we know that particular tools optimize certain parts of programming, and we should collect and report these to help the FAWG. Moriel: I think people forget that the framework doesn't matter but there's still some need for common components that provide things like language support, accessibility, etc. Whatever framework FAWG chooses (recommends, that is), after that we're going to have to build something teams can use on top of that, a library of components / widgets. We need a shared understanding of these things. It's the next step. Dan: Hopefully we preempt disagremeent and drama by collaborating on this aesthetic where everyone can feel heard. Let's prototype that interaction here and talk about how it can scale out. Dan: How do we start this? Moriel: I have an idea. Joaquin: paper and pens? Moriel: Split into groups? Dan: four groups of 1? Joaquin: two groups of two <laughter> Moriel: one of the things I can start with is that there's a history of OOUI that is important to note. beyond the fact that this came from a product (VE), it was meant for VE, it came with all the problems of taking a solution for a specific product and then trying to generalize. a pain point at WMF is that we're not very good at working in our stack in creating a library of things. mw-msg, for example. Dan: that'd be great, we'd want to use it when we localize wikistats Moriel: I'll connect to OOUI, one of the things that happened with mw-msg / jquery-i18n, I went to Unicode conference and they were bragging about having gender in the language and we had that for years! bringing back to OOUI, one of the reason is that OOUI was unresourced pretty much, it was kind of like we wanted ot help the entire stack so we did it but there was no resources! no contributions because everything is internal though, docs weren't so good then, Dan: I think it's pretty intuitive but there's no marketing (here's our dev hub and the 10k companies that are using it) Moriel: when we worked on OOUI, our focus was external people that may not know everything that's going on (eg. gadget developers). by default, you get a lot of features, stuff just works like Button has batteries included. but maybe we did this too much? Making a new widget is insane. but that was kind of the purpose, gadget owners don't have to worry about right to left, accessibility, etc they just use the button and get it for free. Moriel: we try to make it simpler with mixins but that adds complexity too. plugins use differents widgets and it creates a hierarchy and that's even more complex. the intention was to make it as simple as possible but it became very complex. we should think about this when we create a new library and think about where the line between abstraction/simplicity and code organization should be. we want a good experience for programmers but want to understand the tradeoffs for gadget writers. there should be a balance. Dan: as an outsider to mw, i can appreciate the complexity of trying to solve those different dimensions of problems of trying to implement a widget in a simple way that supports this functionality. Moriel: when you open librarization up to outsiders, the framework chosen is really important, especially if you choose a framework that's popular. dan: frameworks seem to be standardizing on components as the way to organize, but but there's a lot of opportunity, missing basic features like even device detection for Vue, which is super popular, is not very good. So lots of opportunity for our libraries to be used and build OSS communities. Moriel: these are things we've solved 16 years ago! but we have kept them inside our system. the price we pay now is that google is about to release globalizationin a different way and we'll need to make a decision about whether to keep our current approach or switch to the new standard Dan: <DJ entered> Moriel was catching up us on the desire to keep widgets very simple and the consequence of them becomeing very complex and difficult for developers. what are things we want to migrate and take to the next framework? we don't want to lose our work. we want to keep it Moriel: there's been a lot of discussion about the lack of separation between anything Dan: what do you think about design system as a goal? <Stephen notetaker info/action stuff> Dan: A design system is a more structured way of doing CSS and approach building your interface starting with design MorieL: in practical terms, what does that mean? if i say migrate the concept of OOUI, what do you mean? Dan: Bootstrap will have javascript or whatever randomly in its library. a design system is purely talking about asesthetic and completely separates appearance and behavior. i don't have experience with it. it's so new that people are just talking about it. Joaquin: that's part of what volker has started doing, typography, color, and expanding on that. that's one of the conversations we've been having in technology, separating ui components from the rest of the logic. however, not all of the products need to use the same library because they have very different constraints. a common base or shared base of components in whatever framework you want to use would be framework aganostic. the good thing about web components is that you can use them in whatever tool you choose, even OOUI could use web componnents, if you want to be compatible with all frameworks moriel: we've been talking about that with OOUI, and i have an experiements i can share, a lot of the things i care about is UX (User Experience) but also some of the things are programmatic. i did an experiment of separating out floatable. if you RTL, it will float this way or that. i recently released a standalone project for popups where i didn't want to use OOUI because it was too big for a simple project. i had an experiment where i did a library that react could use. something like here's web components in a library that supports all the things that browsers don't use and it's compatible with OOUI / React / whatever Joaquin: things are stabalizing. React is pretty stable for 6 or 7 years long. it's fairly stable. there are new contenders and stuff. if we bet on web components, it's the application code that needs to move around as frameworks change. this kind of future proofs ourselves Moriel: this is kind of what we did with jQuery Joaquin: HTML doesn't really change though. even web components has lots of stuff that isn't approved but the custom elements standard is the one that's approved and the thing to bet on Dan: anything that's a standard should be front and center to our attention. anything else should inform and direct our custom code DJ: quite sure there's a ticket that to look at web components because that's the thing that's coming. Dan: in a lot of ways i htink that's what ooui tried to do, make components before everyone else started talking about it, so kudos DJ: we mixed a lot of app logic into our widget and separating that out would be a good idea. have the component and the html with basic behavior but not the app logic in the widget Dan: it sounds like that at some point the FAWG is going to catalog all important stuff in OOUI? Moriel: probably not. the working group isn't going to have capacity. there's a lot of concern with how we migrate the server's rendering. we need to start with how we send the data. Dan: I think Daniel had an epiphany and wants to split out core as an API, php rendering as something that uses core in-process, and node rendering as something that calls the API. Moriel: it's going to take a long time Moriel: I did some experiments on GitHub for Flow with Stephane (not Stephen). In trying to implement one of them, Stephane did this crazy thing in React and I (Moriel), as an OOUI contributor, was ready to jump out the window in a day. OOUI is event based and is another thing we'll get to later in this conversation. Having OOUI communicate with Redux was an experimeent. Another experiment was trying to pull out business logic DJ: i think it's useful to split out the logic. if you look at redux / react, i think it's a useful model to split things out. it's so easy to Moriel: where is the line going though? in some case the widget does need to have its own logic like show and hide. we need to find the line for the separate line. DJ: this is the hard thing aobut api design. for example, php has the trait on a class and in app logic you think of a user on Dan: redux is state management though? DJ: logic is split between pre and post state handling which is baked into OOUI Moriel: if you look at more modern uses of ooui like echo and recentchanges filter. we use mvc. all widgets listen to controler. it's hopefully streamlines. that allowed us to separate business logic into the model and outside of the widetet. we tried to be very careful but it's difficult to know where to draw the line. i see a lot of product that put logic inside the widget and then they run into a lot of issues and weird events going back and forth Dan: is it fair to say that everyone likes state managers? (general agreement) Joaquin: they are changing React to include hooks but it is only one component. we have components but they. one of the things that they are doing is they are coupling state with rendering and have the notion of. they are trying to avoid the spinner nightmare where you have spinner after spinner after spinner. it's a bit complex but very very powerful moriel: some of the framworkes do it very differently but very important to separate the logic. joaquin: it's very improtant that we knowledge share things like state management. even in popups we had this problem, despite having state management, it's still a social thing moriel: we can create the apis to encourage people to do things right. we create like base stuff that set a good standard DJ: a lot of the state management stuff, we often talk about the data props but what about the output of the components like we have an input field . there's like an event model for that depsending on the framework. what is the thinking on that in terms of separation of ocncerns Dan: i am interested and excited about it. i tell you what i like but curious to hear if shared aesthetic. we have event model where sometihng happens to those input boxes and the model or whatever takes of that. events seem like you're shouting to extension, to an app, to whatever. it feels like noise among components. a reactive approach like mobx or ... you take a property like "fullscreen" and we take that property and set it to full screen. other components take hte fullscreen property and don't have to listen to events and just use the property. it saves you from having to think about how these things are changing, you just have to think about th eproperties. moriel: isn't that how redux works? dan: but you manage events yourself? moriel: no, you send parts of the data to certain components or all of them and they just look at the diff moriel: you have the browser event stuff and mousedown or whatever and an action. by definition, that's an event. what you can do though is just change the state and everything listens to those state changes. dan: in other frameworks like vue you hide the browser stuff by just binding to those values directly. there's an extension in knockout that covers binding to different elements. you can abtract above it. moriel: in ooui, it abstracts out all events but it's entirely event based joaquin: i don't htink we can come up with a general soltuion forsolving events but we can have recommendations dj: but if you need specifically to listen to multiple evetns then you can do here and here and do that dan: vue has both tho? vue has events and you cna choose to use them or be reactive. just don't be ugly moriel: it depends on the use case. one of the things that might come out of this is the principle is the abstraction. for example, in ooui whatever the input is, here is the output and something to think about when we create library. dan: that's pretty common for most of the things that support ocmponents moriel: we go back to where the complexity is. the component itself has t odo all of the logic to know how t orespond. where does the complexity lie? dj: how you organize your code and expsoe one vs another. the basic rendering part of the widget is declarative does the interactions and app logic does the more complicated and make MW API requet, for exampole. those are in separate files. moriel:yes, but if you think about bundling we need those two things dj: i think this is why we have app ooui components and generic ocmponents that are in separate library moriel: ooui started with really simple comonents... moriel: unfortunately, no place to put app logic except in widget. big example is title sleect widget or tiitlemultiselectwidget or user select moultiwidget. there are four hierarchies deep. one layer on bottom deals with the api for titles in general. sorting out the image preview and the title istself. that is going to give the title . now you have a user select. it has config variables like do i have a pciture or not. it's all in ooui widget and a big mess. on top of that we might have a further expansion hwere you need a multi select for titltes and another for users! great! it's a frickin' mess. the idea is that now if yo uhave a preference for a mute feature, you jsut add it and it comes with all the bells and whistles (this is good) but to build it was a nightmare! there was no real way to write the business logic except to write in the widget. this is an example of what happens when you don't have that separation. volker was talking about separating that in ooui. dj: if you were to have a different widget base class vs a component vs composite base class that would already help you create a separation between those things. for example, app logic. moriel: what do we consider output? if you create a multiselct tool, you want to create this great abstractiion and this is great but it's a nightmare to create it. dj: the problem is it's not delcarative. moriel: the widget needs to display things from the api. dan: the way we interface with our apis when we're getting stats and stuff, we have to coordinate five different inputs and then cal the api in wikistats. that seems tightly coupled too and there are problems there. does anyone have ap attern Dan: business logic is an interesting word. what is the line? that gets fuzzy Joaquin: i think it gets into app specific territory. those can be recommendations forcertain types of apps and we can list the tradeoffs DJ: ideally the widget has a lot fo business logic that is very specific but is very decoupled to other ui. in between you have another layer of data exchange. if you enforce that, then your data---you have a double layer of data exchange. poeople find that difficult, if you have two data communication steps then people get confused about what their data is and where it should go. moriel: i try to think practically like gadgert owner creating dialog. i don't see a way for us not to settle on a supported thing like Vue.js, for example. here's the supported component. if you wnat to craete your own thing where you load raw javascript into dom, that is fine Dan: balance between making it too easy (drag and drop) vs configurable. there's a line Joaquin: there doesn't just happen to be oneput. we can have generic layer optimized for configurability nad wikimedia devs and an optimized layer for gadget tool developers. <shares React deign guide (https://ant.design/)

In service of the FAWG's work to evaluate JS frameworks, we'd like to collect experiences, knowledge, useful tidbits, etc. Do you have personal experience with OOUI, Angular, Vue, React, <insert your favorite framework here (Knockout JS)>? Come share what you think the framework does well, what it doesn't, and we'll work together to communicate that in a succinct way to help our FAWG friends. * Things you like * Things you dislike * Migration experiences * Anything in between https://etherpad.wikimedia.org/p/js-framework-experience-sharing ==Outcomes== [INFO] Libraryization is important. Finding high value concepts that can stand on their own like internationalization and accessibility and separating them is important. [INFO] It's useful to stay flexible on tooling recommendations vs things we feel strongly about (true for professional and resourced engineers, but not necessarily others) otherwise we will have damage happen to gadgets. [ACTION] Talk about separating logic from View in OOUI to use in whatever the new platform. [ACTION] Explore Web Components as a common denominator across different UI component libraries. For example, if React is used initially and then is later deprecated, Web Components could persist from the old to the new solution. [ACTION] explore what the inputs and outputs of what are in OOUI widgets and what that means for separation of app logic and generic UI logic. [ACTION] explore MVVM, MVC to find a way to generalize external API dependency type things (business logic and widgets, any external thing). ==Full Notes== (disclosure: a little rough, I think following up with the attendees is probably a better way to find some of these insights. In general talking directly to someone seems to this humble humanoid to have much higher fidelity than rushed typing). Attendees: Moriel Joaquin Stephen Dan The theme we want to explore is good ideas and patterns that can inform architecture beyond "use this framework". For example, reactivity, state management, extensibility. Example libraries: OOUI, React, Preact, Vue.js, Web Components Example questions: What is this tool optimized for? What is the differentiator? Why should it be considered or not considered? Example: Preact is highly optimized for size (3kB) and React API compatible Dan: what we do here shouldn't influence framework selection except that we know that particular tools optimize certain parts of programming, and we should collect and report these to help the FAWG. Moriel: I think people forget that the framework doesn't matter but there's still some need for common components that provide things like language support, accessibility, etc. Whatever framework FAWG chooses (recommends, that is), after that we're going to have to build something teams can use on top of that, a library of components / widgets. We need a shared understanding of these things. It's the next step. Dan: Hopefully we preempt disagreement and drama by collaborating on this aesthetic where everyone can feel heard. Let's prototype that interaction here and talk about how it can scale out. Dan: How do we start this? Moriel: I have an idea. Joaquin: paper and pens? Moriel: Split into groups? Dan: four groups of 1? Joaquin: two groups of two <laughter> Moriel: one of the things I can start with is that there's a history of OOUI that is important to note. beyond the fact that this came from a product Visual Editor (VE), it was meant for VE, it came with all the problems of taking a solution for a specific product and then trying to generalize. a pain point at WMF is that we're not very good at working in our stack in creating a library of things. mw-msg, for example. Dan: that'd be great, we'd want to use it when we localize wikistats Moriel: I'll connect to OOUI, one of the things that happened with mw-msg / jquery-i18n, I went to Unicode conference and they were bragging about having gender in the language and we had that for years! bringing back to OOUI, one of the reason is that OOUI was unresourced pretty much, it was kind of like we wanted ot help the entire stack so we did it but there was no resources! no contributions because everything is internal though, docs weren't so good then, Dan: I think it's pretty intuitive but there's no marketing (here's our dev hub and the 10k companies that are using it) Moriel: when we worked on OOUI, our focus was external people that may not know everything that's going on (e.g. gadget developers). by default, you get a lot of features, stuff just works like Button has batteries included. but maybe we did this too much? Making a new widget is insane. but that was kind of the purpose, gadget owners don't have to worry about right to left, accessibility, etc they just use the button and get it for free. Moriel: we try to make it simpler with mixins but that adds complexity too. plugins use different widgets and it creates a hierarchy and that's even more complex. the intention was to make it as simple as possible but it became very complex. we should think about this when we create a new library and think about where the line between abstraction/simplicity and code organization should be. we want a good experience for programmers but want to understand the trade-offs for gadget writers. there should be a balance. Dan: as an outsider to MediaWiki (MW), i can appreciate the complexity of trying to solve those different dimensions of problems of trying to implement a widget in a simple way that supports this functionality. Moriel: when you open librarization up to outsiders, the framework chosen is really important, especially if you choose a framework that's popular. dan: frameworks seem to be standardizing on components as the way to organize, but but there's a lot of opportunity, missing basic features like even device detection for Vue, which is super popular, is not very good. So lots of opportunity for our libraries to be used and build Open Source Software (OSS) communities. Moriel: these are things we've solved 16 years ago! but we have kept them inside our system. the price we pay now is that google is about to release globalizationin a different way and we'll need to make a decision about whether to keep our current approach or switch to the new standard Dan: <DJ entered> Moriel was catching up us on the desire to keep widgets very simple and the consequence of them becoming very complex and difficult for developers. what are things we want to migrate and take to the next framework? we don't want to lose our work. we want to keep it Moriel: there's been a lot of discussion about the lack of separation between anything Dan: what do you think about design system as a goal? <Stephen notetaker info/action stuff> Dan: A design system is a more structured way of doing CSS and approach building your interface starting with design MorieL: in practical terms, what does that mean? if i say migrate the concept of OOUI, what do you mean? Dan: Bootstrap will have javascript or whatever randomly in its library. a design system is purely talking about aesthetic and completely separates appearance and behavior. i don't have experience with it. it's so new that people are just talking about it. Joaquin: that's part of what Volker has started doing, typography, color, and expanding on that. that's one of the conversations we've been having in technology, separating ui components from the rest of the logic. however, not all of the products need to use the same library because they have very different constraints. a common base or shared base of components in whatever framework you want to use would be framework agnostic. the good thing about web components is that you can use them in whatever tool you choose, even OOUI could use web components, if you want to be compatible with all frameworks Moriel: we've been talking about that with OOUI, and i have an experiments i can share, a lot of the things i care about is UX (User Experience) but also some of the things are programmatic. i did an experiment of separating out floatable. if you RTL, it will float this way or that. i recently released a standalone project for popups where i didn't want to use OOUI because it was too big for a simple project. i had an experiment where i did a library that react could use. something like here's web components in a library that supports all the things that browsers don't use and it's compatible with OOUI / React / whatever Joaquin: things are stabilizing. React is pretty stable for 6 or 7 years long. it's fairly stable. there are new contenders and stuff. if we bet on web components, it's the application code that needs to move around as frameworks change. this kind of future proofs ourselves Moriel: this is kind of what we did with jQuery Joaquin: HTML doesn't really change though. even web components has lots of stuff that isn't approved but the custom elements standard is the one that's approved and the thing to bet on Dan: anything that's a standard should be front and center to our attention. anything else should inform and direct our custom code DJ: quite sure there's a ticket that to look at web components because that's the thing that's coming. Dan: in a lot of ways i think that's what OOUI tried to do, make components before everyone else started talking about it, so kudos DJ: we mixed a lot of app logic into our widget and separating that out would be a good idea. have the component and the HTML with basic behavior but not the app logic in the widget Dan: it sounds like that at some point the FAWG is going to catalog all important stuff in OOUI? Moriel: probably not. the working group isn't going to have capacity. there's a lot of concern with how we migrate the server's rendering. we need to start with how we send the data. Dan: I think Daniel had an epiphany and wants to split out core as an API, PHP rendering as something that uses core in-process, and node rendering as something that calls the API. Moriel: it's going to take a long time Moriel: I did some experiments on GitHub for Flow with Stephane (not Stephen). In trying to implement one of them, Stephane did this crazy thing in React and I (Moriel), as an OOUI contributor, was ready to jump out the window in a day. OOUI is event based and is another thing we'll get to later in this conversation. Having OOUI communicate with Redux was an experimeent. Another experiment was trying to pull out business logic DJ: i think it's useful to split out the logic. if you look at redux / react, i think it's a useful model to split things out. it's so easy to Moriel: where is the line going though? in some case the widget does need to have its own logic like show and hide. we need to find the line for the separate line. DJ: this is the hard thing about API design. for example, PHP has the trait on a class and in app logic you think of a user on Dan: redux is state management though? DJ: logic is split between pre and post state handling which is baked into OOUI Moriel: if you look at more modern uses of OOUI like echo and recentchanges filter. we use Model View Controller (MVC). all widgets listen to controller. it's hopefully streamlined. that allowed us to separate business logic into the model and outside of the widget. we tried to be very careful but it's difficult to know where to draw the line. i see a lot of product that put logic inside the widget and then they run into a lot of issues and weird events going back and forth Dan: is it fair to say that everyone likes state managers? (general agreement) Joaquin: they are changing React to include hooks but it is only one component. we have components but they. one of the things that they are doing is they are coupling state with rendering and have the notion of. they are trying to avoid the spinner nightmare where you have spinner after spinner after spinner. it's a bit complex but very very powerful Moriel: some of the frameworks do it very differently but very important to separate the logic. joaquin: it's very important that we knowledge share things like state management. even in popups we had this problem, despite having state management, it's still a social thing Moriel: we can create the APIs to encourage people to do things right. we create like base stuff that set a good standard DJ: a lot of the state management stuff, we often talk about the data props but what about the output of the components like we have an input field . there's like an event model for that depending on the framework. what is the thinking on that in terms of separation of concerns Dan: i am interested and excited about it. i tell you what i like but curious to hear if shared aesthetic. we have event model where something happens to those input boxes and the model or whatever takes of that. events seem like you're shouting to extension, to an app, to whatever. it feels like noise among components. a reactive approach like mobx or ... you take a property like "fullscreen" and we take that property and set it to full screen. other components take the fullscreen property and don't have to listen to events and just use the property. it saves you from having to think about how these things are changing, you just have to think about the properties. Moriel: isn't that how redux works? dan: but you manage events yourself? Moriel: no, you send parts of the data to certain components or all of them and they just look at the diff Moriel: you have the browser event stuff and mousedown or whatever and an action. by definition, that's an event. what you can do though is just change the state and everything listens to those state changes. dan: in other frameworks like vue you hide the browser stuff by just binding to those values directly. there's an extension in knockout that covers binding to different elements. you can abstract above it. Moriel: in OOUI, it abstracts out all events but it's entirely event based joaquin: i don't think we can come up with a general solution for solving events but we can have recommendations dj: but if you need specifically to listen to multiple events then you can do here and here and do that dan: vue has both tho? vue has events and you can choose to use them or be reactive. just don't be ugly Moriel: it depends on the use case. one of the things that might come out of this is the principle is the abstraction. for example, in OOUI whatever the input is, here is the output and something to think about when we create library. dan: that's pretty common for most of the things that support components Moriel: we go back to where the complexity is. the component itself has to do all of the logic to know how to respond. where does the complexity lie? dj: how you organize your code and expose one vs another. the basic rendering part of the widget is declarative does the interactions and app logic does the more complicated and make MW API request, for example. those are in separate files. Moriel:yes, but if you think about bundling we need those two things dj: i think this is why we have app OOUI components and generic components that are in separate library Moriel: OOUI started with really simple components... Moriel: unfortunately, no place to put app logic except in widget. big example is title select widget or tiitlemultiselectwidget or user select moultiwidget. there are four hierarchies deep. one layer on bottom deals with the api for titles in general. sorting out the image preview and the title istself. that is going to give the title . now you have a user select. it has config variables like do i have a picture or not. it's all in OOUI widget and a big mess. on top of that we might have a further expansion where you need a multi select for titles and another for users! great! it's a frickin' mess. the idea is that now if you have a preference for a mute feature, you just add it and it comes with all the bells and whistles (this is good) but to build it was a nightmare! there was no real way to write the business logic except to write in the widget. this is an example of what happens when you don't have that separation. Volker was talking about separating that in OOUI. dj: if you were to have a different widget base class vs a component vs composite base class that would already help you create a separation between those things. for example, app logic. Moriel: what do we consider output? if you create a multiselect tool, you want to create this great abstraction and this is great but it's a nightmare to create it. dj: the problem is it's not declarative. Moriel: the widget needs to display things from the API. dan: the way we interface with our APIs when we're getting stats and stuff, we have to coordinate five different inputs and then call the API in wikistats. that seems tightly coupled too and there are problems there. does anyone have a pattern Dan: business logic is an interesting word. what is the line? that gets fuzzy Joaquin: i think it gets into app specific territory. those can be recommendations for certain types of apps and we can list the trade-offs DJ: ideally the widget has a lot of business logic that is very specific but is very decoupled to other User Interface (UI). in between you have another layer of data exchange. if you enforce that, then your data---you have a double layer of data exchange. people find that difficult, if you have two data communication steps then people get confused about what their data is and where it should go. Moriel: i try to think practically like gadget owner creating dialog. i don't see a way for us not to settle on a supported thing like Vue.js, for example. here's the supported component. if you want to create your own thing where you load raw JavaScript into DOM, that is fine Dan: balance between making it too easy (drag and drop) vs configurable. there's a line Joaquin: there doesn't just happen to be oneput. we can have generic layer optimized for configurability and wikimedia devs and an optimized layer for gadget tool developers. <shares React deign guide (https://ant.design/)

In service of the FAWG's work to evaluate JS frameworks, we'd like to collect experiences, knowledge, useful tidbits, etc. Do you have personal experience with OOUI, Angular, Vue, React, <insert your favorite framework here (Knockout JS)>? Come share what you think the framework does well, what it doesn't, and we'll work together to communicate that in a succinct way to help our FAWG friends. * Things you like * Things you dislike * Migration experiences * Anything in between https://etherpad.wikimedia.org/p/js-framework-experience-sharing ==Outcomes== [INFO] Libraryization is important. Finding high value concepts that can stand on their own like internationalization and accessibility and separating them is important. [INFO] It's useful to stay flexible on tooling recommendations vs things we feel strongly about (true for professional and resourced engineers, but not necessarily others) otherwise we will have damage happen to gadgets. [ACTION] Talk about separating logic from View in OOUI to use in whatever the new platform. [ACTION] Explore Web Components as a common denominator across different UI component libraries. For example, if React is used initially and then is later deprecated, Web Components could persist from the old to the new solution. [ACTION] explore what the inputs and outputs of what are in OOUI widgets and what that means for separation of app logic and generic UI logic. [ACTION] explore MVVM, MVC to find a way to generalize external API dependency type things (business logic and widgets, any external thing). ==Full Notes== (disclosure: a little rough, I think following up with the attendees is probably a better way to find some of these insights. In general talking directly to someone seems to this humble humanoid to have much higher fidelity than rushed typing). Attendees: Moriel Joaquin Stephen Dan The theme we want to explore is good ideas and patterns that can inform architecture beyond "use this framework". For example, reactivity, state management, extensibility. Example libraries: OOUI, React, Preact, Vue.js, Web Components Example questions: What is this tool optimized for? What is the differentiator? Why should it be considered or not considered? Example: Preact is highly optimized for size (3kB) and React API compatible Dan: what we do here shouldn't influence framework selection except that we know that particular tools optimize certain parts of programming, and we should collect and report these to help the FAWG. Moriel: I think people forget that the framework doesn't matter but there's still some need for common components that provide things like language support, accessibility, etc. Whatever framework FAWG chooses (recommends, that is), after that we're going to have to build something teams can use on top of that, a library of components / widgets. We need a shared understanding of these things. It's the next step. Dan: Hopefully we preempt disagremeentement and drama by collaborating on this aesthetic where everyone can feel heard. Let's prototype that interaction here and talk about how it can scale out. Dan: How do we start this? Moriel: I have an idea. Joaquin: paper and pens? Moriel: Split into groups? Dan: four groups of 1? Joaquin: two groups of two <laughter> Moriel: one of the things I can start with is that there's a history of OOUI that is important to note. beyond the fact that this came from a product Visual Editor (VE), it was meant for VE, it came with all the problems of taking a solution for a specific product and then trying to generalize. a pain point at WMF is that we're not very good at working in our stack in creating a library of things. mw-msg, for example. Dan: that'd be great, we'd want to use it when we localize wikistats Moriel: I'll connect to OOUI, one of the things that happened with mw-msg / jquery-i18n, I went to Unicode conference and they were bragging about having gender in the language and we had that for years! bringing back to OOUI, one of the reason is that OOUI was unresourced pretty much, it was kind of like we wanted ot help the entire stack so we did it but there was no resources! no contributions because everything is internal though, docs weren't so good then, Dan: I think it's pretty intuitive but there's no marketing (here's our dev hub and the 10k companies that are using it) Moriel: when we worked on OOUI, our focus was external people that may not know everything that's going on (e.g. gadget developers). by default, you get a lot of features, stuff just works like Button has batteries included. but maybe we did this too much? Making a new widget is insane. but that was kind of the purpose, gadget owners don't have to worry about right to left, accessibility, etc they just use the button and get it for free. Moriel: we try to make it simpler with mixins but that adds complexity too. plugins use differents widgets and it creates a hierarchy and that's even more complex. the intention was to make it as simple as possible but it became very complex. we should think about this when we create a new library and think about where the line between abstraction/simplicity and code organization should be. we want a good experience for programmers but want to understand the trade-offs for gadget writers. there should be a balance. Dan: as an outsider to mwMediaWiki (MW), i can appreciate the complexity of trying to solve those different dimensions of problems of trying to implement a widget in a simple way that supports this functionality. Moriel: when you open librarization up to outsiders, the framework chosen is really important, especially if you choose a framework that's popular. dan: frameworks seem to be standardizing on components as the way to organize, but but there's a lot of opportunity, missing basic features like even device detection for Vue, which is super popular, is not very good. So lots of opportunity for our libraries to be used and build OSSOpen Source Software (OSS) communities. Moriel: these are things we've solved 16 years ago! but we have kept them inside our system. the price we pay now is that google is about to release globalizationin a different way and we'll need to make a decision about whether to keep our current approach or switch to the new standard Dan: <DJ entered> Moriel was catching up us on the desire to keep widgets very simple and the consequence of them becomeing very complex and difficult for developers. what are things we want to migrate and take to the next framework? we don't want to lose our work. we want to keep it Moriel: there's been a lot of discussion about the lack of separation between anything Dan: what do you think about design system as a goal? <Stephen notetaker info/action stuff> Dan: A design system is a more structured way of doing CSS and approach building your interface starting with design MorieL: in practical terms, what does that mean? if i say migrate the concept of OOUI, what do you mean? Dan: Bootstrap will have javascript or whatever randomly in its library. a design system is purely talking about asesthetic and completely separates appearance and behavior. i don't have experience with it. it's so new that people are just talking about it. Joaquin: that's part of what vVolker has started doing, typography, color, and expanding on that. that's one of the conversations we've been having in technology, separating ui components from the rest of the logic. however, not all of the products need to use the same library because they have very different constraints. a common base or shared base of components in whatever framework you want to use would be framework aganostic. the good thing about web components is that you can use them in whatever tool you choose, even OOUI could use web componnents, if you want to be compatible with all frameworks mMoriel: we've been talking about that with OOUI, and i have an experiements i can share, a lot of the things i care about is UX (User Experience) but also some of the things are programmatic. i did an experiment of separating out floatable. if you RTL, it will float this way or that. i recently released a standalone project for popups where i didn't want to use OOUI because it was too big for a simple project. i had an experiment where i did a library that react could use. something like here's web components in a library that supports all the things that browsers don't use and it's compatible with OOUI / React / whatever Joaquin: things are stabailizing. React is pretty stable for 6 or 7 years long. it's fairly stable. there are new contenders and stuff. if we bet on web components, it's the application code that needs to move around as frameworks change. this kind of future proofs ourselves Moriel: this is kind of what we did with jQuery Joaquin: HTML doesn't really change though. even web components has lots of stuff that isn't approved but the custom elements standard is the one that's approved and the thing to bet on Dan: anything that's a standard should be front and center to our attention. anything else should inform and direct our custom code DJ: quite sure there's a ticket that to look at web components because that's the thing that's coming. Dan: in a lot of ways i htthink that's what oouiOOUI tried to do, make components before everyone else started talking about it, so kudos DJ: we mixed a lot of app logic into our widget and separating that out would be a good idea. have the component and the htmlHTML with basic behavior but not the app logic in the widget Dan: it sounds like that at some point the FAWG is going to catalog all important stuff in OOUI? Moriel: probably not. the working group isn't going to have capacity. there's a lot of concern with how we migrate the server's rendering. we need to start with how we send the data. Dan: I think Daniel had an epiphany and wants to split out core as an API, phpPHP rendering as something that uses core in-process, and node rendering as something that calls the API. Moriel: it's going to take a long time Moriel: I did some experiments on GitHub for Flow with Stephane (not Stephen). In trying to implement one of them, Stephane did this crazy thing in React and I (Moriel), as an OOUI contributor, was ready to jump out the window in a day. OOUI is event based and is another thing we'll get to later in this conversation. Having OOUI communicate with Redux was an experimeent. Another experiment was trying to pull out business logic DJ: i think it's useful to split out the logic. if you look at redux / react, i think it's a useful model to split things out. it's so easy to Moriel: where is the line going though? in some case the widget does need to have its own logic like show and hide. we need to find the line for the separate line. DJ: this is the hard thing aobut apiabout API design. for example, phpPHP has the trait on a class and in app logic you think of a user on Dan: redux is state management though? DJ: logic is split between pre and post state handling which is baked into OOUI Moriel: if you look at more modern uses of oouiOOUI like echo and recentchanges filter. we use mvcModel View Controller (MVC). all widgets listen to controller. it's hopefully streamlinesd. that allowed us to separate business logic into the model and outside of the widetetwidget. we tried to be very careful but it's difficult to know where to draw the line. i see a lot of product that put logic inside the widget and then they run into a lot of issues and weird events going back and forth Dan: is it fair to say that everyone likes state managers? (general agreement) Joaquin: they are changing React to include hooks but it is only one component. we have components but they. one of the things that they are doing is they are coupling state with rendering and have the notion of. they are trying to avoid the spinner nightmare where you have spinner after spinner after spinner. it's a bit complex but very very powerful mMoriel: some of the frameworkess do it very differently but very important to separate the logic. joaquin: it's very improortant that we knowledge share things like state management. even in popups we had this problem, despite having state management, it's still a social thing mMoriel: we can create the apisAPIs to encourage people to do things right. we create like base stuff that set a good standard DJ: a lot of the state management stuff, we often talk about the data props but what about the output of the components like we have an input field . there's like an event model for that depsending on the framework. what is the thinking on that in terms of separation of occoncerns Dan: i am interested and excited about it. i tell you what i like but curious to hear if shared aesthetic. we have event model where sometihnghing happens to those input boxes and the model or whatever takes of that. events seem like you're shouting to extension, to an app, to whatever. it feels like noise among components. a reactive approach like mobx or ... you take a property like "fullscreen" and we take that property and set it to full screen. other components take htethe fullscreen property and don't have to listen to events and just use the property. it saves you from having to think about how these things are changing, you just have to think about th ethe properties. mMoriel: isn't that how redux works? dan: but you manage events yourself? mMoriel: no, you send parts of the data to certain components or all of them and they just look at the diff mMoriel: you have the browser event stuff and mousedown or whatever and an action. by definition, that's an event. what you can do though is just change the state and everything listens to those state changes. dan: in other frameworks like vue you hide the browser stuff by just binding to those values directly. there's an extension in knockout that covers binding to different elements. you can abstract above it. mMoriel: in oouiOOUI, it abstracts out all events but it's entirely event based joaquin: i don't htinkthink we can come up with a general soltusolution for solving events but we can have recommendations dj: but if you need specifically to listen to multiple evetnsevents then you can do here and here and do that dan: vue has both tho? vue has events and you cnacan choose to use them or be reactive. just don't be ugly mMoriel: it depends on the use case. one of the things that might come out of this is the principle is the abstraction. for example, in oouiin OOUI whatever the input is, here is the output and something to think about when we create library. dan: that's pretty common for most of the things that support occomponents mMoriel: we go back to where the complexity is. the component itself has t odoto do all of the logic to know how t oto respond. where does the complexity lie? dj: how you organize your code and expsoexpose one vs another. the basic rendering part of the widget is declarative does the interactions and app logic does the more complicated and make MW API request, for exampole. those are in separate files. mMoriel:yes, but if you think about bundling we need those two things dj: i think this is why we have app oouiOOUI components and generic occomponents that are in separate library mMoriel: oouiOOUI started with really simple components... mMoriel: unfortunately, no place to put app logic except in widget. big example is title sleectselect widget or tiitlemultiselectwidget or user select moultiwidget. there are four hierarchies deep. one layer on bottom deals with the api for titles in general. sorting out the image preview and the title istself. that is going to give the title . now you have a user select. it has config variables like do i have a pcipicture or not. it's all in oouiOOUI widget and a big mess. on top of that we might have a further expansion hwerewhere you need a multi select for titltes and another for users! great! it's a frickin' mess. the idea is that now if yo uyou have a preference for a mute feature, you jsutust add it and it comes with all the bells and whistles (this is good) but to build it was a nightmare! there was no real way to write the business logic except to write in the widget. this is an example of what happens when you don't have that separation. vVolker was talking about separating that in oouiOOUI. dj: if you were to have a different widget base class vs a component vs composite base class that would already help you create a separation between those things. for example, app logic. mMoriel: what do we consider output? if you create a multiselect tool, you want to create this great abstractiionion and this is great but it's a nightmare to create it. dj: the problem is it's not delcdeclarative. mMoriel: the widget needs to display things from the apiAPI. dan: the way we interface with our apisAPIs when we're getting stats and stuff, we have to coordinate five different inputs and then calcall the apiAPI in wikistats. that seems tightly coupled too and there are problems there. does anyone have ap pattern Dan: business logic is an interesting word. what is the line? that gets fuzzy Joaquin: i think it gets into app specific territory. those can be recommendations for certain types of apps and we can list the trade-offs DJ: ideally the widget has a lot foof business logic that is very specific but is very decoupled to other uiUser Interface (UI). in between you have another layer of data exchange. if you enforce that, then your data---you have a double layer of data exchange. poeople find that difficult, if you have two data communication steps then people get confused about what their data is and where it should go. mMoriel: i try to think practically like gadgert owner creating dialog. i don't see a way for us not to settle on a supported thing like Vue.js, for example. here's the supported component. if you wnaant to craeteeate your own thing where you load raw javasJavaScript into domDOM, that is fine Dan: balance between making it too easy (drag and drop) vs configurable. there's a line Joaquin: there doesn't just happen to be oneput. we can have generic layer optimized for configurability nadand wikimedia devs and an optimized layer for gadget tool developers. <shares React deign guide (https://ant.design/)