Page MenuHomePhabricator

RFC: Adopt a modern JavaScript framework for use with MediaWiki
Open, Needs TriagePublic

Tokens
"Party Time" token, awarded by Mvolz."Mountain of Wealth" token, awarded by WMDE-leszek."Party Time" token, awarded by Osnard."Party Time" token, awarded by Addshore."Love" token, awarded by Jakob_WMDE."Like" token, awarded by Demian."Love" token, awarded by gabriel-wmde."Barnstar" token, awarded by awight."Yellow Medal" token, awarded by alexhollender."Love" token, awarded by abi_."Love" token, awarded by Jan_Dittrich."Love" token, awarded by MSantos."Like" token, awarded by nray."Love" token, awarded by AnneT."Like" token, awarded by Masumrezarock100."Love" token, awarded by kchapman."Love" token, awarded by Ladsgroup."Love" token, awarded by Tonina_Zhelyazkova_WMDE."Party Time" token, awarded by Niedzielski.
Assigned To
None
Authored By
egardner, Dec 19 2019

Description

Proposal

As part of the Wikimedia Foundation’s platform evolution program, the Technology and Product departments have assembled a cross-departmental Frontend Architecture Working Group (FAWG). This group (which met extensively between September and December 2019) was tasked with carrying out the WMF’s platform evolution recommendations – in particular, with exploring how to modernize the tools used for front-end development at the Foundation.

As part of its work, the FAWG recommends that the Foundation should adopt a modern, widely-used JavaScript framework for the purpose of developing user interfaces within its projects. After much research and discussion, the working group believes that the open-source Vue.js framework is the best match for the Foundation’s requirements right now as well as for the foreseeable future.

The new framework would initially be introduced in one or two small features which would serve as case studies. Wider adoption could proceed if initial experiments succeed.

The working group anticipates that some deeper changes to architecture and infrastructure will be needed in order to take full advantage of what a modern JS framework like Vue.js can offer. In the longer term, adding support for a frontend build step in deployment and for server-side rendering (SSR) of UI components are two tasks that would be particularly useful here. In the short term, there may be a need for making small additive changes to tools like ResourceLoader to better support using Vue.

Until such features are in place, use of Vue.js would be limited to cases where server-rendered elements can be progressively enhanced within the user’s browser. Considerations of accessibility, internationalization, and performance will remain paramount. This RFC is about adopting a specific tool for use in building UI components within our present architecture. The FAWG has also produced a set of recommendations that touch on larger architectural changes in the Foundation’s projects, but they are beyond the scope of this RFC.

Even with these limitations, the FAWG believes that adopting a modern, widely-used library like Vue.js will provide many benefits by improving developer productivity, aligning our work with the best-practices for UI development used by the wider web, and lowering barriers to contribution.

Problem Statement

Platform Evolution is one of the five pillars of the Wikimedia Foundation's Medium Term Plan. The need to evolve our platform is very evident when it comes to how we design, develop, and deliver experiences to users in the browser.

WMF projects still rely on the same approach to front-end development that they did a decade ago: most user interface elements are built in PHP (often without relying on templating languages), and enhanced in the browser using jQuery and our own in-house frameworks (OOJS and MobileFrontend) and UI component library (OOUI). There are many pain points associated with this way of working in 2019.

Thoughtfully adopting a modern JS framework will provide many immediate improvements to the front-end development process at the Foundation, and will help to pave the way for further architectural improvements in the future. Some advantages of using a modern JS framework include:

  • The ability to build UIs in a declarative way (describing what to build), as opposed to the present imperative approach (describing how to build it), leading to more concise code that is easier to reason about
  • Better support for breaking up UI code into small, manageable components with clear separation of concerns
  • Components built with a modern framework would be reactive (automatically responding to user input) out of the box, with no need for manual DOM reconciliation. This can potentially eliminate an entire class of bugs
  • State management systems (Redux/Vuex/etc) would be available to help make complex data flows consistent and predictable
  • Unit-testing of UI elements would be greatly simplified, leading to better test coverage and fewer bugs in our UIs
  • The ability to do server-side or isomorphic rendering of UI elements opens up many new architectural possibilities that could be explored in the future
  • Aligning front-end development within the Foundation to current best-practices in the larger web will simplify onboarding of new developers (a process that is currently quite painful and time-consuming, since many things need to be re-learned here) and lower the barriers to contribution generally
  • Relying on tools that have large, active communities outside the Foundation will let us benefit from the larger community’s work (fixing bugs, writing documentation, maintaining the framework); this will also make it easier for innovations developed within the Foundation to be adopted across the wider web.

Requirements

The FAWG has collectively gathered an extensive list of requirements for whatever new technology we end up adopting. These can be summarized as follows:

  • The framework allows UI elements to be defined in a declarative way
  • UI elements created within the framework are reactive (update automatically in response to changes in data or user input) by default
  • The framework is open-source, widely used, and has a thriving community (and we anticipate this will continue to be the case for years to come)
  • Flexibility: the framework supports the widest-possible range of use-cases (client-side as well as server-side rendering, progressive enhancement as well as full "SPA" usage, build step as well as no build-step etc.)
  • The framework is heavily optimized for performance.

Libraries Considered

The FAWG evaluated a number of different libraries in the front-end framework landscape. We believe that the only libraries which currently satisfy all of the requirements above are React and Vue.js.

Angular and Ember have active communities and powerful features, but lack the flexibility that will be required for our particular use-cases (especially early on in any "transitional" period of adoption when tools like jQuery, OOJS, and OOUI remain in use).

Svelte, Inferno, and Preact are aggressively optimized for performance but have much smaller communities of users (Preact suffers from this issue to a lesser extent, but only as long as it maintains a very high level of compatibility with mainstream React, which may not be the case forever). Stimulus.js embraces the philosophy of progressive enhancement but doesn't support other use-cases like server-side rendering.

React and Vue.js share many features and philosophies. Both enable developers to build UIs in a declarative, reactive, and component-based way; both core libraries are fairly light-weight and performant; both possess large and active communities. We believe that the Foundation would be well-served by adopting either tool. However, we believe that Vue.js has a few key advantages that are relevant for the Foundation's use-cases.

Why Vue.js

It is true that React has a larger community by at least an order of magnitude; if the requirement of widespread adoption outweighs the others listed above, then React is the clear winner.

However, we believe that Vue.js has sufficiently wide adoption in the form of a thriving and fast-growing community to be a safe bet. In addition, we feel that Vue.js has some advantages in terms of flexibility that distinguish it from React for our anticipated use-cases within WMF projects:

  1. Better support for usage without Webpack/Babel/front-end build tools: Both React and Vue.js rely on a build step for their ideal use cases. React uses JSX files, while Vue.js uses single-file components. But Vue.js can also use templates provided as HTML strings (which can be provided in a variety of ways). This allows us still define UI elements in a declarative way, one of our key requirements. React can also be used without a build tool, but it falls back on its imperative CreateElement API which is not ideal for general use. We should still explore introducing a full build step in the future (including full support for module bundling, ES6+ transpilation via Babel, etc), but this is a non-trivial change to the architecture of MediaWiki. In the meantime, Vue.js’s string templates could probably be handled by ResourceLoader with some small modifications. Finally, the ability to define components in a declarative way without requiring a build step may be especially useful in the development of gadgets and other user-generated scripts, one feature that makes Wikipedia and related projects very different from many other major websites
  2. Vue.js may enable us to rely on fewer libraries as dependencies. If we are only allowed to use a small number of whitelisted tools (due to security audits, for example), Vue.js allows us to do more with fewer dependencies in some cases. For example, the core Vue.js library includes powerful transition and animation tools; React has similar tools but they exist within community-maintained libraries separate from the main codebase. Similarly, both React and Vue.js can support scoping CSS styles to a single component, but React users must use a 3rd-party library like Styled Components, while Vue.js includes this feature in the core library. Finally, key add-ons in the Vue.js ecosystem (router, state management, testing tools, etc.) tend to be maintained as officially-supported products by the core development team, while the equivalent tools in the React ecosystem tend to be community-driven, and support levels will vary.
  3. The official Vue libraries are evolving in a stable and predictable fashion. In the last 4-5 years, Vue.js has moved from 0.x to 1.x to 2.x (the current version), and is about to enter version 3. There have been very few breaking changes that required rewrites of existing code; new versions tend to introduce new optional features while preserving the core workflows. In contrast, React and its related tools have gone through a large amount of change over the same period of time. The recommended best-practices have changed considerably over the years. Keeping up with these changes would be quite difficult given the pace that WMF projects move at.
  4. Vue.js development is not led by a single corporation whose goals may diverge from those of the WMF. React was originally licensed in a way that made many open-source projects hesitant to use it; fortunately those days are gone. However, React is still developed primarily by Facebook and will likely continue to change in ways that serve Facebook's needs first and foremost. The WMF had to spend time and energy migrating away from another open-source FB project (HHVM) when Facebook decided that new versions would no longer remain fully compatible with PHP. Sudden changes in direction may be less likely in a project like Vue.js which does not rely on a single dominant corporate backer.

It should be noted that these points are not “reasons why Vue.js is better than React” – they are arguments that Vue.js is the best choice for the WMF, where “best” must balance between current realities, migration paths, and ideal future outcomes.

Next Steps

Fully adopting a tool like Vue.js would represent a significant change in the way the Foundation approaches front-end development. This is a decision that has many implications and potential pitfalls.

To minimize the risks inherent in such a change, the FAWG recommends that the initial adoption of Vue.js be limited to one or two case-study projects that fall within the upcoming Desktop Refresh project. These should be small-scale, discrete features which would rely on client-side interactivity regardless of how they were implemented. Core reading and editing functionality should be left alone for now. A good test-case feature would be one that provides an enhancement to functionality that has a more basic, no-JS fallback.

Developing a new component library in any framework will need to be done in a way that aligns with Wikimedia’s existing design system. Integrating any new tools we adopt into this system is a precondition to production usage and should commence as soon as possible.

Teams working on such projects should carefully evaluate the impacts of the new tools on performance, accessibility, developer productivity, etc., and this data should inform the wider framework adoption process.

Additionally, Vue.js has been used successfully in production by Wikidata for several years; WMDE is currently experimenting with the use of server-side rendering for a new feature. As part of our evaluation process, WMF should consult with WMDE to learn from these experiences.

Conclusion

