Change Details

NOTE: this task is a **draft** and should be considered **work in progress** until resolution or this notice is removed. The purpose of this task is identify features both present and missing in MobileFrontend’s current framework that are requirements of a replacement. This task is **not** for discussing existing problems (see T225453), although they may be referenced for context. Recognition and understanding of the issues to be resolved is a prerequisite for discussing requirements. = Draft - **Component-based and composable.** Features are divisible, written once, and efficiently usable in any combination. - **Documented.** The replacement should be accompanied by a wealth of training materials from diverse contributors. - **Thoroughly open-source.** Not only in principle but in practice too. The replacement chosen should be modern, popular, and easy to use anywhere and contribute to by everyone. Although the source code for MobileFrontend’s custom framework is technically available, it close-source in practice. It is outside of our remit to gamble on another close-source like solution given the many freely available alternatives. - **Well-defined and semantically versioned APIs.** We think packages distributed on NPM with well-versioned APIs and changelogs are very accessible to, even expected by, many developers. Picking a replacement library that follows these conventions will help ensure that upgrades are commonplace with minimal and understood risk. - **Dedicated resourcing.** The replacement should be well resourced, owned, and maintained by a large global community of experts. We've found that building frameworks is expensive, outside our focus, and we're not very good at it. We want to take the world of open-source's very best and use that instead. We think that not only will this enable us to accomplish the mission better, but we'll also have better products that are more relevant to current and future internal and external contributors. - **Competitive.** From the best, we will choose the best. Given that we have no responsibility to invent our next framework, and that changing frameworks is expensive, it makes sense that we'd want to pick the very best from the many available. We will weigh the features provided by each against each other as well as the existing MobileFrontend framework as is practical. - **Mature.** Our content may be revolutionary but we think that most of our user interfaces are solved problems many times over elsewhere. It's a frustrating experience to code features currently because it's so challenging to implement in MobileFrontend what's done with ease in other component libraries. The replacement chosen should be modern and prevalent within the industry with an established precedent for working well on many different websites. This will help minimize the number of unknowns and risks when building new features. It should be very rare that we ever encounter something that hasn't been done before. - **Multiple programming paradigms.** Good support for both object-oriented and functional programming styles will give us flexibility to choose the ideal development approach for each feature. For instance, the Popups extension takes a very functional approach to programming that we think works very well both in the end result presented to users as well as the maintenance load for developers. We'd like to have this flexibility when building UI in MobileFrontend. - **Declarative programming.** It is difficult to overstate the complication and complexity added by the missing support for this feature in MobileFrontend's existing framework. It changes the way we think and how we approach problems in ways that are unintuitive. We think that solutions that are closer to the HTML they represent are vastly easier to read, reason about, and compose. Support for declarative programming is a must. - **Peripheral libraries.** Facilities should be included or available for application state and route management, among others. The replacement needn't have these itself but it should be easily compatible with libraries that provide this functionality. - **No additional dependencies except what we need.** Although developer performance is a great concern, so is bandwidth. The solution chosen should only ship what we need and minimize implied dependencies.

NOTE: this task is a **draft** and should be considered **work in progress** until resolution or this notice is removed. The purpose of this task is identify features both present and missing in MobileFrontend’s current framework that are requirements of a replacement. This task is **not** for discussing existing problems (see T225453), although they may be referenced for context. Recognition and understanding of the issues to be resolved is a prerequisite for discussing requirements. = Draft In short, we want the best tool available. It should be easy, efficient, and even fun to write good code that works well. This will enable MobileFrontend to be successful by product, technical, social, and open-source development measures. More specifically, the following qualities have been identified as necessary: - **Component-based and composable.** Features are divisible, written once, and efficiently usable in any combination. - **Documented.** The replacement should be accompanied by a wealth of training materials from diverse contributors. - **Thoroughly open-source.** Not only in principle but in practice too. The replacement chosen should be modern, popular, and easy to use anywhere and contribute to by everyone. Although the source code for MobileFrontend’s custom framework is technically available, it close-source in practice. It is outside of our remit to gamble on another close-source like solution given the many freely available alternatives. - **Well-defined and semantically versioned APIs.** We think packages distributed on NPM with well-versioned APIs and changelogs are very accessible to, even expected by, many developers. Picking a replacement library that follows these conventions will help ensure that upgrades are commonplace with minimal and understood risk. - **Dedicated resourcing.** The replacement should be well resourced, owned, and maintained by a large global community of experts. We've found that building frameworks is expensive, outside our focus, and we're not very good at it. We want to take the world of open-source's very best and use that instead. We think that not only will this enable us to accomplish the mission better, but we'll also have better products that are more relevant to current and future internal and external contributors. - **Competitive.** From the best, we will choose the best. Given that we have no responsibility to invent our next framework, and that changing frameworks is expensive, it makes sense that we'd want to pick the very best from the many available. We will weigh the features provided by each against each other as well as the existing MobileFrontend framework as is practical. - **Mature.** Our content may be revolutionary but we think that most of our user interfaces are solved problems many times over elsewhere. It's a frustrating experience to code features currently because it's so challenging to implement in MobileFrontend what's done with ease in other component libraries. The replacement chosen should be modern and prevalent within the industry with an established precedent for working well on many different websites. This will help minimize the number of unknowns and risks when building new features. It should be very rare that we ever encounter something that hasn't been done before. - **Multiple programming paradigms.** Good support for both object-oriented and functional programming styles will give us flexibility to choose the ideal development approach for each feature. For instance, the Popups extension takes a very functional approach to programming that we think works very well both in the end result presented to users as well as the maintenance load for developers. We'd like to have this flexibility when building UI in MobileFrontend. - **Declarative programming.** It is difficult to overstate the complication and complexity added by the missing support for this feature in MobileFrontend's existing framework. It changes the way we think and how we approach problems in ways that are unintuitive. We think that solutions that are closer to the HTML they represent are vastly easier to read, reason about, and compose. Support for declarative programming is a must. - **Peripheral libraries.** Facilities should be included or available for application state and route management, among others. The replacement needn't have these itself but it should be easily compatible with libraries that provide this functionality. - **No additional dependencies except what we need.** Although developer performance is a great concern, so is bandwidth. The solution chosen should only ship what we need and minimize implied dependencies.

