Page MenuHomePhabricator

RFC: Adopt a modern JavaScript framework for use with MediaWiki
Closed, ResolvedPublic

Assigned To
None
Authored By
egardner
Dec 19 2019, 10:41 PM
Tokens
"Pterodactyl" token, awarded by Ash_Crow."Like" token, awarded by Peb."Orange Medal" token, awarded by Pablo-WMDE."Like" token, awarded by eranroz."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.

Description

Please note: Please refrain from adding late drive-by comments to this task as they are not helpful. Thanks.


  • Product owner(s): TBD.
  • Code steward: TBD.
  • Initial implementation: @egardner, @Catrope.

Motivation

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.

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.

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

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.EditedJan 23 2020, 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.EditedJan 24 2020, 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.Jan 24 2020, 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.EditedFeb 1 2020, 9:11 PM

Update (2020-02-27T03:53+0900): "Vue is Evan You's one-person project" → "Vue core is Evan You's one-person project"


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 core 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 core 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 core due to certain circumstances, MediaWiki will have to manage Vue core 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.

daniel added a subscriber: daniel.Feb 24 2020, 11:43 AM

Summary of the IRC meeting on #wikimedia-office on Feb 22, per https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-02-19-22.03.html

  • EricGardner made a demonstration extension that shows off these features: https://github.com/egardner/mediawiki-extensions-VueTest (KateChapman, 22:16:39)
  • <EricGardner> That extension repo also contains a lot of documentation that may be useful for folks getting started with Vue, and some additional config for linters, test runners, etc that I found useful (KateChapman, 22:16:51)
  • <EricGardner> Also, one important limitation of the approach Roan is describing is that JS still needs to be written in ES5 (KateChapman, 22:17:04)
  • <Nikerabbit> Are there other things besides ES6 that aren't supported yet, but maybe in the future? (KateChapman, 22:21:47)
  • https://vue-composition-api-rfc.netlify.com/ (milimetric, 22:24:47)
  • It is required for our scale and range (core/extensions, multiple orgs/teams, community gadgets) that the framework strictly follow a no-breaking-change rule other than removal of deprecated functionality after replacements are added in a previous release. (Krinkle, 22:43:28)

Full logs: https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-02-19-22.03.log.html

From skimming the logs, it seems that there are lots of details to be explored, but none of them block the RFC as proposed. Is that a fair summary?

22:43:28 <Krinkle> #info It is required for our scale and range (core/extensions, multiple orgs/teams, community gadgets) that the framework strictly follow a no-breaking-change rule other than removal of deprecated functionality after replacements are added in a previous release.

Vue 3 planned multiple major breaking changes: removal of the filter, change of v-model, removal of inline-template, removal of data object declaration, etc. Those APIs are not deprecated in Vue 2, and those APIs are user-facing API that mediawiki developers should directly call. You can check https://github.com/vuejs/rfcs/issues?q=label%3A%22breaking+change%22+is%3Amerged for further details.

Is this really OK for this RFC? For me Vue.js looks like doesn't meet this requirements, which possibly blocks the RFC.

Anomie removed a subscriber: Anomie.Feb 24 2020, 5:28 PM

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.

https://github.com/developit/htm does support IE11. Weather to use template literals or not is totally up to users. Since template literals is just another form of function call. You can call htm directly without template literals syntax. Check this out: https://github.com/simnalamburt/snippets/blob/b49265b1/html/htm-without-es6.html#L21-L42

Also you can always use https://babeljs.io/docs/en/babel-standalone in the browser too.

You can call htm directly without template literals syntax. Check this out: https://github.com/simnalamburt/snippets/blob/b49265b1/html/htm-without-es6.html#L21-L42

Snippet:

return html('\
  <ul>\
    ',list.map(function(e) { return html('<li>',e,'</li>') }),'\
  </ul>\
')

I can see the horror on the face of designers.
It's great that it's possible, but for the "benefit" of IE11, I wouldn't take that path of suffering.

Server-side transpiling / compiling a separate bundle for IE11 would be the approach I'm interested in.

EvanYou added a subscriber: EvanYou.EditedFeb 26 2020, 5:33 PM

Project lead of Vue.js here. Anything I say is obviously going to be biased, so take them with a grain of salt, but I'll try my best to reason with objective facts.

The main reason I'm posting is because @simnalamburt 's arguments above which seem to be heavily biased, unnecessarily hostile and intentionally misleading.

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

The Vue.js project is not just the core library. It's made up of the core lib, the supporting libraries (router, vuex), CLI, build tools, devtools extension, and the documentation. Me as the project lead is primarily focused on the core, while most of the supporting libraries are now fully maintained by team members. For example:

In comparison, projects like React is a monorepo that puts most of its official packages AND the documentation in a single repository. So comparing the contributor graphs of facebook/react and the Vue core repo will be highly misleading.

Bottom line: It is inaccurate and misleading to cite only the core repo trying to label it as a "one-person project".

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.

This brings up an interesting topic that has been discussed earlier in the thread: the sustainability of the project.