The Frontend Architecture Working Group was tasked with providing recommendations to the wider Foundation to guide future work; this RFC is one of those recommendations.

Adopting a framework is not the same thing as designing a new architecture; there will be follow-up RFCs to address other questions that came up in the FAWG’s work. We believe that gradually adopting a modern JS framework in a thoughtful way will allow us to improve the experience for both developers and users within our projects now, while some bigger architectural questions continue to be evaluated.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Base added a subscriber: Base.Dec 30 2019, 7:32 PM
abi_ awarded a token.Jan 2 2020, 6:59 AM
abi_ added a subscriber: abi_.
awight awarded a token.Jan 7 2020, 8:39 AM
awight added a subscriber: awight.

@egardner are you okay with this going on last call after the TechCom meeting next week?

@kchapman I assume that after Last Call, there is some kind of official vote on whether or not to adopt a given proposal – is this correct?

I'm not seeing the kinds of questions or disagreements that would necessitate keeping this RFC in the discussion phase longer, so I'm fine to move things forward.

Izno added a subscriber: Izno.Jan 9 2020, 5:14 PM

What discussion has been held regarding the fact we have multiple other Javascript libraries (some mentioned in the description) in use and/or is this framework intended to deprecate those? If it, what has been discussed about the process? For example, Jquery.ui is still in use, while that was on-paper deprecated some long time ago.

stjn added a subscriber: stjn.EditedJan 13 2020, 3:13 PM

Vue.js is great and, from what I’ve heard, has a better community in comparison to others, but one can only hope that this means the adoption of it in advanced interfaces that benefit from its features, not in everything that requires some JS to work. The prospect of not being able to edit or read stuff, like you already can’t with big Wikidata items, because of the increased costs of JavaScript execution won’t be exactly welcoming to people from developing countries, for example.

Anomie added a subscriber: Anomie.Jan 13 2020, 5:36 PM

Additionally, Vue.js has been used successfully in production by Wikidata for several years; WMDE is currently experimenting with the use of server-side rendering for a new feature.

I'm a bit concerned by the fact that this is experimental, and that it requires an external service to function. The service linked in that page there seems to be extremely bespoke, it's not clear it supports anything other than Wikibase's termbox.

One of the strengths of Wikipedia and MediaWiki is that they largely function when in-browser JavaScript is unavailable. This makes it seem like continuing that is not a priority, and will require complex setup for any wiki that wants to try to do so.

Vue.js is great and, from what I’ve heard, has a better community in comparison to others, but one can only hope that this means the adoption of it in advanced interfaces that benefit from its features, not in everything that requires some JS to work. The prospect of not being able to edit or read stuff, like you already can’t with big Wikidata items, because of the increased costs of JavaScript execution won’t be exactly welcoming to people from developing countries, for example.

The wording here makes me suspect that everything that has been converted to OOUI (and everything where that was intended but not yet gotten around to) would be converted to this, even though most of it really doesn't need much JS fanciness. The best I hope for is that they'll take a "prerendering" approach (i.e. build-time generation of the server-side HTML) rather than "we don't care about non-JS users anymore" or a server-side rendering nodejs service.

I'm struck by a quote I found when briefly researching the ability of vue.js generically to not cause this problem:

In https://github.com/chrisvfritz/prerender-spa-plugin, the author of that plugin wrote:

Recently, SSR (Server Side Rendering) has taken the JavaScript front-end world by storm. The fact that you can now render your sites and apps on the server before sending them to your clients is an absolutely revolutionary idea (and totally not what everyone was doing before JS client-side apps got popular in the first place...)

Demian rescinded a token.
Demian added a subscriber: Demian.
dbarratt added a comment.EditedJan 14 2020, 2:27 AM

Overall I think this is awesome. I think it's an overdue change. 👏 Thanks for all of your hard work. 😃

After much research and discussion, the working group believes that the open-source Vue.js framework is the best match for the Foundation’s requirements right now as well as for the foreseeable future.

I think it's important to remember that Vue is effectively a fork of AngularJS. In a way, it rejects all of the reasons it was rewritten into Angular. Not saying that's a good or bad thing, just that it's important to know the framework's philosophy.

React uses JSX files, while Vue.js uses single-file components. But Vue.js can also use templates provided as HTML strings (which can be provided in a variety of ways). This allows us still define UI elements in a declarative way, one of our key requirements. React can also be used without a build tool, but it falls back on its imperative CreateElement API which is not ideal for general use.

I must be missing something because from the documentation, there isn't any difference between JSX and React.createElement(). In fact, when JSX is compiled, it is compiled into React.createElement() am I missing something? Obviously ReactDOM.render() is imperative, but that is only used to mount the application into the DOM and is used with or without JSX. For instance, here's a Hello World example (from their homepage) in JSX:

function HelloMessage(props) {
    return (
      <div>
        Hello {props.name}
      </div>
    );
}

and then without JSX:

function HelloMessage(props) {
    return React.createElement(
      "div",
      null,
      "Hello ",
      props.name
    );
}

which again, is what the JSX compiles to anyways... I'm not sure I understand how the former is declarative but the latter is imperative? Is React.createElement() being confused with Document.createElement()? Would you mind explaining that a bit more? Of course the syntax of React.createElement() is a bit verbose, but we could wrap it in a simpler function for most use cases.

Finally, key add-ons in the Vue.js ecosystem (router, state management, testing tools, etc.) tend to be maintained as officially-supported products by the core development team, while the equivalent tools in the React ecosystem tend to be community-driven, and support levels will vary.

I think it's important to note that as of React 16.8, state management has become a first-class citizen for React. It made sense for them to add this because so many people were using external state management tools. I appreciate the thoughtfulness by only adding what most people actually need, rather than what they think most people will need.

Testing is kind of a separate conversation anyways. React recommends Jest which works well with React, Vue, and even jQuery. It might be a good idea to use something like that regardless of the framework chosen. I think it might be best to evaluate the testing framework separately from the UI framework.

In contrast, React and its related tools have gone through a large amount of change over the same period of time. The recommended best-practices have changed considerably over the years. Keeping up with these changes would be quite difficult given the pace that WMF projects move at.

According to the CHANGELOG, the last breaking change was when 16.0.0 was released on September 26, 2017 and none of those changes required a major rewrite. Before that it was when 15.0.0 was released on April 7, 2016 (which was the first major version) and none of those require major changes to our code base. I'm not sure I really get this argument. While React has continued to evolve and provide new and better ways to do things, they haven't gotten rid of the 4+ years old ways of doing things).

However, React is still developed primarily by Facebook and will likely continue to change in ways that serve Facebook's needs first and foremost. The WMF had to spend time and energy migrating away from another open-source FB project (HHVM) when Facebook decided that new versions would no longer remain fully compatible with PHP. Sudden changes in direction may be less likely in a project like Vue.js which does not rely on a single dominant corporate backer.

I think someone could use the exact same argument to reject using MediaWiki or WordPress. I realize there is some hurt from HHVM, but I don't think that should be used to stigmatize React. I believe the case of HHVM is a better reason to not use Preact than React proper. It's clear now, that the gains made in performance forks are (at some point in the future) folded back into the mainline project. You can see this with the performance gains gained in React which has closed the performance gap with Preact (just like PHP has closed the gap with HHVM).

Regardless, the premise isn't even accurate in the first place. The creator of Vue works for a company called "Vue Technology LLC" which is a registered for-profit company in New Jersey, United States (Entity ID: 0450081005). To be clear, Vue, like a lot of open source projects, absolutely relies on a "a single dominant corporate backer." Now how that corporate backer plans to make a profit, is beyond my scope of understanding as they are privately held and sharing their financial status is not compulsory in the United States. I hope, for our sake, that it is doing really well. It's entirely possible that it isn't doing well at all and could collapse tomorrow, we really have no way of knowing (nor are company executives obligated to be truthful to non-investors).

To be fair, I have no problem with a for-profit company. I think a positive, sustainable cash flow is way more important than your tax status and whether you have shareholders or not. As an example, I would much rather use an open-source product from a Certified B Corporation than a non-profit that does not have a sustainable business model (though, sadly, we do not have the luxury of either in this situation). My point is that the argument is a fallacy.

I forgot to mention that both WordPress (as of version 5.0) and Drupal (future) use React. I think it might be wise to consult with these two projects and see why they chose React over Vue.

I'm very excited about this proposal and eager to adopt a modern framework like Vue!
I think there's still a lot of infrastructure that needs to be put in place to take advantage of single-file components, and I'm wondering what the developer experience is like without them.

As this article in the description points out, there are many ways to define components in Vue. However, any method that requires setting the template option requires shipping the Vue compiler to the client, as described in the docs (Runtime + Compiler vs. Runtime-only), which seems like a large payload cost. from a performance perspective, is that something we're willing to ship?

Without the compiler, we're really only left with document.createElement or the shorter h() alias inside of a render function.

One of the strengths of Wikipedia and MediaWiki is that they largely function when in-browser JavaScript is unavailable. This makes it seem like continuing that is not a priority, and will require complex setup for any wiki that wants to try to do so.

I didn't read this RFC like this. The server-side rendering ability has even been listed as a requirement for choosing the framework.

How I interpret the intention, the experience in non-JS-enabled browsers is not intended to change (degrade) significantly. It seems likely (thinking about WMDE experiences too) that the server-side rendering of UI might not be happening in PHP, but rather in node, but that shouldn't be making a difference for Wikipedia readers and editors.
For non-Wikimedia installations it might be that folks hosting those mediawiki installation would need to provide a node server, or require their users would need to have JS enabled in their browsers. I cannot say how much of a change that would be for non-Wikimedia MediaWiki installations.

Regardless, the premise isn't even accurate in the first place. The creator of Vue works for a company called "Vue Technology LLC" which is a registered for-profit company in New Jersey, United States (Entity ID: 0450081005).

The VueJS project has a core team of around 10 people and none of them are employed at this "Vue Technology LLC". All of them work for different tech companies amongst which are GitLab and Netlify. Would you say VueJS is led by GitLab and Netlify?

To be clear, Vue, like a lot of open source projects, absolutely relies on a "a single dominant corporate backer." Now how that corporate backer plans to make a profit, is beyond my scope of understanding as they are privately held and sharing their financial status is not compulsory in the United States. I hope, for our sake, that it is doing really well. It's entirely possible that it isn't doing well at all and could collapse tomorrow, we really have no way of knowing (nor are company executives obligated to be truthful to non-investors).

