Foreword: The topic of integrating a new JavaScript framework in WordPress has proven to be both lively and contentious. The summary that follows is a best effort at an objective and accurate recap, but you are encouraged to review the original Slack transcript for the complete unaltered context (Slack registration required).

Below is a summary of the discussion from today’s JavaScript chat (agenda, Slack transcript, last week’s summary):

Introduction

• The conversation that followed from last week has taken heavy aim at considering only React and Vue as candidates. Have we been certain to exhaust all other options?
• Backbone features will continue to be maintained in core for the foreseeable future
• The decision to be made is one affecting new features to be built
• Developers will still have flexibility in choosing their preferred tools for themes and plugins
• We need to know what we’re building in order to make sound technical decisions. This year’s focuses can serve as a start: the post editor (Gutenberg), Customizer expansion in moving toward theme building functionality, and REST API-based reimplementations of existing features (examples including Quick Draft, post listing)

Alternative Suggestions

• Deciding on React as the framework of choice in WordPress.com Calypso was the result of prototype implementations of various frameworks (at the time, 3+ years ago) and judging the success of each.
• Preact could serve as a stand-in for a React-like paradigm if we consider ourselves blocked by React’s patent grant or ideological differences between Facebook the company and WordPress the project.

Contrasting Candidates for Consideration

The bulk of the conversation considered the merits of React and Vue only, largely contrasted on the basis of developer onboarding, ideological alignment between WordPress and for-profit companies, and the extent to which each sets the foundation for successful future maintenance of the features we seek to implement.

• Vue in practice: There have been no examples surfaced for projects relating to WordPress and the sorts of features we want to build (examples welcome in comments).
• Ideological implications: We should consider what it means to align WordPress with any particular framework. There’s a worry that the values of Facebook as a company are at odds with those of WordPress.
• Concerns about React: its learning curve and licensing (specifically, a termination clause included in its patent grant)
• React is a pattern as much as it is a library, as evidenced by proliferation of compatible libraries like Preact, Inferno, Rax, and others.
  • Patterns emphasizing declarative rendering, one-way data flow, and embracing JavaScript the language. WordPress has historically stayed true to the fundamentals of the languages, largely foregoing template languages or other domain-specific languages in PHP.
• Embracing JavaScript the language
  • Building rich applications is not comparable to history of applying JavaScript minimally in small interactions. Modern JavaScript is necessarily more involved to learn than a library like jQuery because we are building more complex functionality.
  • Are we really setting a foundation for developers to succeed into the future if we obscure the language with a template language like Vue’s (logic example)? Are we being inviting to new developers who began programming using JavaScript, or providing skill-learning opportunities that are broadly applicable?
  • Vue offers render functions similar to React, but their existence could undermine the perception of Vue being simpler if we’re acknowledging that the limits of the framework necessitate additional paradigms encompassing the entirety of React. Or is the argument of React’s complexity something else?
• Conversely, there is a strong sentiment that Vue has a much friendlier developer onboarding experience. WordPress has prospered by its approachability, and our patterns in JavaScript should reflect this too. Vue’s documentation is undeniably superb.
  • Regardless of any framework decision, making educational resources available will be important
• The role of corporate backing: Is Facebook’s investment in React a benefit in its supporting longevity of the project, or would it hold us hostage to the whim of their decision-making?
  • Vue is largely maintained by a single contributor (related: bus factor) funded via Patreon to work full-time on the project
  • It is not in Facebook’s interest to make large backwards-incompatible changes, because they too would suffer in their maintenance of hundreds of thousands of components across their products
• On the complexity of React: is this more accurately attributed to supporting tooling? Specifically build tools like Webpack, and patterns for state management like Redux. For better or worse, React is largely unopinionated on architecture not affecting view rendering.
  • Would we need similar tooling for Vue? Both Vue and React offer no-tooling-required options, but both also push developers toward a build process (single file components for Vue, JSX for React)
  • Is build configuration something that we’d expose to developers anyways? Maybe not for the configuration itself, but a build process generally limits ability to directly modify files on a remote server.
  • Build tooling could be a worthwhile inevitably for developers to learn
• Readability: Vue components may be more readable for new developers because they leverage HTML-like elements and attributes
• Approachability: Ease of getting started can be a double-edged sword if it fails to teach fundamentals of the language that would be necessary for continued maintenance. The demands of rich interfaces necessitate a deep understanding of the language.
  • At the same time, we must not ignore that WordPress would not be where it is today if not for its ease of getting started. If we achieve maintainability but nobody is willing or capable to maintain it, then nothing is accomplished.
• To differing sentiments between the developer chat and resulting commentary on last week’s summary: there are clear React leanings observed in the Slack chat, whereas the summary comments largely favored Vue.
  • How can we disassemble surface-level claims of “complex” and “simple” into a detailed understanding of why these feelings exist?
• The broad impact of choosing a framework: Plugin and theme authors should have the freedom and flexibility to choose their desired tool.
  • In this framing, it should primarily be a decision of core contributors to make if it is they who are to be affected.
  • But is a framework decision going to count as a vote of confidence and unnecessarily skew perceptions one way or the other to choosing the best tool for the job?
• Learning from the past: Why does Media Library see so few contributions? What lessons can we learn from this to avoid having this conversation again in a few years time, or is that an inevitability?
• Future compatibility: Templating languages tend to have short lifespans. An example was raised of a Vue 2.0 breaking change regarding v-for as evidence suggesting that deviations from the core language are subject to change and therefore undermine stability. Learning the syntax of a language can be simple at the cost of understanding the underlying flow of data.
• Process for adoption: A rewrite is unfeasible, and therefore modularity is an important consideration. Do we see the future dashboard as a collection of small applications, or a monolithic single-page application? There appear to be differing opinions on this.
  • Instead of rushing to adopt a new framework, where can we find ways to reduce our footprint, especially in light of revised browser support?

Conclusion and Action Items

With WordCamp Europe quickly approaching and this conversation having encompassed two JavaScript chats, it’s expected that a review of the discussions and formulation of action items should take place during the WCEU contributor day and at the Community Summit.

The topic of next week’s JavaScript chat will not focus on this decision, but you are encouraged to leave your comments below relating to this week’s topic or a suggestion for next week.

#javascript, #summary