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
Volker

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