There is no "single dominant corporate backer". Evan You is on Patreon and Vue is on Open Collective and all the corporate backers are listed on the GitHub repo.

To be fair, I have no problem with a for-profit company. I think a positive, sustainable cash flow is way more important than your tax status and whether you have shareholders or not. As an example, I would much rather use an open-source product from a Certified B Corporation than a non-profit that does not have a sustainable business model (though, sadly, we do not have the luxury of either in this situation). My point is that the argument is a fallacy.

Speaking of an open source project being backed by a large corporation, most people probably know the story of Angular 1 and how it was completely rewritten, so all projects using Angular 1 had to be rewritten as well. Therefor having a big corp (in Angular's case Google) behind the framework does not guarantee a sustainable model.

I forgot to mention that both WordPress (as of version 5.0) and Drupal (future) use React. I think it might be wise to consult with these two projects and see why they chose React over Vue.

One can have the opposite argument: Wouldn't it be wise to consult with big projects, which use Vue, as to why they chose it?

dbarratt added a comment.EditedJan 14 2020, 5:20 PM

@Tonina_Zhelyazkova_WMDE my point is that it doesn't mitigate uncertainty, the BDFL could change the direction of Vue just as easily as a public corporation could (I would argue even easier because he has little risk involved in changing, where Facebook has a lot of risk). The reality is, is that the point being made (about mitigating uncertainty) is a business decision, not a technical one, and I don't think it takes all of the factors into account.

One can have the opposite argument: Wouldn't it be wise to consult with big projects, which use Vue, as to why they chose it?

We could go back and forth on this all day. I chose the two projects that (I think?) are closer to us in relation and have bigger user bases with more contributors than we do. In other words, they had more to risk. More importantly perhaps, is why would Facebook's biggest competitor, Twitter, choose to use React?

One of the strengths of Wikipedia and MediaWiki is that they largely function when in-browser JavaScript is unavailable. This makes it seem like continuing that is not a priority, and will require complex setup for any wiki that wants to try to do so.

I didn't read this RFC like this. The server-side rendering ability has even been listed as a requirement for choosing the framework.

You're right, I think I read it a bit too quickly. In particular I missed in the introductory section where it says it currently "would be limited to cases where server-rendered elements can be progressively enhanced within the user’s browser".

But, the general tone still makes me not very hopeful...

For non-Wikimedia installations it might be that folks hosting those mediawiki installation would need to provide a node server, or require their users would need to have JS enabled in their browsers. I cannot say how much of a change that would be for non-Wikimedia MediaWiki installations.

I was very happy when the Parsoid/PHP project was begun to remove one of the major requirements for a bespoke nodejs service in the MediaWiki ecosystem, I'd really hate to have a new one added.

We could go back and forth on this all day. I chose the two projects that (I think?) are closer to us in relation and have bigger user bases with more contributors than we do. In other words, they had more to risk. More importantly perhaps, is why would Facebook's biggest competitor, Twitter, choose to use React?

Indeed, we can cite companies using either framework all day. I assume the underlying point of these examples is that React is more popular than Vue. And yes this is a fact. But is being most popular an argument in favor of choosing React for MW? If yes, why? What does the most popular framework has that Vue doesn't provide? Usually the benefit of the "most popular" is that you can find the most information and get the most help. But docs, guides and help is available for Vue too. And, in fact, Vue has a reputation of having the best docs and guides compared to other FE frameworks.
Here's the Vue guide comparing Vue to other frameworks and underling key differences and benefits. I couldn't find anything similar from the React team.

I'm glad a recommendation has been made, and that we can move things forward in other very important topics that maybe are more foundational than the framework, like build tools and processes, and developer workflows. Those decisions will directly affect how any library is used.

That said, respecting the frontend working group's recommendation, I'll join in the conversation.


A couple of data points regarding the bus factor mentioned, looking at the data:

I'm certain Evan is extremely smart and capable, but he is just one person. And that fact, is dangerous for the long term viability of the decision. I do hope the Vue core team actually step up in terms of the coding responsibilities, because the bus factor is huge.


[...] But docs, guides and help is available for Vue too. And, in fact, Vue has a reputation of having the best docs and guides compared to other FE frameworks.

Just for the sake of completeness, I'll add that the React docs are great, like the Vue ones are too. The React team hired last year a full time Documentation engineer and has done a lot of great work, specifically with the getting started and beginner friendliness of the docs.


I think there's still a lot of infrastructure that needs to be put in place to take advantage of single-file components, and I'm wondering what the developer experience is like without them.
As this article in the description points out, there are many ways to define components in Vue. However, any method that requires setting the template option requires shipping the Vue compiler to the client, as described in the docs (Runtime + Compiler vs. Runtime-only), which seems like a large payload cost. from a performance perspective, is that something we're willing to ship?
Without the compiler, we're really only left with document.createElement or the shorter h() alias inside of a render function.

+1. Any choice of framework is the tip of the iceberg in terms of improvements to the frontend development toolchain.

Whatever happens, I hope for Wikimedia projects we don't end up sending compilers to all clients, given the amount of traffic we have it would be extremely inefficient and wasteful to do so.


From the RFC description:

React can also be used without a build tool, but it falls back on its imperative CreateElement API which is not ideal for general use.

It falls back to its JS API, but it is not imperative. It is function calls like the ones you use in Vue with h, like Jan mentioned above. It is the only option if you don't want to send compilers to the client's browsers, which is basically mandatory in any non-toy production website.

In contrast, React and its related tools have gone through a large amount of change over the same period of time. The recommended best-practices have changed considerably over the years. Keeping up with these changes would be quite difficult given the pace that WMF projects move at.

Emphasis mine. This rationale is very much broken, as well as a very poor reason.

First, if we move at glacial pace, we need to figure out how to be more agile and do better, not be complacent with it.

Second, React since release has been very stable, and when they have broken the public API, they have always provided tools in the form of libraries and codemods to migrate code automatically. The reason is that Facebook has ~60.000 components the last time they talked about it, and the people responsible for updating the frontend code of the whole thing is the React team. Yes, those 6 people. They are very careful to be backwards compatible, and when unavoidable, to provide easy and automated migration paths.

Third, yes, the libraries evolve, and provide better practices, and both libraries are the same. React doesn't force you to rewrite your existing components, but it encourages you to build the new ones in some patterns they have found best. Vue is the same, and it is going to happen the same with v3, when they release the composition API. They are not deprecating the existing patterns for developing components, but they will provide a better one for you to adopt on new code or when revisiting old code.

Their current strategy and consequences are the same. Actually, it was not long ago when there was a lot of vue drama because the community thought v3 would deprecate the v2 APIs. With the release of suspense and hooks the react community didn't freak out, because all changes to versions have been very much backwards compatible and with easy migration paths, so no-one expected differently.

Vue.js development is not led by a single corporation whose goals may diverge from those of the WMF

Finally, this has already been pointed out by David, which is not very true in reality, and seeing the links to the contribution graphs I posted above. Vue is led by one committer who worked for Google. I don't think this reasoning is very sound in comparison.


Like I said at the beginning, I'm happy there is a decision made, and we can move onto other important topics.

I hope next decisions are better justified. Some times, the reason is not as rational or factual and trying to make it look like it is can be a mistake when others look at the justification. Maybe it would've been better to just state that it is personal preference and knowledge of the committee when comparing two good options, rather than digging for logic reasons where there may not have been that many.

Onwards to LESS/CSS/SASS, Javascript/Typescript/Babel, Webpack/Parcel/ESM/RL, the road is long and there is much to cover.

daniel moved this task from Inbox to Under discussion on the TechCom-RFC board.Jan 15 2020, 9:38 PM

I'm very excited about this proposal and eager to adopt a modern framework like Vue!
I think there's still a lot of infrastructure that needs to be put in place to take advantage of single-file components, and I'm wondering what the developer experience is like without them.

Supporting single-file components wouldn't actually be that hard at all. With small modifications to our existing infrastructure, we could have ResourceLoader automatically remap SFCs to JS component definitions (with the template as a string), because this transformation is very simple. We wouldn't be able to support ES6 or scoped styles though (because those depend on preprocessing steps that use nodejs libraries).

As this article in the description points out, there are many ways to define components in Vue. However, any method that requires setting the template option requires shipping the Vue compiler to the client, as described in the docs (Runtime + Compiler vs. Runtime-only), which seems like a large payload cost. from a performance perspective, is that something we're willing to ship?
Without the compiler, we're really only left with document.createElement or the shorter h() alias inside of a render function.

My proposal above is basically to let developers write #7 (single file components) and transform them to #1 (template passed as a string to the template option). This would keep things simple, but would also require shipping the compiler to the client, which as you point out is inefficient.

The only way to avoid shipping the compiler to the client is to compile templates on the server side. One way we could do this is have a build step and commit the compiled template files to the repository. This is what we already do for server-side Handlebars templates in Flow, and what MobileFrontend does for its Webpack bundles. Committing built files to the repo isn't great, but we haven't agreed on a better way to manage build steps yet (see T199004). Another way would be to have ResourceLoader's SFC transformation step shell out to vue-cli and compile the template on the fly. This would be just like how we handle JS/CSS minification, URL remapping/embedding in CSS, CSSJanus and LESS compilation, except that those things are all implemented in PHP while this would require shelling out to a nodejs tool, which may be slow. (But would it be slower than LESS compilation?)

In summary, I think our options are:

  • Transform SFCs on the fly using simple PHP code; compile templates client-side
  • Run build step that transforms SFCs and compiles templates; commit built files to repo
  • Transform SFCs and compile templates on the fly by shelling out to vue-cli

I'd also be very interested to hear thoughts on the above from @Krinkle and @egardner especially.

chasemp moved this task from Incoming to Watching on the Security-Team board.
dbarratt added a comment.EditedJan 17 2020, 4:37 AM

Indeed, we can cite companies using either framework all day. I assume the underlying point of these examples is that React is more popular than Vue. And yes this is a fact. But is being most popular an argument in favor of choosing React for MW? If yes, why? What does the most popular framework has that Vue doesn't provide?

I think this might be conflating the technical and the business arguments.

From a technical perspective, you're absolutely right, being the most popular, is absolutely not a standard of excellence. From a business perspective, being popular can help mitigate uncertainty and risk.

As an analogy, an engineer might find a Koenigsegg to be the best car in the world, but owning that car (even if we had the money) would carry an immense amount of risk (theft, repairs, insurance, company's solvency, etc.). On the other hand, buying a Toyota Camry is clearly not technically superior, but carries very little risk in the way of ownership. Obviously this isn't a perfect analogy, but I hope it helps illustrate my point.

In 2019, there were 230 (excluding vue-bot) commits to Vue, 153 (66.5%) were authored by a single individual. During the same time period, there were 2,135 commits to React and 4 contributors made more than 153 commits and the top individual could only account for 34.2% of commits. 2 contributors individually made more commits to React than the total number of commits to Vue.

To reiterate:

Vue.js development is not led by a single corporation whose goals may diverge from those of the WMF.

is objectively false.

From what I can tell, React mitigates this uncertainty much better than Vue does. It is hard for me to imagine a scenario in which Wikimedia chooses Vue, but does not end up investing significantly in maintaining it.

In summary, I think our options are:

Another option that I think should be considered is using React instead of Vue.

From a business perspective, being popular can help mitigate uncertainty and risk.

[citation needed]

(An example, yahoo being the most popular search engine back in early days)

Here are a few more requirements that I think need to be considered with this proposal (being not familiar with React nor vue):

security side:

  • Has a good track record of responding to security issues in a timely manner
  • Has good defaults/APIs that makes it hard to introduce XSS issues and makes it obvious in code review if someone is doing something potentially unsafe (see some examples Chris provided at https://www.mediawiki.org/wiki/Requests_for_comment/Template_engine)
  • Does not require me to npm install stuff off the internet just to run client-side MW JavaScript (e.g. all PHP dependencies are audited/manually reviewed and then checked into git in mediawiki/vendor).

software freedom/redistributor side (with my Debian partially hat on):

  • MediaWiki tarballs must ship the preferred form of modifying the JavaScript code, not a bunch of minified files ("Corresponding Source" in GPL lingo)
  • This should not introduce dependencies upon things that aren't already included in most Linux distributions

Also, what exactly is this going to replace/obsolete if successfully adopted? Are we going to drop all of jQuery/OOUI/mustache/etc. in favor of vue.js?

TK-999 added a subscriber: TK-999.Jan 17 2020, 9:22 AM
Addshore added a subscriber: Addshore.
Addshore added a comment.EditedJan 17 2020, 10:39 AM

As an analogy, an engineer might find a Koenigsegg to be the best car in the world

I don't believe anyone has said any of these frameworks are the "best in the world", so this analogy probably doesn't make sense.

I distinctly remember seeing:

After much research and discussion, the working group believes that the open-source Vue.js framework is the best match for the Foundation’s requirements right now as well as for the foreseeable future.

In 2019, there were 230 (excluding vue-bot) commits to Vue, 153 (66.5%) were authored by a single individual. During the same time period, there were 2,135 commits to React and 4 contributors made more than 153 commits and the top individual could only account for 34.2% of commits. 2 contributors individually made more commits to React than the total number of commits to Vue.

React appears to be made up of one git repo and vue multiple.
If you count the vue repos that are linked in the readme you end up with 1105 commits (vue) vs 1830 (react) based on some bad maths by me....
This means vue probably has around 60% of the commits of react, which isnt as dramatic as the

Broken down more to comment on it ...

there were 2,135 commits to React

I didn't get this number, but 1830 instead for react

In 2019, there were 230 (excluding vue-bot) commits to Vue

I would include the bot..
The same changes probably happen in the react repo, just they are not automated.

2 contributors individually made more commits to React than the total number of commits to Vue.

Not sure that is a good measure of much either

Another option that I think should be considered is using React instead of Vue.

It was considered (see task description)

We believe that the only libraries which currently satisfy all of the requirements above are React and Vue.js.

Demian added a comment.EditedJan 17 2020, 12:55 PM

When choosing a framework, the most important in my view is that the chosen framework be tailored to the specific needs of the project and the community's experience. I think this aspect should be explored in detail as well, so in the next 1 or 2 decades (until these frameworks are superseded and we have this discussion again), we get the best out of the chosen framework.

Compared to React, Vue puts a bit more focus on approachability. Making sure people who know basics such as: HTML, JavaScript, and CSS can pick it up as fast as possible. (1)

Wikimedians are primarily not developers, we are familiar with document processing and templates. Vue templates are similar to wikitext templates, however much simpler and friendly.
React JSX however, is wrapped into javascript. This difference might be insignificant for an experienced developer, but it is added complexity for a non-developer who wants to get involved in design work.

Vue is excellent for creating interactive multi-page apps. It allows you to quickly import the core library and inject Vue into the existing pages. You don’t even need to use components for simpler features.
Although Vue is well-suited for developing large SPAs, it wasn’t created for this purpose. As your project grows, reusing HTML templates becomes a pain compared to JSX syntax. (2)

Generally React is designed with webapps in mind, whereas Vue also favors simple use-cases. The differences are small but reflect a different focus. In my view, our purposes are better aligned with Vue's: MediaWiki is not an app and familiarity of the syntax means less barriers to entry.

This choice is for our primary web presence where we work with articles. It affects the skins, navbar, notifications (Echo), search tool, history, logs, watchlist, editor: the tools that are part of a common frame (layout). These tools are focused on document-processing.

More technical and complicated tools - for ex. statistics - need not be constrained by this choice. If another framework is better equipped for those purposes, that should be used, independent of the framework used for presenting articles. For ex. I can imagine that the developer of a specific statistical tool would want or need to use a specific component only available in one framework. These tools don't need to be integrated with the primary interface, therefore the choice is up to the developer. Even if it would be integrated, using both frameworks is somewhat wasteful, but possible.

Whatever the choice will be, the primary purpose of this RfC is the introduction of a modern, reactive framework and the actual choice is of secondary importance.
The choice is not as fundamental and binding as the choice of php7 vs. hhmv: that was a low-level change that influenced all projects. The choice of a UI framework has less impact.

Regarding the future of these frameworks:

The speed at which web frameworks and paradigms come and go, I expect both Vue and React to be superseded within 5 years (numbers are arbitrary) by a new, yet not as popular approach and deprecated within 10 years in favor of the new technology. In a decade I expect this discussion to happen again to choose the new technology of that time. When choosing a framework, we are choosing it for this timespan only.

Both frameworks have been around for 5+ years and have a notable community. If the creators of these frameworks would change their path in a problematic way, the communities would be able to keep alive and up-to-date these frameworks with current browsers, only the technology itself would stop advancing. That's all that Wikimedia needs: most of our web presence currently uses old technologies, that still works. 10 years from now that wouldn't be more an issue, than now.

Tarrow added a subscriber: Tarrow.Jan 17 2020, 12:57 PM
  • Does not require me to npm install stuff off the internet just to run client-side MW JavaScript (e.g. all PHP dependencies are audited/manually reviewed and then checked into git in mediawiki/vendor).

I believe that either react or vue could be included in a php-vendor-like git repo we control. It could even be just checked in as a library to resources/src/. Similar to the way we currently ship jQuery.

software freedom/redistributor side (with my Debian partially hat on):

  • MediaWiki tarballs must ship the preferred form of modifying the JavaScript code, not a bunch of minified files ("Corresponding Source" in GPL lingo)

Could we ship either react or vue in the same way we do jQuery in the tarballs? I don't think this RFC is about running some build step so as far as I can tell no code would be transformed or minified before run time. There is (T199004) where maybe this point would be important though?

  • This should not introduce dependencies upon things that aren't already included in most Linux distributions

I don't think this specifically introduces any extra dependencies. Perhaps this is also important in the (vaguely?) related build step ticket (T199004).

Also, what exactly is this going to replace/obsolete if successfully adopted? Are we going to drop all of jQuery/OOUI/mustache/etc. in favor of vue.js?

As I read it I think the RFC isn't proposing that. In the description it mentions an initially limited scope.

Task Description says:

[Adoption should] be limited to one or two case-study projects that fall within the upcoming Desktop Refresh project. These should be small-scale, discrete features which would rely on client-side interactivity regardless of how they were implemented.

I'm not sure I feel like I'm competent to discuss how effective the modern frameworks this RFC discusses are on the track record of security issues. Maybe someone from FAWG can comment?

I'm also not really that confident about discussing how they encourage best practices re XSS etc. I found the vue docs to be fairly readable: https://vuejs.org/v2/guide/security.html which suggests to me that in most cases things are sanitised and the smell to look for is v-html which is the way to shove un-escaped stuff in. Again maybe a FAWG person could add anything more they talked about on this.

Demian added a comment.EditedJan 17 2020, 9:25 PM

I forgot to mention that both WordPress (as of version 5.0) and Drupal (future) use React. I think it might be wise to consult with these two projects and see why they chose React over Vue.

One can have the opposite argument: Wouldn't it be wise to consult with big projects, which use Vue, as to why they chose it?

It would be wise to explore a few projects why they chose either framework, but so far I've only found Gitlab's reasoning linked by Tonina.
Instead, I'll pick some reasons from neutral comparisons, starting with the more concise, aiming to be neutral myself. Long post, summary at the end.

Comparison A: https://www.mobileappdaily.com/2018/08/20/reactjs-vs-vuejs
When To Deploy React.js
  • While developing a complex app
  • When developing both Mobile and Web App
  • For community support
Why Use React.JS?
  • No need to rewrite the code: When using React Native for building an interactive user interface, there is no need for the developer to write the code from the scratch and it saves all the extra effort while increasing the efficiency at the same time.
  • Components can be reused: The component-specific structure of React gives offers the facility to develop applications using an agile approach, which is simplified for the developer with the help of the reusable components.
  • ReactJS is a single codebase: Developers often have to write app's code separately for different platforms like iOS and Android but with the React JavaScript framework this issue is resolved as it is a single codebase.
  • Compatibility with third-party plugins: Another huge reason to use this JavaScript framework is that react.js provides great compatibility with third-party plugins without facing any speed or memory space issue.
When To Deploy Vue.js
  • While developing a web app having templates
  • When developing a simple category app
  • When racing against time
Why Use Vue.JS?
  • Reduced optimization efforts: The component's dependencies are automatically tracked in Vue.JS and during its render that's why the system is aware of when to re-render thus, reducing the optimization efforts.
  • Official support: Although both React and Vue provide robust Routing Solutions, but when it comes to official support corners Vue.js leads react. In Vue native, the state management and routing libraries are officially backed up, unlike react.js updates.
  • Ease-of-use: As this uses the standard HTML-based templates, the revamping process of an already existing app becomes much easier. This ease-of-use has made Vue a popular framework with the reusable templates and effective structure.
Comparison B: https://www.codeinwp.com/blog/angular-vs-vue-vs-react/ (December 11, 2019)

React, interestingly, combines the UI and behavior of components. For instance, here is the code to create a hello world component in React. In React, the same part of the code is responsible for creating a UI element and dictating its behavior.

  • My note: This is a benefit in highly interactive, complex UIs, where the DOM is strongly coupled with the functionality and often change together. The change can be made in one place.

Vue: Further, you can also use pre-processors in Vue rather than CSS, which is a great functionality. Vue is great when it comes to integration with other libraries, like Bootstrap.

  • My note: MediaWiki style sheets are coded in LESS and pre-processed to generate CSS.
Comparison C: https://www.mindk.com/blog/react-vs-vue/ (December, 2018)
templating vs JSX

Any valid HTML can be a Vue template. You can add JS functionality with bindings and custom directives (attributes). Templates allow you to gradually migrate your project to Vue. The framework has a great degree of customization allowing you to:

  • Use SCSS or CSS scoping instead of CSS;
  • Write your code in preprocessors like Pug;

JSX gives you the versatility of a full programming language with temporary variables, flow controls, and referencing JS values directly in scope. JSX also supports sophisticated IDE features like autocomplete, type checking, or linting.
In the end, the choice between JSX and templates comes down to personal preference. JSX can feel more powerful and flexible while templates offer a clear separation of concerns preventing you from injecting too much logic into views. Finally, designers and HTML developers are seldom used to JSX which makes collaboration a bit of a problem for UI/UX-heavy teams.

Documentation

Vue has wonderful docs and its API references are one of the best in the industry. They’re well-written, clear and accessible dealing with pretty much everything you need to know to create Vue applications.

  • Unlike React, the docs are translated in several languages in addition to English.
  • For better or worse, Vue is more opinionated than React with many issues having a clear answer in the docs.

React’s documentation pales in comparison with Vue’s. It goes through the basics of React development and includes some advanced concepts but the presentation isn’t as accessible or well-structured. What’s more, it doesn’t include the detailed overview of React ecosystem like in Vue’s docs.

Scalability

With front-end frameworks, scalability comes in two flavors: expanding a single-page application (SPA) and adding more pages to a traditional MPA.

  • Vue is excellent for creating interactive multi-page apps. It allows you to quickly import the core library and inject Vue into the existing pages. You don’t even need to use components for simpler features.
  • Although Vue is well-suited for developing large SPAs, it wasn’t created for this purpose. As your project grows, reusing HTML templates becomes a pain compared to JSX syntax.
Comparison D: https://www.dunebook.com/react-vs-vue/ (December 5, 2019)
  • Vue is simpler in terms of syntax. In React, all components express their UI within render functions using JSX, a declarative XML-like syntax that works within JavaScript.
  • React has a CBA with pure JavaScript; a declarative style; and powerful, developer-friendly DOM abstractions.
  • React provides outstanding performance thanks to its virtual DOM and smart-reconciliation algorithm, which, as a side benefit, lets you perform testing without spinning up (starting) a headless browser.
  • Vue is incrementally adaptable, with a core library focused on user interfaces that you can use in existing projects
  • Vue is approachable–the beginners can pick up the library easily, and the confirmed developers can be productive very quickly
  • Vue is a little smaller & faster than react. It doesn’t mean Vue is better than react.
  • In a nutshell, if you need to build a lightweight or medium-sized application, or maybe even prototype an idea? Use Vue. Building a larger application? Use React
GitLab - Vue: https://about.gitlab.com/blog/2016/10/20/why-we-chose-vue/

Simplicity and ease of use. Primarily what drew us to Vue.js is that it allows our team to easily write simple JavaScript. Getting started with Vue.js is extremely easy. Its source code is very readable, and the documentation is the only tutorial you'll ever need. You don't need external libraries.
[...] what we love about Vue.js: it's an elegant combination of structure and simplicity.

Vue - official comparison: https://vuejs.org/v2/guide/comparison.html

In React, everything is just JavaScript. Not only are HTML structures expressed via JSX, the recent trends also tend to put CSS management inside JavaScript as well. This approach has its own benefits, but also comes with various trade-offs that may not seem worthwhile for every developer. Vue embraces classic web technologies and builds on top of them.
[...] as the default experience we offer templates as a simpler alternative [to JSX]. Any valid HTML is also a valid Vue template, and this leads to a few advantages of its own:

  • For many developers who have been working with HTML, templates feel more natural to read and write. The preference itself can be somewhat subjective, but if it makes the developer more productive then the benefit is objective.
  • HTML-based templates make it much easier to progressively migrate existing applications to take advantage of Vue’s reactivity features.
  • It also makes it much easier for designers and less experienced developers to parse and contribute to the codebase.
  • You can even use pre-processors such as Pug (formerly known as Jade) to author your Vue templates.

Vue has even taken [the state management] model a step further with Vuex, an Elm-inspired state management solution that integrates deeply into Vue that we think offers a superior development experience.
Another important difference between these offerings is that Vue’s companion libraries for state management and routing (among other concerns) are all officially supported and kept up-to-date with the core library. React instead chooses to leave these concerns to the community, creating a more fragmented ecosystem. Being more popular though, React’s ecosystem is considerably richer than Vue’s.

WordPress and Drupal

I haven't found the answer why WordPress uses React. Here are a few references that popped up while searching:

While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.

My note: WordPress being the most popular CMS, the most likely reason for their choice - similar to Drupal's - is the adoption (popularity) of React.

It is worth to note that - if not for WordPress -, today we might not be considering React because of that license clause they tried to implement.
Regardless of who's the backer of a project, unwanted turns can happen. It's only the balance between the community's and the backer's power that can prevent that from happening. In this sense the creators of Vue have less power to make a change to their project that would make Vue unsuitable for MediaWiki.
All in all I find it very unlikely that any of these projects would take a severe turn, that necessitates abandoning that project. If it might happen, it could happen to any of them (it almost happened to React).

Sources

Not cited:

Summary

Vue and React has the same purpose, the same or very similar features (in the core or in popular plugins). These differ mostly in the details and implementation approach. I'm listing only those features that distingush these frameworks for MediaWiki's purpose.

React:
  • JSX (React's template functionality) has a more streamlined developer experience in highly complex applications with a lot of business logic written in javascript.
  • CSS is part of the JSX code, closely coupled with the javascript and the html.
  • The developer has to think about performance optimization (shouldComponentUpdate property) — a common source of hard-to-debug, circumstantial bugs.
  • React Native for mobile platforms is a mature product. Components can be shared between the webapp and the mobile app.
Vue:
  • HTML templates have a more designer-friendly syntax
  • Support for LESS, SCSS, Pug (compact html syntax) pre-processors.
  • The developer does not have to think about when a component should be updated. There's built-in dependency tracking, which has a computational price that, but that cannot be observed in tests. Vue actually has a small performance advatage in many tests.
  • Ease-of-use, well organized documentation (some translated to multiple languages).
  • Vue Native exists. It has a small market share.
Both frameworks have:
  • reactive DOM updates (data binding) -- core feature
  • DOM generation from components (templates) -- core feature
  • router (URL parsing, browser history navigation) -- plugin for React, in core for Vue
  • server-side rendering (for search engines and fast first-page loading time, old browsers and low-bandwidth connections) -- plugin for both
Summary summary

The above cited comparisons seem to agree that React is better suited for complex, business-logic-heavy single-page applications. MediaWiki is neither of these.
Projects that could benefit from React's focus on javascript-first design - like statistics and specialized batch management interfaces - are free to choose their own framework, or even combine the two, independently of the framework used for the primary document-viewer and editor interface.

The articles also seem to agree on that Vue - in comparison to React - is better equipped for the document-focused multi-page environment of MediaWiki,

  • for designers and casual developers - who are of a much greater number in the Wikimedia Movement, than highly experienced developers,
  • for progressively (incrementally) transitioning the existing MediaWiki code-base.

I've only explored the developer experience with the citations above: in my view that's what predetermines how easily developers and volunteers can adapt to the new framework, which in turn determines how many contributors will get involved with the development.
The community and stability of these frameworks has been investigated above and I have no concerns about the availability of either framework in the next decade, after which presumably there will be another framework to adopt.

Conclusion

Based on this research I have the strong opinion that Vue offers an easier transition and easier adaptation for designers and volunteers. These benefits could result in more involvement from the community in development, resulting in more UI improvements and hopefully bridging the gap between developers and community members to some extent.

Osnard added a subscriber: Osnard.

[citation needed]
(An example, yahoo being the most popular search engine back in early days)

I wasn't able to locate any research papers on the subject, perhaps because of my lack of proper search terms, or (more likely?) they are behind a paywall (or maybe the research hasn't been done).

I was able to find an article by Chris Doig where they list a lot of risks associated with choosing a software vendor (in our case, either Facebook or Vue Technology, LLC) one of them being:

When you buy from companies like Microsoft, IBM, Oracle there is little risk of them going out of business. Unfortunately, larger vendors are seldom hotbeds of innovation. If you want more innovative software, you may need to consider smaller vendors or startups. Then there is the risk that these companies are not what they appear to be.

Not only are newer business less likely to survive (only 28% survive to their 6th year), but companies who fail to reach a positive balance sheet (whether for-profit or non-profit), cannot continue to operate.

Continuing your example, if we were living in 1997, choosing Yahoo! as the search engine would be a wise choice. Between a publicly-traded company and a company that doesn't even exist yet (Google), of course Yahoo! is the better choice. Only by using hindsight bias can we realize that we should have waited a year and chosen a startup company that nobody had ever heard of. Without knowing the future, it's impossible to know what new technology is going to replace both Vue & React. However, choosing the less risky of the two is a way to mitigate business risk.

To be clear, it is perfectly fine to take on the increased risk of choosing Vue over React. Like the article mentions, there are other factors you would want to take into consideration (like how some in this thread have mentioned how quickly the projects respond to security concerns, etc.). However, it is important to acknowledge the risk we are taking on, and I think it's important to talk about how we plan to mitigate that risk.

I think the greatest risk to Vue, is that Vue Technology, LLC goes out of business and the foundation is forced to either start investing heavily in its maintenance or migrating to a different framework. If we want to take on that risk, that is totally fine, but can we call a spade a spade and acknowledge the business risk associated with choosing Vue?

In a lot of ways, this reminds me of how WordPress and Drupal chose jQuery, and Joomla! chose MooTools. I have no idea which one is technically superior, but I don't want to be the Joomla of this story. Of course, none of us know the future, but if we're going to walk into this, I hope we can with our eyes wide open.

I wanted to join in this discussion earlier, but I spent the last two weeks fighting off the flu. Thanks to everyone who has participated so far, it's great to see interest in this topic. I'd like to try and speak to a few points that have been raised so far. I'll paraphrase some of the questions I've seen upthread:

1. Does this proposal change the way Mediawiki uses Javascript generally (i.e. by introducing new requirements in browser or on server)?
I think the answer to this question is no – at least not immediately. The focus of this RFC is to change the way we build the interactive, JS-heavy elements we are already shipping to users. For now, that means using a strategy of progressive enhancement, where server-rendered content would be replaced by more interactive, UI elements written in Vue.

There was a lot of interest within the FAWG in server-side rendering (SSR), so I think that's something that we will continue to explore. It may even be possible to get server-rendered Vue components without needing an external Node.js service, by relying on something like PHP v8JS. Being able to define a single set of server-rendered UI components that would work for users with and without JS (as opposed to having to duplicate our UI in JS and PHP) would be a big step forward in terms of productivity.

But any change of this nature would be the subject of a new RFC; using a tool like Vue keeps these possibilities open in the future but doesn't force us into working this way until we decide that we want to.

2. Would Vue replace OOJS/OOUI/jQuery UI/etc?
In the short term, no – we want to develop on or two test features to ensure that this is a good addition to our technology stack. See the discussion of pilot projects, etc. in the RFC.

But ultimately (assuming the initial projects are successful), probably so. A lot of work went in to OOJS and OOUI, but the unfortunate reality is that basically no one outside the Wiki-universe uses these tools or pays attention to them. The entire paradigm of how these tools work is increasingly out of sync with contemporary standards in web development (non-reactive, everything is mutable, heavy reliance on jQuery not just for DOM manipulation but for promises & object utilities, Java-style inheritance, etc). I think we would be better of if we were able to adopt some more commonly-used solutions instead of having to maintain our own separate ecosystem for everything.

Of course this is easier said than done, so any migration away from something like OOUI would be a big process that would take some time. Porting over the tools that have been developed internally for accessibility and internationalization would be a top priority. But if we could pull this off, the rest of the web could benefit from the Foundation's work in these areas (OOUI has great accessibility but no one else is using it unfortunately).

3. Vue vs React
Both Vue and React are great, and to some extent the choice between these two frameworks is always going to be a bit subjective. However, I think that there are some areas where Vue has advantages when it comes to our specific use-case.

  • It will be much easier to integrate Vue into the Mediawiki tech stack as it presently exists because it doesn't require a build step. Ultimately we should adopt some kind of front-end build step, but I have no idea when that will happen. As @Catrope mentioned upthread, we think support for single-file Vue components in ResourceLoader is doable in the near future – provided the JS in those components is written in ES5 (Vue supports this just fine; components are not written using Class declaractions, etc. as is common in React). It's a lot harder to experiment with a new framework if you're forced to choose between 1) re-wiring a lot of your infrastructure, even before your experiment is finished, or 2) using the tool in a very non-standard way (harder to evaluate). The downside is that we have to ship the Vue template compiler in production, but we can stop doing this once we have a better build system in place. Vue's full (runtime + compiler) build comes in to ~33KB gzipped, so I think this is a compromise we can live with for the time being.
  • HTML templates: Vue components are defined in HTML and CSS, the classic languages of the web. I think this will make it much easier for designers, less-experienced developers, and interested people generally to understand what is going on (@AronManning mentioned this above and I'm in agreement). As a large open-source project, I think anything we can do in the interest of transparency / lowering barriers to contribution is worth considering.
  • Do more with fewer libraries: this was one of the points in the original RFC text above – if we need to explicitly whitelist, audit, and vendor a limited set of 3rd-party libraries (similar to how PHP dependencies are handled) then I think that using Vue means fewer things to keep track of.
  • Stability: I know that not everyone is in agreement here, but I still think Vue has some advantages in terms of stability vs. React. The React team seems to be sending very strong signals to the community that the Hooks API is the future (they are recommending people write new code based on Hooks instead of classical components, for example). Not long ago there was a similar big push to write as much as possible using stateless functional components. Even if the core React library itself has handled breaking changes pretty gracefully, the idea of what constitutes "best practices" seems to have gone through a lot of changes. This is all magnified once you enter the world of 3rd-party libraries: what's the currently-accepted "best" way to handle CSS in React components, for example? See the re-write/breaking changes in React-router for another example. In contrast, Vue has been good about offering alternative ways of doing things while preserving a stable set of practices for basic use. Vue v3 will add support for something very similar to React's Hooks API but the idea is that it's not something that everyone will need to reach for. Similarly, you can write stateless functional components (and even use JSX) in Vue but it's only going to be useful to do so in particular edge cases.

Again, these are not reasons why "Vue is better than React" – but I do think that a case can be made that Vue is a better fit for the needs of the Foundation right now.

Demian added a comment.EditedWed, Jan 22, 7:05 AM

I think the greatest risk to Vue, is that Vue Technology, LLC goes out of business and the foundation is forced to either start investing heavily in its maintenance or migrating to a different framework. If we want to take on that risk, that is totally fine, but can we call a spade a spade and acknowledge the business risk associated with choosing Vue?
In a lot of ways, this reminds me of how WordPress and Drupal chose jQuery, and Joomla! chose MooTools. I have no idea which one is technically superior, but I don't want to be the Joomla of this story. Of course, none of us know the future, but if we're going to walk into this, I hope we can with our eyes wide open.

Yes, we should understand the risks. I tried to measure the popularity with search trends:
React js as a search term is 1.5x times as popular as Vue js in the past year. (1).
In the last 5 years, it was 3x times as popular (2015-2020)
Jquery in its first 5 years was ca. 15x as popular as Mootools (2007-2012)
jQuery vs MooTools can be hardly compared to React vs Vue, Mootools never really took off the ground (2006-2020).

To neutrally assess the risks, we have to consider Facebook's attempt to change the license of React. Vue is not in a position where such an attempt could be made.

Vue now has a significant corporate user-base (source), presumably thanks to the easy, progressive transitioning:

  • Facebook, Netflix (also using React)
  • Adobe, Grammarly, Behance, Xiaomi, Alibaba, Codeship, Gitlab, Laracasts, ...

If the backing of Vue would collapse, GitLab alone could take on the development: that would be cheaper than migrating to React.
It is very unlikely, that all these users would abandon Vue if the unexpected happens. Even if they do, the WMF is already developing and maintaining a UI framework on its own. Keeping alive Vue would not be much harder.

I have the impression that Vue and React entail similar risks, as far as that can be measured. What's bigger risk - Vue's smaller backing, or Facebook's greed - cannot be objectively evaluated.
With both frameworks, it is very unlikely that their community would let go of it, should anything happen.

Understanding these risks, I'm sure the technical benefits, which are a reality today, far outweigh a possible, but unlikely worst-case scenario in a theoretical future.

In T241180#5822020, @AronManning wrote:

To neutrally asses the risks, we have to consider Facebook's attempt to change the license of React. Vue is not in a position where such an attempt could be made.

While I agree with the overall decision, we shouldn't misrepresent what happened. Facebook did change the license of react in 2014 and nobody cared for years until it blew up in 2017. Also, their defensive patent clause only concerned people/companies that own/create software patents. And since we are writing GPL software, that should never affect us, right?

Demian added a comment.EditedWed, Jan 22, 4:32 PM
In T241180#5822020, @AronManning wrote:

To neutrally assess the risks, we have to consider Facebook's attempt to change the license of React. Vue is not in a position where such an attempt could be made.

While I agree with the overall decision, we shouldn't misrepresent what happened. Facebook did change the license of react in 2014 and nobody cared for years until it blew up in 2017. Also, their defensive patent clause only concerned people/companies that own/create software patents. And since we are writing GPL software, that should never affect us, right?

Thanks for clarifying. The licensing question is of no interest (or concern) to me, thus I mentioned it superficially, as a drawback that can happen if the backer is too big.
Also to clarify: I do not make a decision for the WMF, only for myself. I wish to present the reasons, instead.

I don't believe anyone has said any of these frameworks are the "best in the world", so this analogy probably doesn't make sense.

I did say:

Obviously this isn't a perfect analogy, but I hope it helps illustrate my point.

If it doesn't help then please feel free to discard it.

If you count the vue repos that are linked in the readme you end up with 1105 commits (vue) vs 1830 (react) based on some bad maths by me....
This means vue probably has around 60% of the commits of react, which isnt as dramatic as the

I may have not been clear. I'm not concerned with the number of commits, as that would be difficult (if not impossible) to compare. I'm concerend with the distribution of those commits. If the claim is that:

Vue.js development is not led by a single corporation whose goals may diverge from those of the WMF.

there doesn't seem to be any evidence to support that claim, and in fact, there appears to evidence to support the exact opposite. In fact, it is not only led by a single corporation (Vue Technology, LLC) it is led by a single individual whose goals may diverge from those of the WMF. (based on the distribution of commits, who owns the trademarks, domain names, etc.).

I have been wondering over the past few days if it would be less risk for Wikimedia Foundation to simply purchase Vue Technology, LLC (and all of its assets). At least that would prevent the company from going out of business or being purchased by another company like Facebook.

I'm really confused by this. vue-router, vue-cli, and vue-loader are not libraries that React offers (though they are offered by the community). These aren't libraries that are part of the proposal. Are we considering adding these to MediaWiki as well? If so I can take a look at the comparable libraries from React. Again, I'm not concerned with the number of commits or even number of contributors, but if we're going to claim that Vue is a "better" choice because it isn't controlled by a single company (individual) then I think we should be able to backup that claim.

I feel like the proposal bounces back and forth between something lightweight and something that has "batteries included" as stated in:

Vue.js may enable us to rely on fewer libraries as dependencies

If that is a goal, it might be beneficial to consider other frameworks like Next.js, though I imagine that is out of scope for this RFC.

I didn't get this number, but 1830 instead for react

I may have used the wrong git command. I did something like this, but that might be wrong. :)

I would include the bot..
The same changes probably happen in the react repo, just they are not automated.

Even if I include the bot, it doesn't change the distribution of commits, which I assume is part of the methodology used to make the claim against React in the first place.

Another option that I think should be considered is using React instead of Vue.

It was considered (see task description)

Apologies, I meant "reconsider." Restated for clarity:
Another option might be to reconsider using React instead of Vue.

dbarratt added a comment.EditedThu, Jan 23, 4:07 PM
  • It will be much easier to integrate Vue into the Mediawiki tech stack as it presently exists because it doesn't require a build step.

I haven't dived into the rest of this, but this really stood out to me.

The React docs are very explicit:

With a few lines of code and no build tooling, try React in a small part of your website. You can then either gradually expand its presence, or keep it contained to a few dynamic widgets.

The rest of that page explains how to do just that. I would recommend reading it and trying it out. :)

Also, React can be used without ES6 (though it might be better to use functional components instead of createReactClass())

@dbarratt regarding need for a build step: there's some discussion of this in the original RFC; it's true that React can be used sans build-step with the CreateElement API.

But I think this is still a second-class experience of using the framework. Useful for edge cases but probably not the way we'd want to encourage for wide-scale adoption here. To get on the "happy path" with React you need JSX (and probably ES6) which means you need a transpiler like Babel. As I've mentioned upthread, I strongly believe that we should look into adopting a front-end build step that could include a tool like Babel, but this is a big change to our infrastructure and probably still at least 1 year away.

Vue has something very similar to React's CreateElement API (the h() function, etc). But it's own happy path (single-file components, aka .vue files) is going to be easier for us to get to from where we are currently. This is because vue files are basically HTML files, so we can work with them using our existing infrastructure (ResourceLoader).

There will be some limitations to this approach:

  1. we'll rely on Vue's built-in template compiler for the time being, which means shipping a little bit of additional code in production;
  2. the JS part of the components will need to be in ES5 for now;
  3. we won't have the ability to write scoped styles for components (but we can still write normal CSS and keep things all in one file for clarity).

Personally I think these are limitations we can live with (plus they will hopefully be temporary). This is what I meant when I said it would be easier to integrate Vue into our tech stack. With a small amount of work we can get most of the advantages of using the framework in the intended way.

Since React and Vue are ultimately very similar, I think that considerations of what the migration path looks like for us to use one or the other can helpfully inform our decision of which one to use.

AnneT added a comment.Thu, Jan 23, 5:45 PM

On the notion of using React without a build step: in my opinion, it's not worth using React at all if you're not going to use JSX. Even this sample code from the React docs is pretty gross compared to HTML, JSX, or a templating language:

return e(
  'button',
  { onClick: () => this.setState({ liked: true }) },
  'Like'
);

Imagine something more complex than a single, simple HTML element. We'd have the same issue we have now in extensions in which markup is built with jQuery, which makes it difficult add/change things quickly or to audit markup for accessibility.

In my ideal world, we'd implement a build step in tandem with introducing Vue or React, but I know that's not likely to be possible, so I see the merit of using Vue over React in this case.

Also, on a higher level, I'm so excited at the prospect of introducing a modern JS framework into our workflow Foundation-wide and believe this will be incredibly beneficial to us in the short and long terms. Thanks @egardner and FAWG!

@dbarratt regarding need for a build step: there's some discussion of this in the original RFC; it's true that React can be used sans build-step with the CreateElement API.

I explained in T241180#5800440 that some of the points in the original RFC seem to be incorrect, but please correct any misunderstanding I might have.

But I think this is still a second-class experience of using the framework. Useful for edge cases but probably not the way we'd want to encourage for wide-scale adoption here. To get on the "happy path" with React you need JSX (and probably ES6) which means you need a transpiler like Babel.

I'm not sure how you got this impression. Following the call to action on React's homepage leads me to the Getting Started page which again, reiterates:

React has been designed from the start for gradual adoption, and you can use as little or as much React as you need. Whether you want to get a taste of React, add some interactivity to a simple HTML page, or start a complex React-powered app, the links in this section will help you get started.

And on the same page explains how you can add it to any webpage in just a few steps. That seems to be exactly what we want to do? It doesn't even require us to use ResourceLoader and as I explained in T241180#5800440, it is what React gets compiled into anyways.

Since React and Vue are ultimately very similar, I think that considerations of what the migration path looks like for us to use one or the other can helpfully inform our decision of which one to use.

Absolutely, but this is somewhat putting the cart before the horse. We have no idea if MediaWiki will ever have a build step. At the same time, I don't think it's necessarily wise to effectively shift that build step to ResourceLoader (which kinda feels like the solution that is being proposed?) In other words, the ideal migration may never happen, so are we content with not having a build step? (i.e. what happens when the temporary solution becomes permanent?)

Absolutely, but this is somewhat putting the cart before the horse. We have no idea if MediaWiki will ever have a build step. At the same time, I don't think it's necessarily wise to effectively shift that build step to ResourceLoader (which kinda feels like the solution that is being proposed?) In other words, the ideal migration may never happen, so are we content with not having a build step? (i.e. what happens when the temporary solution becomes permanent?)

AIUI, this is exactly the reason (well, one of, but an important one) why they consider Vue over React: the ability to move forward with more modern solutions without additional requirements (that might never happen), and why it'd be limited to some experiments at first, so it'd be possible to back out if the additional requirements don't work out and it's found to be unpractical without them.
In other words: the ideal migration may never happen - are we content with not (trying to) advancing our technology at all?

From the Vue docs

When using in-DOM templates or in-JavaScript template strings, the template-to-render-function compilation is performed on the fly. This is usually fast enough in most cases, but is best avoided if your application is performance-sensitive.

It's hard to imagine that Wikipedia is not a "performance-sensitive" application.

To be fair, React also provides a mechanism to compile JSX at runtime, but also warns against it:

This approach is fine for learning and creating simple demos. However, it makes your website slow and isn’t suitable for production.

We will definitely need to study any possible performance impacts from using the template compiler at runtime. If it turns out that relying on the compiler at runtime causes significant perf regressions then we will need to come up with another solution (and re-open some points in this discussion).

But I'm actually optimistic about this. MediaWiki's ResourceLoader already supports client-side template compilation using Mustache Templates. This works fine and is used in a number of places in production now. The functionality we're talking about here is very similar. Browsers are very good at parsing strings into DOM nodes quickly and efficiently.

I think that what the Vue docs mean by "performance sensitive" applications is a situation where you are creating hundreds or thousands of DOM nodes on the fly, or changing things very rapidly (something like a real-time stocks dashboard, for example). I could see how in these kinds of situations, you'd want to make things as efficient as possible and in-browser template compilation could slow things down.

Doing the equivalent thing with React involves shipping the full Babel runtime, which I think is a lot more performance-intensive than parsing strings into DOM elements; now you are dealing with an entire Turing-complete programming language, so parsing is more involved and you need a bigger runtime to do it. I think there is a difference between saying "it makes your website slow and isn't suitable for production" vs. "This is usually fast enough in most cases but is best avoided if your app is performance sensitive."

Anyway, incorporating Babel/Webpack/etc. into our build system has many potential benefits in terms of performance (it would be great to tree-shake libraries like OOUI so that only the pieces which are needed get shipped, for example). But I don't know if or when that will happen.

My hope is that using Vue can provide us a lot of the advantages of modern JS with a few minor trade-offs based on our unique infrastructure. If those trade-offs end up being not so minor, then we can re-evaluate.

Jhernandez added a comment.EditedThu, Jan 23, 10:30 PM

There will be some limitations to this approach:

  1. we'll rely on Vue's built-in template compiler for the time being, which means shipping a little bit of additional code in production;

This is irresponsible. For the amount of traffic we have, the amount of extra computation we are going to force on millions of clients because of our inability to get our process together.

User experience should be first and foremost, before developer experience. This is usually said when using new tools for the sake of devx but in our case it is using old tools and avoiding change.

I strongly suggest the FAWG puts out a recommendation that any code using Vue has to be pre-compiled, either in the repo at commit or deploy time, or if it is gadgets/scripts, client side once when saving the gadget, and not on read/run.

We will definitely need to study any possible performance impacts from using the template compiler at runtime. If it turns out that relying on the compiler at runtime causes significant perf regressions then we will need to come up with another solution (and re-open some points in this discussion).

Looking forward to this research.

But I'm actually optimistic about this. MediaWiki's ResourceLoader already supports client-side template compilation using Mustache Templates. This works fine and is used in a number of places in production now. The functionality we're talking about here is very similar. Browsers are very good at parsing strings into DOM nodes quickly and efficiently.

Product Web went the extra mile to avoid shipping the mustache compiler by default on desktop because of page previews, @Niedzielski wrote about it here: Blog Post: mustache.js replaced with JavaScript template literals in Extension:Popups.

We should hold ourselves to a higher standard and be strict about the performance impact of our decisions, everything matters.

Shipping the vue compiler to production is like we have fully given up from the start.

Hey @Jhernandez! Point taken but of course the integration won't be perfect or frictionless initially. As I understand it, FAWG and Web will be iterating on the initial solution well beyond this RFC so there will be opportunity to uncover integration complexities (such as the ones you noted) that would arise from any choice and I'll be bold enough to say that I'm probably more optimistic than you that we'll figure them out :]

For example, MobileFrontend already has the ability to ship fully compiled assets. The changes you helped plan for the MobileFrontend architecture project (and which are now in production for Popups and MobileFrontend) demonstrate that we have a lot of flexibility for consuming arbitrary frameworks efficiently. I don't know whether Vue.js will require similar changes or not but these past experiences have proven to be quite successful for the desktop and mobile sites and give me confidence that it's a solvable problem. To your point about template parser overhead, I think that having the ability to parse Vue templates would be useful at least for development builds during initial iterations and I'm sure that will be explored more then.

This RFC in my view posits that 1) what we have isn't working 2) Vue.js is not only a viable alternative to what's currently available but a compelling one 3) a change is needed and will likely be imperfect at least at first. I'm 100% for it. I'm confident you'll agree with at least #1 (some points are documented in T225453 for others).