I have been working on Vue full time for over 4 years now. The user count (primarily based on Vue Devtools weekly active) has been growing at 1.7~2X year over year. The financial backing from sponsors have been growing at a similar pace (aside from myself, we now have two devs, https://github.com/posva and https://github.com/sodatea working full time on Vue related projects thanks to our sponsors on OpenCollective (https://opencollective.com/vuejs, a 501(c)(6) account hosted under the Open Source Collective)).

As you can see from my personal Patreon and our OpenCollective, the sponsor sources are very diverse and there is no single dominant backer. We have seen sponsors come and go, but the overall sponsorship amount has been consistently growing for years.

Bottom line: the project is financially very stable and bears minimal risk in sudden stoppage of development.

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

This is factually wrong. Every merged RFC has reached consensus inside the Vue core team - I'm just the one doing the actual merging. Most of the RFCs actually goes through an internal draft phase before they are made public, so technically the team consensus happens even before they are submitted as a pull request. If a core team member opposes an RFC, they also have all the rights to comment directly under that RFC thread and voice their opinions. Feel free to ask any of our core team members if that is true, but PLEASE do not spread misinformation as if they are facts.

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].

This was over 3 years ago. That is to say: we haven't shipped breaking changes in 3 years.

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.

We established the RFC process with the exact purpose to let our users know about them and provide feedback in advance. If you look at the dates, the first RFC with breaking change for v3 was proposed more than a year ago (https://github.com/vuejs/rfcs/pull/8).

These RFCs are not arbitrary: we only introduce breaking changes if we consider it a reasonable trade-off, and that our users agree with it. In every breaking change RFC, we carefully consider the implications of these changes and how much they would affect existing usage. Every RFC has a dedicated section discussing the adoption strategy on how we can provide a reasonable migration path - many of them will be supported with a compatibility build with deprecation warnings (this is what we did for the 1.x -> 2.x upgrade as well). We are doing all this exactly because we care about stability.

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.

I don't think the comparison justifies your conclusion that "React has been evolved in a more stable way". Objectively, you would have to make more code changes as a result of React "changing behavior" in the past 3 years compared to Vue (where you literally have to make 0 changes).

Another tangent point here: many in this thread have argued against the stability point in the original RFC citing how stable React core is, but missing the point that the RFC was referring to not just the core libs, but also "related tools and best practices". If we look at how the React state management solutions are moving from Flux -> Redux -> MobX -> Immer -> Hooks, how logic reuse are moving from mixins -> higher order components -> render props -> hooks, and how there are over 60 different CSS-in-JS solutions each claiming to be the best.

Personally, I think it is great that the React ecosystem has been continuously experimenting with new ideas, but I think it's also fair to say that "best practices" in the React ecosystem is a target that moves much faster than that in the Vue ecosystem.

It is also worth mentioning that Concurrent Mode, which is arguably the biggest feature that the React team has been working on for over 3 years, requires users to write React code in a "concurrent-safe way" - i.e. staying away from mutable state, and following a number of rules that contradicts with common patterns seen in pre-concurrent-mode usage. The design of React Hooks is a result of trying to introduce a concurrent-friendly API to replace classes, however in trying to stay concurrent-safe, Hooks introduces a whole new category of usability issues, e.g. the need to manually list dependencies to invalidate stale closures, and the need to manually memoize callbacks with useMemo to prevent unnecessary re-renders. Full-on concurrent mode, once enabled, also makes your app non-compatible with a large part of the existing ecosystem because many libraries are not "concurrent-safe". Code written with Hooks and Concurrent mode enabled will look drastically different form React code that was written 3 years ago.

That said - I think the React team is doing a great job at shipping such drastic paradigm shifts in a backwards compatible fashion, but claiming that React is more stable than Vue just doesn't make sense.

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.

Again, sounds like baseless accusations to me. Hopefully the RFC process section above has already addressed this point.

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.

It is true that Vue 2.x has been in maintenance mode for a year. This is because we have been focusing on making major improvements to the framework in v3, which comes with a ton of fundamental improvements and new features. Also, the Composition API has already been made available for 2.x as a plugin during this period.

And Vue 3 has been in preview for 2 years.

Factually incorrect: We first announced the plan to work on Vue 3 in September 2018 (https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf). Vue 3 has been in alpha stage since Jan 3rd (https://github.com/vuejs/vue-next/releases/tag/v3.0.0-alpha.0) with most of the planned improvements and new features completed and we are set for beta in the coming months.

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.

Do realize that the development of frameworks is not a race about who moves faster. Designing and shipping major new features is a lengthy process and each team will do it at different paces and timings. Picking an arbitrary time frame and comparing the number of new features shipped most likely leads to skewed conclusions.

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.

Community size has marginal returns once it grows beyond a certain threshold. With over 1 million active users worldwide, I personally believe the Vue community is "big enough" to provide anything the React community can provide.

In terms of contributors, the entry of barrier could play an important role too. I would imagine that not all potential contributors to MediaWiki are JavaScript veterans who already know how React works, but it should be fairly easy to grasp HTML templates.

A separate comment regarding shipping the runtime compiler:

  • The runtime-only build of Vue is ~23kb gzipped, and ~33kb with the compiler. The compiler itself is only 10kb gzipped extra payload. In fact, we consciously design our compiler to minimize its size because its potential usage in the browser.
    • In comparison, to compile JSX at runtime, it requires the entire Babel runtime which is not optimized for payload size at all.
  • Typically, compiling a decently sized template takes around a few milliseconds on an average laptop (depends on template size, obviously). The cost of runtime compilation will be well within reasonable range if the use case is embedding a few interactive widgets on a page with largely pre-rendered content. That said, I would recommend benchmarking the cost of runtime compilation in prototypes or smaller scale scenarios to properly gauge whether the cost is something acceptable for the intended use cases.

Thank you for the excellent detailed reply, @EvanYou. This is a great summary of the points, and gives a good perspective to this RFC and the entire modernization endeavor in general.

I would also make the point that historically, the Wikimedia movement has been very active in contributing upstream to whatever libraries we've been using. Our use cases tend to expose some unique behaviors and we can then help make the solutions and supporting libraries more robust. We've been doing that consistently with other libraries over the years, whether it is with patches and fixes to the existing code or with supporting libraries around it.

Having an environment that supports and encourages such collaboration in general is another plus to consider.

simnalamburt added a comment.EditedFeb 26 2020, 11:12 PM

Hi @EvanYou I'm actually grateful to see you here! Since the framework authors rarely participate in discussions on which framework to use.

First of all, I'm sorry to hear that my comment felt aggressive. I want to tell you that my comments are not about "Vue/React is better than the other" or personally attack you or Vue project. It's about which framework better meets MediaWiki's needs. After reading you comments, I realized that some parts of my comments were misleading and some parts of my comments were even based on misunderstanding but I'd like to tell you that none of them was intentional. I'll try not to sound hostile in this time with my limited English skill.

 

About the bus factor

Yes I knew and I actually mentioned that Vue.js project have a team which maintains multiple supporting libraries, and there's nothing wrong with you focusing on Vue core. Looks like it was not a wise word choice to tell Vue core as "actual Vue project" (sorry for my English). But I think the fact that the Vue core is managed by one person is worth mentioning in the RFC's review process. There were several people who already mentioned this point in this RFC. This issue is what people actually care.

As far as I know, React core and ReactDOM is maintained by four people: Dan Abramov, Brian Vaughn, Andrew Clark, and Sebastian Markbage. They are not the founders of React, and React source code has been handed over by several developers over time. And this history is a strong credit for React's sustainability. Since you can trust that development will be continued even if some developers are forced to stop the contribution due to developers' circumstances.

I know Vue.js is financially stable and actually that's very grateful thing! But I think it's still a risk that Vue core is being developed by one developer. If https://github.com/posva or https://github.com/sodatea or anyone else are planned to participate in the development of Vue core, I will withdraw this statement. But in the current state, the bus factor of the Vue core seems to be one.

Yes it's Vue core not entire Vue. But still, bus factor 1 for Vue core sounds dangerous for MediaWiki.

About the RFC process

Sorry for the misunderstanding. I've been watching the Vue.js RFC, and I found that the person from Vue team who comments/merges/closes the RFCs was mostly by you, so I thought you were the decision maker. Even some RFCs were created by the Vue team people and closed by the Vue team people, so I couldn't imagine the discussions taking place outside of the GitHub Issue Tracker. Are there public channels or places where Vue team people discuss these RFCs? If so, there will be no more person like me who thinks Vue's decisions are not transparent or unpredictable.

About the breaking changes

I agree that those breaking changes introduced in Vue 2 and planned for Vue 3 is reasonable and necessary. And actually there's nothing wrong with it. As a programmer I'm actually a big fan of breaking APIs for progression, and I've never personally complained about it. But because MediaWiki is a project that takes backward compatibility seriously, I think it worth mentioning in the review of this RFC.

Vue.js indeed didn't shipped breaking changes or changing behavior in last 3 years is because Vue.js 2.0.0 was released at 2016-10-01. React didn't shipped breaking changes or changing behavior in last 2 years too, since React 16.0.0 was released at 2017-09-26. What we need to compare is how it was to migrate Vue 1.x → 2.x → 3.x and React 0.14 → 15 → 16 → 17.

  • Was removed or changed API of future release were deprecated, or marked as unstable beforehand?
  • How much code modification is required for the migration process?
  • How much code will be affected by the change?

https://reactjs.org/blog/2016/04/07/react-v15.html#breaking-changes This is React 0.14 → 15 migration document. All removed APIs were deprecated in 0.14. There is 3 behavioral changes and only 2 of them impacts applications. The first one required small amount of code change at least in Facebook, and the second one is actually bugfix.

https://reactjs.org/blog/2017/09/26/react-v16.0.html#breaking-changes This is React 15 → 16 migration document. All removed APIs were depreacted in 15, and those removed APIs are still supported as separate packages without performance overhead, so React component modification were not required. Only import ... from ... codes needed changes and automatic migration tool (codemon) for that was provided. Behavioral changes are actually change of unsupported behavior and bugfixes like "Now componentWillMount hooks will be called in deterministic order".

There's no list of planned breaking changes for React 17 but we can talk about React Concurrent Mode. If users want to use Concurrent Mode users need to rewrite codes in concurrent-safe way. If users can't afford the migration costs, then Blocking Mode will be suffice since it does not require such code overhaul.

https://vuejs.org/v2/guide/migration.html This is Vue 1.x → 2.x migration document. There're quite many breaking changes and, AFAIK most APIs were not deprecated or marked as unstable beforehand. Many of them requires code modification but thankfully there is migration helper. Most changes were made to daily APIs so most users were affected.

https://github.com/vuejs/rfcs/issues?q=label%3A"breaking+change"+is%3Amerged This is planned Vue 2.x → 3.x breaking changes. AFAIK most APIs are not deprecated or marked as unstable in Vue 2.x yet, but this can be changed in future Vue 2.x releases. It is good to see that total number of breaking changes itself is much smaller than 1.x → 2.x, but still many of them requires code midification. I heard that Vue team is going to release a compatibility builds which provides backward compatibility with a cost of performance impact.

Overall, the React team always had deprecation process before API changes, and always stressed that "only a small number of codes should be affected" even if code modification is needed. There was a case where an deprecated API used by a large number of code was deleted, but that API is still supported by seperate packages so didn't need to update React component codes.

Vue does not seem to have a deprecation process yet. Instead, Vue provides migration helper which tells you how to change your codes and compatibility build with a runtime cost.

Evaluating these facts, I think React preserves API stability better than Vue. And I do not think this comparison is heavily biased. MediaWiki is a project that takes backward compatibility very seriously, and we need to think about whether Vue meets the following criteria:

22:43:28 <Krinkle> #info It is required for our scale and range (core/extensions, multiple orgs/teams, community gadgets) that the framework strictly follow a no-breaking-change rule other than removal of deprecated functionality after replacements are added in a previous release.

About moving library trend and new ways to write components.

Library trend doesn't define best practices. Redux still works in production without issue and MobX too. Actually those libraries are different thing that each have its pros and cons. In 2020 many people writes functional component with hooks but still the other many people write codes in class component with redux and there's nothing wrong about it. There is a phrase that Dan Abramov always repeats on the Internet: You don't need to rewrite your codes in <something new>.

React always maintained API stability for those "old fassioned" codes and this value perfectly aligns with MediaWiki's needs.

About the pace of development

I think it is undeniable that React led the introduction and development of various paradigms in stable and fast way. React is suitable for projects that need to evolve for a long time, such as MediaWIki, because it actively introduces a new paradigm and at the same time reliably introduces APIs. The reason that I selected a certain time frame is to compare two frameworks in objective way. If you think my conclusion is distorted, I wonder what your opinion is.

About the community size

Honestly I can't predict how the size of the community will affect MediaWiki. But I think that having a larger community will at least not adversely affect MediaWiki.

 

In summary, I still thinks React will be more conducive to MediaWiki's sustainability. If you think differently, comments are always welcome. Just please execuse my extremely slow English writing.

Please note that I'm not the one who claims to not use Vue at all. As mentioned above, I even used Vue voluntarily in my day job and that project is still maintained. Not to blame you or your project, but to determine which project would be a better fit for MediaWiki, I hope we can have a nice and enjoyable discussion. :)

P.S.

To be honest, the another reason that I'm glad to see @EvanYou here is because he is the first person who reacted with my main points. I've read the IRC meeting logs of #wikimedia-office on Feb 22, and no one reacted to my comments. It seems like the decision to use Vue.js has already been made.

Comments such as "why not React" would really have to show why our current implementation path won't work at all

No implementation path won't work at all. Even continue using jQuery and OOjs will somehow work. I just tried to sort out the pros and cons of what I know, since this is RFC(Request For Comments).

If FAWG decided to take these shortcomings and just move on, please let me know. Or if FAWG have already developed too much with Vue.js and can't get it back, please let me know. If FAWG decided to use Vue.js as MediaWiki developers' personal preference, please let me know. MediaWiki is an open source project, but in the end most of the work is done by the developers of MediaWiki, and I think it's better to follow it if there is a clear preference from the developers of MediaWiki. If for some reason you've already decided to use Vue.js, I won't comment anymore. I'm a third party with little contribution to MediaWiki anyway.

Demian added a comment.EditedFeb 27 2020, 1:26 AM

Hello, @EvanYou!

Thank you for your detailed response from which we learned a lot. Please forgive us, if any of the opinions in this discussion were inappropriate or incorrect, I assume that was not the intention, even if these are very direct and opinionated.

Please note that both simnalamburt and myself are volunteers / users of this project. Our opinions are personal, even if it might sound as representing more than that.

But I think the fact that the Vue core is managed by one person is worth mentioning in the RFC's review process. There were several people who already mentioned this point in this RFC. This issue is what people actually care.

Please do not generalize based on your opinion and another one or two person's similar focus. While I do care about this as a fact, it is not an issue in my opinion. I understand how such an implication can be perceived as hostile. It is clear that there's a healthy community around Vue and quite a few developers who are able to continue core development if the need arises. The core being maintained by one specific person is more of a management question, rather than an issue as you suggest.

Yes it's Vue core not entire Vue. But still, bus factor 1 for Vue core sounds dangerous for MediaWiki.

As detailed above, not at all, imho. A note on the fine details of the English language: using a less dramatic word like "perceived risk" is more factual and might be more welcome. Every engineering decision is a balance between risks and benefits. Imho this "risk" is mostly speculative and far outweighed by the benefits of progressive adaptability and friendliness towards non-developers in Vue.

[...] But because MediaWiki is a project that takes backward compatibility seriously, I think it worth mentioning in the review of this RFC.

That's only true in certain cases. Generally, MediaWiki operators had great difficulties migrating from certain versions in the past. In fact, there's much more effort and thought invested into the migration aspect of Vue than MediaWiki. While the basic approach in MediaWiki is to not change things, but instead carry the technical debt, Vue has a well thought-out process to facilitate changes and migration. There are a few lessons there that we could learn to clean up MW's code-base, thereby reducing the size of the big JS bundles (300+ KiB compressed) sent to clients.

I stepped away from this discussion for a moment, but I wanted to say thanks to everyone for all the thoughtful contributions. And a special thanks to @EvanYou for engaging with us here, it's really great to have his perspective as the creator of the framework under discussion! Thanks for sharing some information about how the Vue team is managing the introduction of new features and project sustainability.

I also appreciate all the thoughtful comments in favor of alternative approaches like React. I think @simnalamburt has done a good job articulating React's strong points. Everything that's been shared in the course of this RFC discussion will help to inform what the Foundation does as we try to figure out how to modernize the front-end of a 15+-year-old tech stack that serves billions of people.

Personally, I still think that Vue is a better fit for WMF for a couple of reasons, a few of which Evan just mentioned upthread.

Stability: I've used Vue since version 0.12, and the single biggest breaking change I experienced was the removal of the filter option. It was pretty straightforward to migrate the same functionality to methods and/or computed properties. New features have been added but the core APIs have remained very stable. And, equally important in my mind, the community-defined best-practices have also remained pretty stable. I thought Evan expressed this very succinctly:

Another tangent point here: many in this thread have argued against the stability point in the original RFC citing how stable React core is, but missing the point that the RFC was referring to not just the core libs, but also "related tools and best practices". If we look at how the React state management solutions are moving from Flux -> Redux -> MobX -> Immer -> Hooks, how logic reuse are moving from mixins -> higher order components -> render props -> hooks, and how there are over 60 different CSS-in-JS solutions each claiming to be the best.

I think the Vue community has figured out how to continue evolving without embracing this level of fragmentation – but unlike Ember (which espouses a similar approach), there is still a lot of flexibility in how the tools are used. I think this is a good fit for MediaWiki. We don't need to live on the bleeding edge as long as we aren't stagnating. I don't even think Vue is "behind" React, there are just different priorities.

Compatibility: The other big point in favor of Vue in my opinion is its emphasis on backwards compatibility. We still provide first-class support for IE 11. We also don't have a standard process for compiling or transpiling front-end code in place yet. We are still unable to use "ES2015" features in 2020. Using React without Babel and JSX seems like a huge headache (I appreciate @simnalamburt's mention of HTM, but that library still relies on template literals, which we can't use in IE). It is possible to use React outside of a modern JS environment, but I'd say that Vue provides much better support. Our initial experiments in modifying our PHP-based front-end module system to support Vue single-file components (with JS code in ES5 of course) have been very promising. I think Vue and React offer very similar benefits (reactivity, component-based APIs, state management, more test-able front-end code, performance, etc.), but the migration path for using Vue looks much easier from where we currently stand. The fact that Vue provides a template compiler optimized for in-browser usage is a big part of this; to my knowledge Vue is unique in this respect.

These are my personal views, but I think they are shared by many members of the FAWG (where we discussed some of these topics at length). Wikimedia Deutschland (our sister org, which is behind the Wikidata project) also decided to start using Vue a few years back and it seems to have worked out well for them. But we'll continue to evaluate these decisions as we move forward with experiments and pilot projects.

Milimetric added a comment.EditedFeb 27 2020, 4:52 AM

Thank you @EvanYou, your answer was enlightening. To dig a bit more into the compatibility builds you mentioned here:

Every RFC has a dedicated section discussing the adoption strategy on how we can provide a reasonable migration path - many of them will be supported with a compatibility build with deprecation warnings (this is what we did for the 1.x -> 2.x upgrade as well).

I'm not at all comparing, but we were put in a tough situation in the past when jQuery UI didn't follow this particular semver practice: https://semver.org/#how-should-i-handle-deprecating-functionality. It sounds like Vue does follow this with compatibility builds, but you say "many of them" instead of "all". In our ecosystem we support user-written gadgets and scripts, and it's not scalable to migrate all of them without a compatibility build. For the 2 -> 3 migration, we think we can manage because we're just starting to adopt Vue and we have more control. But going forward, do you think it's possible for Vue to adopt the semver deprecation policy more absolutely?

@Demian Thank you! You're the second person who discussed about my main points! Comments are always welcomed!

About the bus factor

I also don't care about the Bus Factor when I do my personal projects. I've been always a big fan of "Let's take a risk and move forward". But is this OK too for WikiMedia? Don't WikiMedia developers care about Bus factors either like me? But I think it worths a discussion.

I've seen many cases[1][2][3] talking about bus factors in WikiMedia discussion. Argo CI has even been rated as having a bad bus factor because it was two people.[4] You said that saying "people do care about bus factors" is a generalization but it seem like people actually care about the bus factor to me.

[1]: https://www.mail-archive.com/wikidata-l@lists.wikimedia.org/msg05410.html
[2]: https://phabricator.wikimedia.org/T28#1081799
[3]: https://phabricator.wikimedia.org/T221112
[4]: https://www.mediawiki.org/w/index.php?title=Wikimedia_Release_Engineering_Team/CI_Evaluation_Cabal/2019-09-17&oldid=3611926

Of course, we can always choose to take risks. To do so, let's just discuss about this risk and make a decision. I don't know if I missed it, but so far it doesn't seem that the RFC has been modified to take this risk, or that a member of the FAWG has said to take this risk. Please feel free to say "we can take that and let's move forward"! Let's have some discussion and get some consensus.

About the breaking changes

I think this is the exactly the certain case that MediaWiki takes compatibility seriously. Since the framework choosed in this RFC will not only used inside MediaWiki but also shared accross whole MediaWiki frontend community like extensions, gadgets, user scripts, etc. I have seen oojs being careful to even update jQuery to avoid breaking changes, and have seen oojs-ui do deprecation before breaking changes. But as I said Vue does not have a deprecation process and I'm concerned about this.

If a deprecation process is added to Vue in the future, this claim will be withdrawn. At present, however, WikiMedia seems to have to give up its requirements that "strictly follow a no-breaking-change rule other than removal of deprecated functionality after replacements are added in a previous release".

 

@egardner Thanks for the comments and I agree that the migration of Vue is not so painful. I'm just saying that migration of React is easier because it have deprecation process and doesn't require component code modifications in many cases.

As I mentioned in https://phabricator.wikimedia.org/T241180#5921939, the library trend is not best practice. Just as WikiMedia doesn't have to use React just because people use React the most, people don't have to use Redux just because they use Redux the most, and not rewrite all the code because trend has changed.

There is a phrase that Dan Abramov always repeats on the Internet: You don't need to rewrite your codes in <something new>.

These library choices are not fragmantation. You can use class component and hooks in a same project and it's nothing wrong. You can use css modules and css-in-js in a same project and there's no issue with this. Sticking with old libraries are not stagnation. The "facebook.com" still containes thousands of components written in "createClass" and it works perfectly without issue, nicely interoping with new libraries or new components. I think this is a great advantage for projects like MediaWiki which have large user-written extentions and gadgets.

About using it without bundler

When I first read the RFC, I thought WikiMedia planned to put bundler or build steps in some form in the future. As I read it again, looks like there's no specific plan for now. It may even be possible to avoid building steps at all. I thought this is not a big deal since I thought that WikiMedia will have build steps in the future. But if not, I agree with you that this is seriouse developer experience issue.

From the TechCom discussion yesterday, and the discussion here, adaption of Vue seems to be blocked on commitment to a deprecation policy as outlined in https://semver.org/#how-should-i-handle-deprecating-functionality. Breaking changes without deprecation are not something we can handle, even if the necessary migration would be trivial. We just don't have the necessary level of control to "stop the world" and migrate.

Is this a fair summary? Are there any other critical points?

PS: An updated version of MediaWiki's own deprecation policy went on last call yesterday, see T193613: RFC: Establish stable interface policy for PHP code.

@daniel I think there should probably be some clarification regarding Vue's deprecation and versioning policies.

  1. Vue sticks to semver and only ships breaking changes in major releases. This means as long as the user uses a proper semver range (e.g. ^2.6.0) with their package manager, they will never encounter unexpected breakage.
  1. Vue introduces major version bumps at a much lower frequency compared to React or Angular, and it is our intention to stay on a major version as long as possible. So instead of deprecating and removing features once every several months, we tend to provide a relatively longer stable cycle (v2 -> v3 is 3 years) and group deprecations and feature removals around these major releases.
  1. We have only done one major version bump (v1 -> v2) so far, and we have learned a lot over the three years about what can be improved about this process. This is why we announced v3 way ahead of time and introduced the RFC process to give the community ample time to prepare for the changes and even participate in the design process. Deprecation notices in a minor version before the next major is definitely something we can and should adopt.
  1. For the v3 migration, this is the currently planned procedures:
    1. v2.7 will be released with deprecation warnings for features that are set for removal. This release will also become an LTS version with 18 months of extended support time.
    2. v3 will come with a "compatibility build" that exposes v2 behavior (where applicable) via feature flags and provide deprecation warnings / migration guidance when v2 usage is detected. v2 compat feature flags that can be turned off individually so the migration can be performed piecemeal.
    3. Codemods will be provided for simple API syntax changes that can be automatically upgraded.
    4. A migration helper will scan the codebase and provide guidance for any changes that cannot be covered by the compatibility build or codemods (we try our best to avoid such changes, but sometimes they are inevitable).

Hope this addresses the stability concerns.

  1. For the v3 migration, this is the currently planned procedures:
    1. v2.7 will be released with deprecation warnings for features that are set for removal. This release will also become an LTS version with 18 months of extended support time.
    2. v3 will come with a "compatibility build" that exposes v2 behavior (where applicable) via feature flags and provide deprecation warnings / migration guidance when v2 usage is detected. v2 compat feature flags that can be turned off individually so the migration can be performed piecemeal.
    3. Codemods will be provided for simple API syntax changes that can be automatically upgraded.
    4. A migration helper will scan the codebase and provide guidance for any changes that cannot be covered by the compatibility build or codemods (we try our best to avoid such changes, but sometimes they are inevitable).

Hope this addresses the stability concerns.

I think the key issue here is the completeness of the compatibility build. The MediaWiki ecosystem involves MW core, many extensions (which are separate git repos), and gadgets and user scripts that are written by our users on wiki pages. This means that, in @daniel's words, we can't easily "stop the world" and migrate everything at once to deal with a breaking change. If there are breaking changes in Vue 3, then as soon as we upgrade the version of Vue that MW core uses from 2.6 (or 2.7) to 3.0, extensions that use features that are no longer supported will immediately break. But we also can't update that code in the extensions first, if doing so requires features that are only available in 3.0. With a somewhat annoying amount of effort, we could land all the migration changes in rapid succession and only have a broken master branch (and CI system) for an hour or so, then deploy all those changes at once. But for code that lives on-wiki, we can't do that: deploying Vue 3 before migrating that code would break, and migrating it before Vue is deployed would also break. It's (kind of) OK to break our development environment for an hour, but it's much less OK to break things on production wikis.

If the v3 compat build you mention provides full compatibility, such that all code written for v2 works with it and all code written for v3 does too, that would put us in a much better situation, where we can migrate more gradually. If it provides compatibility for most things, then maybe a smooth migration is still doable depending on what the missing features are (maybe they're rarely used and/or have good alternatives that we could pre-migrate them to). I don't know if you're far along enough to be able to shed some light on what level of compatibility you expect to be able to provide, but when you do have that information, it would be very helpful to have. It'll be the key factor determining how smooth or how rocky our migration path will be.

Having said all that, I should add two caveats. First, as @Milimetric said, we think we'll be able handle breaking changes a lot better for the Vue 2->3 migration, because we don't expect to have very much code to migrate yet by then. I also don't expect we'll have any on-wiki code using Vue at that point (or if we do, it'll be very little), because that requires some additional infrastructure that we haven't built yet. That means that the problems that an not-quite-fully-compatible compatibility build would cause would be much more manageable, and we're OK dealing with those. For Vue 3->4 and future migrations, a smooth migration path will be much more important. Second, a trivial migration path would be to expose both Vue2 and Vue3 as separate modules and let each piece of code load the version it needs, until everything is migrated (assuming that Vue2 and Vue3 instances can coexist on the same page). This would be challenging for shared components, and it certainly wouldn't be ideal from a performance perspective (I joked at a meeting this week that "nothing would break... except for my neck when the Performance Team sneaks into my apartment and murders me in my sleep"), but it could be an escape valve for isolated code that's especially difficult to migrate for whatever reason.

There seems to be an assumption made in a number of comments that while OOUI and other component libraries will stick around in the "short term", that in the medium term we would like to move away from using them. While for smaller apps, gadgets, special pages etc. that use a handful of buttons and textboxes, this is probably feasible, VisualEditor is tightly interwoven with OOUI to the point where we'd probably have to rewrite 30-50% of the codebase. Such a project would take years of developer time and cost the Foundation millions.

This doesn't mean we shouldn't look to introduce better ways to do things like this, the OOUI codebase is flawed and getting old, and no doubt something we write from scratch now will probably be better, but we need to be honest with ourselves about the technical debt we are incurring. If we don't have a plan to somehow integrate Vue & OOUI, we are committing to maintaining both as we certainly don't have the resources to ever fully drop OOUI.

I think mentioning two points are necessary here.
First, regarding breaking changes, I have been maintaining several gadgets in my home wiki at my volunteer capacity, the biggest reason I have been so reluctant to update my gadgets to OOUI (not to mention keeping it up-to-date with its breaking changes) is that it's really hard to comprehend and has a pretty steep learning curve, specially for a volunteer who has a pretty limited time. Not to mention other volunteers who are not professional programmers would have harder time. Having a modern and easy to understand framework would make it easier for volunteers to maintain their gadgets with breaking changes.

Breaking changes are a challenge for the new framework being adapted and definitely currently a problem in our ecosystem but I feel a modern one addresses the issue, at least to some degree, rather than making it worse.

There seems to be an assumption made in a number of comments that while OOUI and other component libraries will stick around in the "short term", that in the medium term we would like to move away from using them. While for smaller apps, gadgets, special pages etc. that use a handful of buttons and textboxes, this is probably feasible, VisualEditor is tightly interwoven with OOUI to the point where we'd probably have to rewrite 30-50% of the codebase. Such a project would take years of developer time and cost the Foundation millions.

This doesn't mean we shouldn't look to introduce better ways to do things like this, the OOUI codebase is flawed and getting old, and no doubt something we write from scratch now will probably be better, but we need to be honest with ourselves about the technical debt we are incurring. If we don't have a plan to somehow integrate Vue & OOUI, we are committing to maintaining both as we certainly don't have the resources to ever fully drop OOUI.

Second, Your point is true, there will cost with adapting a new framework, specially for VE. I'm not disputing that but, and this is my feeling and I might be very wrong here please point out, I feel WMF doesn't spend much engineering resources on frontend as other user-facing tech organizations (of course, for example Apache foundation doesn't need that much frontend resources). This should change and this RFC, assuming it will be approved, can serve as justification for improving the situation.

Second, Your point is true, there will cost with adapting a new framework, specially for VE. I'm not disputing that but, and this is my feeling and I might be very wrong here please point out, I feel WMF doesn't spend much engineering resources on frontend as other user-facing tech organizations (of course, for example Apache foundation doesn't need that much frontend resources). This should change and this RFC, assuming it will be approved, can serve as justification for improving the situation.

I agree that this would be the ideal outcome, but we have to be realistic about our resourcing, and in the absence of real commitments to them changing drastically, be aware of the tech debt we are incurring.

My concern is that there is already a momentum around deploying Vue and it is even being used for new projects, but we haven't either (a) committed to that change in resourcing or (b) had a serious discussion around maintaining Vue & OOUI separately.

DLynch added a subscriber: DLynch.Mar 4 2020, 4:10 PM

Per today's meeting of TechCom, this RFC is going on Last Call. If not concerns remain unaddressed by March 18, this RFC will be accepted as proposed.

TechCom considers all concerns raised so far in the discussion above to be sufficiently resolved. To specifically address the concern I raised last week, it now appears that we can be confident that sufficient compatibility mechanisms will be in place to allow for a smooth migration away from any deprecated features.

As to the question of maintaining or migrating OOUI: as far as I know, this has been part of the original discussions within the FAWG sub-group that evaluated vue.js. @kchapman can provide more information on resourcing of this effort.

Krinkle updated the task description. (Show Details)Mar 4 2020, 7:23 PM
MaxSem added a subscriber: MaxSem.Mar 6 2020, 9:24 PM

TechCom approves this RFC with the understanding that a component library needs to be developed so use of Vue.js happens in a coordinated and reusable way. A migration path from OOUI needs to be included in this planning.

The Desktop Refresh search box pilot is exempt from this.

Pablo-WMDE awarded a token.
Peb awarded a token.Mar 19 2020, 9:06 AM
enjikaka added a subscriber: enjikaka.EditedMar 19 2020, 12:30 PM

Vue.js and React are already deprecated. Web Components is the standard approach from W3C. I think it makes perfect sense for WikiMedia to use standards over proprietary frameworks that are on their death row. Anything Vue and React can do, you can also do with web components.

Web Components also does not require build steps as they run natively on the web. That is a huge pro for both development and the end user consuming the product. Not having a build step is also a great way to ease the road to using ES modules in production.

There are several libraries to help with the creation and usage of Web Component too, to make them closer API wise to Vue and React. Lit-Element is a popular solution: https://lit-element.polymer-project.org

I also see the discussion on costs above. Rewriting everything to a JS framework is signing up for another rewrite in 5 years. Web Components is standardized and won't have to be refactored in coming years. Also important to note that Web Components can run inside Vue for example. This is also true for framework X launching in 2028. If the frameworks supports HTML/DOM, it supports Web Components. The point being, the Foundation would save A LOT of money writing as much as possible in web components as early as possible. It's future proof. Vue, React or what have you can be used to orchestrate the web components into pages and/or bridge with the state machine and VDOM if such a layer is desireable.

ddevault added a subscriber: ddevault.EditedMar 19 2020, 1:01 PM

I apologise in advance for the drive-by commentary, but I was reading through this thread and I found it pretty disturbing.

This proposal reads to me like you went into it already wanting to use Vue.js, then went through whatever mental gymnastics were necessary to retroactively justify that call. A better rationale would have started with "these are our pain points, and this is our evaluation of how these options address our problems." Things like this are less effective:

Better support for usage without Webpack/Babel/front-end build tools
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.

Non-trivial changes, like rewriting frontend components with Vue? A build step for software has been commonplace since well before Wikimedia even existed, the idea of introducing one is non-controversial and should have been evaluated in its own right for benefits like offloading complexity to compile-time rather than run-time.

There's also little analysis here of the user-impact - this proposal is entirely focused on the developer experience. A project like Wikimedia has a userbase of "everyone", which means that making technology decisions that eschew even 1% of users would be taking tens of millions of people out of the equation. Techniques essential to all of these libraries, such as shadow DOM, are still unsupported by older browsers which collectively still represent ~5% of market share. And even on modern browsers, websites designed with these tools require more compute resources to display, making it more cumbersome or even impossible to use on low-end or older hardware. This proposal considers the performance of these libraries, but only relative to one another - not to the baseline. None of this was quantified, either, we're just given conclusions.

I would recommend that you reconsider your approach.

If anyone’s wondering where all these drive-by comments are coming from: we’re apparently making the rounds on Hacker News. Yay.

Folks: please understand that you’re extremely late to the party. We’ve been discussing this for months, and that’s not including all the work of the Frontend Architecture Working Group that led to this RFC in the first place. There’s been a “last call” period for anyone to raise concerns, and nothing new was brought up during those two weeks. I don’t think this means that commenting on this task is now completely forbidden (though I frankly don’t know what could come out of it, since I’m not aware of any process existing to reopen an RFC). But I think I can speak speak for many of us when I say that blanket statements such as “Vue and React … are on their death row” are not going to be met with an abundance of patience at this point.

@ddevault none of the solutions discussed in this thread relies on Shadow DOM.

Ah, that's right. I had forgotten there was a difference.

Aklapper updated the task description. (Show Details)Mar 19 2020, 2:30 PM
tanguy_k added a subscriber: tanguy_k.EditedMar 19 2020, 3:35 PM

I did a deep popularity comparison of React, Vue and Angular here: https://gist.github.com/tkrotoff/b1caa4c3a185629299ec234d2314e190

The bottom line is that React is by far the most popular frontend framework (and continues to grow faster), except for the GitHub stars.
In addition, React is more loved and "wanted" than other front-end frameworks (although it is more used: satisfaction tends to decrease with popularity).

React is way easier to support in long term, than Vue and Angular. Long-term support is the most important feature specific only to React

As written above in big letters, please refrain from adding late drive-by comments to this task as they are not helpful. Please do read. Thanks.

Jdforrester-WMF closed this task as Resolved.Mar 24 2020, 7:30 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

The RfC is resolved. The work continues.