NOTE: this task is a **draft** and should be considered **work in progress** until resolution or this notice is removed. The purpose of this task is identify features both present and missing in MobileFrontend’s current framework that are requirements of a replacement. This task is **not** for discussing existing problems (see T225453), although they may be referenced for context. Recognition and understanding of the issues to be resolved is a prerequisite for discussing requirements. = Draft In short, we want the best tool available. It should be easy, efficient, and even fun to write good code that works well. This will enable MobileFrontend to be successful by product, technical, social, and open-source development measures. More specifically, the following qualities have been identified as necessary: - **Component-based and composable.** Features are divisible, written once, and efficiently usable in any combination. - **Documented.** The replacement should be accompanied by a wealth of training materials from diverse contributors. - **Thoroughly open-source.** Not only in principle but in practice too. The replacement chosen should be modern, popular, and easy to use anywhere and contribute to by everyone. Although the source code for MobileFrontend’s custom framework is technically available, it close-source in practice. It is outside of our remit to gamble on another close-source like solution given the many freely available alternatives. - **Well-defined and semantically versioned APIs.** We think packages distributed on NPM with well-versioned APIs and changelogs are very accessible to, even expected by, many developers. Picking a replacement library that follows these conventions will help ensure that upgrades are commonplace with minimal and understood risk. - **Dedicated resourcing.** The replacement should be well resourced, owned, and maintained by a large global community of experts. We've found that building frameworks is expensive, outside our focus, and we're not very good at it. We want to take the world of open-source's very best and use that instead. We think that not only will this enable us to accomplish the mission better, but we'll also have better products that are more relevant to current and future internal and external contributors. - **Competitive.** From the best, we will choose the best. Given that we have no responsibility to invent our next framework, and that changing frameworks is expensive, it makes sense that we'd want to pick the very best from the many available. We will weigh the features provided by each against each other as well as the existing MobileFrontend framework as is practical. - **Mature.** Our content may be revolutionary but we think that most of our user interfaces are solved problems many times over elsewhere. It's a frustrating experience to code features currently because it's so challenging to implement in MobileFrontend what's done with ease in other component libraries. The replacement chosen should be modern and prevalent within the industry with an established precedent for working well on many different websites. This will help minimize the number of unknowns and risks when building new features. It should be very rare that we ever encounter something that hasn't been done before. - **Multiple programming paradigms.** Good support for both object-oriented and functional programming styles will give us flexibility to choose the ideal development approach for each feature. For instance, the Popups extension takes a very functional approach to programming that we think works very well both in the end result presented to users as well as the maintenance load for developers. We'd like to have this flexibility when building UI in MobileFrontend. - **Declarative programming.** It is difficult to overstate the complication and complexity added by the missing support for this feature in MobileFrontend's existing framework. It changes the way we think and how we approach problems in ways that are unintuitive. We think that solutions that are closer to the HTML they represent are vastly easier to read, reason about, and compose. Support for declarative programming is a must. - **Peripheral libraries.** Facilities should be included or available for application state and route management, among others. The replacement needn't have these itself but it should be easily compatible with libraries that provide this functionality. - **No additional dependencies except what we need.** Although developer performance is a great concern, so is bandwidth. The solution chosen should only ship what we need and minimize implied dependencies.