On a personal note, I wish we had had this tooling (or something similar) back when you were leading these efforts on behalf of Web. I believe that had your good ideas (in many ways repeated here but with different framing) met with nourishment instead of being extinguished, we would have something quite remarkable now to show for it but the timing wasn't right it seems. What's most important to me is that these changes are happening now even if it it's a few years tardy. I can't wait to start building things with this stuff!

There will be some limitations to this approach:

  1. we'll rely on Vue's built-in template compiler for the time being, which means shipping a little bit of additional code in production;

This is irresponsible. For the amount of traffic we have, the amount of extra computation we are going to force on millions of clients because of our inability to get our process together.

As @egardner said: let's measure how much slower client-side compilation actually is, so that we can make an informed decision. Unless the performance impact is really bad, though, I would strongly favor starting with client-side compilation first, then working on a way to avoid it / make it faster second.

I strongly suggest the FAWG puts out a recommendation that any code using Vue has to be pre-compiled, either in the repo at commit or deploy time, or if it is gadgets/scripts, client side once when saving the gadget, and not on read/run.

As I pointed out before, there's a discussion about front-end build steps over at T199004, and it's a complicated topic. In particular, there are significant hurdles to running build steps like template compilation at build time. We could, as you suggest, pre-compile templates and commit them to the repository (Flow does this for Handlebars templates that are used server-side). However, your comment about "once when saving the gadget, not on read/run" gave me another idea.

Shelling out to the Vue template compiler from ResourceLoader is likely to be too slow for on the fly processing (we should measure this and find out). But maybe we could lazy-compile templates instead. At first, we'd serve the template uncompiled, and have the client compile it. But at the same time, we'd kick off a job that compiles the template and stores/caches the result. Then, when the module is requested again, we could get the compiled template from cache and serve that instead. This would work even if shelling out to the template compiler is slow, because clients don't have to wait for the compilation step to complete: we just serve them a uncompiled template until the compiled template appears in the cache. There would be some challenges here with ResourceLoader's caching (it'd want to cache the uncompiled version for 30 days, we'd have to find a way around that) and with knowing when we would and wouldn't have to ship the Vue compiler to the client, but I think this is a concept worth exploring. We should also measure how slow shelling out to the Vue compiler actually is, if it isn't terribly slow we might even be able to do it on the fly (with heavy caching, like we do for LESS compilation).

Demian added a comment.EditedFri, Jan 24, 1:32 PM
  1. we'll rely on Vue's built-in template compiler for the time being, which means shipping a little bit of additional code in production;

There were some exaggerated concerns about shipping a 30KiB "compiler" to the clients. This should not be confused with the complexity and execution time of let's say a C++ compiler or - more extreme - a Rust compiler.
I don't have observations about the speed of the template generation, but I've noticed some potential savings in regards of the quantity of javascript written and shipped.

When loading an article on enwiki, the largest js package that gets loaded is a bit above 496 KiB (139 KiB compressed). When I click an image and mmv gets loaded that's another 560 KiB compacted (93 KiB compressed) javascript code + 202 KiB jquery.color (56 KiB compressed) + a few small packages. Altogether 7 packages, 1488 KiB (356 KiB compressed).
Mmv's half MB code is largely ooui and html dom generation. Generating a few lines of html takes a page of js (ad-hoc comparison). Should it be rewritten using Vue, I expect big part of that code would become unnecessary.
Loading that code and generating mmv's dom often takes upwards of 1 second... I wonder if a lightbox in Vue would take that long to appear.

To compare this with WikiWand: it loads 532 KiB (ca. 240 KiB compressed) js together with the minified angular and jquery. This includes the lightbox/mediaviewer in the initial package.

I'm looking forward to the performance tests.

stjn added a comment.Fri, Jan 24, 2:30 PM

We will definitely need to study any possible performance impacts from using the template compiler at runtime. If it turns out that relying on the compiler at runtime causes significant perf regressions then we will need to come up with another solution (and re-open some points in this discussion).

I would, again, suggest to test this on already JS-heavy sides of Wikipedia, and not on something like Desktop Improvements project. Loading additional 150 Kb of Vue.js + compiler (ungzipped, execution time also matters in this) to our existing 600 Kb or so would be absolutely detrimental to performance for something like a language switch toggle.

@AronManning I think a tool like MMV is exactly the kind of thing that could really benefit from a Vue.js re-write. The UploadWizard tool is another.

There are already several places where we are shipping large, complex JS packages to the user for features that exist mostly or entirely in the client side. Consolidating all these separate tools to use one library for rendering could actually save bandwidth and eliminate some redundancy in the code that we ship.

RE: developer vs user experience – I am not advocating for just recklessly tossing in random NPM packages to our runtime dependencies and adding 1MB+ of JS on every page request because "it works fine on my machine". User experience should come before developer experience, but right now I would argue that our front-end developer experience is crippled. This negatively impacts user experience in other ways, because it slows or prevents the development of new features, makes it harder to fix bugs, etc.

If 33KB of JS can address some of those problems then we should at least investigate to see if a reasonable trade-off can be made. I don't think we're being irresponsible if we study the impact and make an informed decision.

simnalamburt added a comment.EditedSat, Feb 1, 9:11 PM

Hi I’m Hyeon Kim and I’ve used both Vue and React more than 3 years in the day job, and also have contributed to a small MediaWiki instance more than 2 years. Since I’ve used both React and Vue in production for more than three years, I believe I understand the advantages and disadvantages of both projects. And I believe that I understand the technical situation of MediaWiki.

I read the RFC and felt that some points about React and Vue in the RFC were different from the actual status quo. I understand that you want to choose a library that suits the needs of MediaWiki, not something that is generally preferred. I just want to say that Vue has some aspects that don't meet MediaWiki's requirements.

In summary, Vue is unstable, slowly evolving, and has sustainability issues.

 

1. Vue is Evan You's one-person project, which poses a risk to MediaWiki's sustainability.

Yes, they do have a team, but who maintains the actual Vue project is only one person[1][2], Evan You, the creator of Vue. Unfortunately, there’s no active outside collaborator either.

[1]: https://github.com/vuejs/vue/graphs/contributors
[2]: https://github.com/vuejs/vue-next/graphs/contributors

If Evan is forced to stop managing Vue due to certain circumstances, MediaWiki will have to manage Vue or change the framework again, which is undesirable.

Also, React’s decision making is more predictable and transparent than Vue. React has an RFC process and decisions are made by the consensus of the React core team. Vue has an RFC process too, but only one person Evan You decides whether to accept or reject the RFC[3].

[3]: https://github.com/vuejs/rfcs/pulls?q=is%3Apr+is%3Aclosed

2. React evolves in a stable and reliable way, while Vue breaks APIs.

When Vue was upgraded from 1 to 2, there were tons of breaking changes[4]. Now, Evan You is also preparing Vue 3, which has major breaking changes[5] again: removal of the filter[6], change of v-model[7], inline-template[8], etc. This RFC mentioned the transition feature, and it’ll be changed[9] too.

[4]: https://vuejs.org/v2/guide/migration.html
[5]: https://github.com/vuejs/rfcs/issues?q=label%3A"breaking+change"+is%3Amerged
[6]: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0015-remove-filters.md
[7]: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0011-v-model-api-change.md
[8]: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0016-remove-inline-templates.md
[9]: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0017-transition-as-root.md

On the other hand, React has been evolved in a more stable way[10][11]. Not only the number of breaking changes was much less than Vue, but also all those breaking changes were changes of only behavior, not API. All removed APIs were deprecated a year ago, so there was an enough time for users.

[10]: https://reactjs.org/blog/2017/09/26/react-v16.0.html#breaking-changes
[11]: https://reactjs.org/blog/2016/04/07/react-v15.html#breaking-changes

Why did this difference occur? This is because React and Vue pursue different values.

3. The core value that the React team pursues aligns much better with the MediaWiki team.

One of React’s design principles is stability[10]. React is not only globally adopted by the community, but also heavily used by Facebook themselves. And it works as a strong incentive for Facebook to maintain backward compatibility of API.

[10]: https://reactjs.org/docs/design-principles.html#stability

However, Vue is a one-person project with no incentive to maintain backward compatibility despite the hard work. Evan You is already overwhelmed with managing Vue alone and can't afford to maintain API compatibility. Vue pursues multiple values as a design principle but stability is not one of them.

4. React is evolving much faster than Vue.

Since Vue 2.5 which was released at 2017-10-13, the development pace of Vue has seriously decreased. Since then, Vue 2.6 (2019-02-04) was the only release that had new features. And since Vue 2.6, Vue 2.x became in maintenance mode which means it’s fixing only bugs and security vulnerabilities. And Vue 3 has been in preview for 2 years.

Within the same period, React evolved dramatically. Fragments, Portals, React Fiber, Suspense, Hooks. These new features impacted the whole frontend community and impacted Vue 3 too. Not to mention that React not only evolved fast but also preserved the API letting existing codes works.

5. Bigger community, more contributors, more free lunch.

As you mentioned, React has a much larger community with many more programmers. Which means MediaWiki can get much more potential contributors by choosing React. And MediaWiki team will be able to save more time since there are many stable libraries out there.

 

In summary, React will be more conducive to MediaWiki's sustainability because it's stable, evolves faster, and has a larger community. There are a few points where Vue suits better with MediaWiki, but I think the disadvantages of Vue outweigh the advantages.

P.S. Please check https://github.com/developit/htm. HTM is useful when you want to use React without any build tools or JSX. HTM template is a string too so maybe you’ll be able to leverage ResourceLoader just like the Vue template.

(Google Docs Link)

P.S. Please check https://github.com/developit/htm. HTM is useful when you want to use React without any build tools or JSX. HTM template is a string too so maybe you’ll be able to leverage ResourceLoader just like the Vue template.

That sounds intriguing, but unfortunately, it uses template literals which are not available in IE 11. So since IE11 still considered a modern browser that gets the highest level of support from MediaWiki, we would still need a build step to ensure that all features are working there as well.

I leave it to others to respond to your main points.

Regarding

Developing a new component library in any framework will need to be done in a way that aligns with Wikimedia’s existing design system. Integrating any new tools we adopt into this system is a precondition to production usage and should commence as soon as possible.

I think this component library should strive to preserve the current strong points of OOUI—the powerful accessibility features and centralized theming that allows skin authors to easily apply a custom theme to user interface elements regardless of where they are used by creating a custom theme, to make it easier for features to conform to the same accessibility standards and simplify the work of skin authors.