JavaScript chat summary for May 9th

The focus of the meeting was reflecting on ongoing and past efforts to apply JavaScript more heavily in WordPress, to help inform requirements of the tools we’ll need to implement the features we want to build.

To the end of better understanding what we have in core now, @adamsilverstein shared some research he is working on: A slidesdeck of JavaScript added to each version of WordPress (click the right arrow on the first link to go thru the versions) and a summary of features that use JavaScript added to each version

Next, we delved into the pains, tools, patterns, etc. used in the following ongoing efforts:

  • Porting the media library and TinyMCE into the Customizer with Media and Text widgets
  • Creating new and revised UIs leveraging the REST API like Quick Drafts and New List Table

@timmyc talked about his experiences developing the new Media Widgets, which are all built utilizing wp.media. @westonruter has created a great summary of some of the bumps they had along the way.

@youknowriad shared the experience working on the editor project using React. He said the main pain point is making TinyMCE work in a “controlled” way (unidirectional data-flow).

@rmccue and the REST API team have been looking at making the dashboard use the REST API generally, looking at a lot of the core JS. He summarized “WordPress has a JavaScript framework already: we have all the pieces that you’d have in a framework, but they’re not tied together, and they’re very poorly documented… Additionally, every piece is subtly different in architecture, implementation, design, etc.”

@joemcgill added the overall architecture of wp.media is not well documented anywhere, so there’s a huge barrier to entry for anyone who wants to work on even minor bugs. It’s not simply understanding backbone, but you also have to understand how wp.media has implemented a custom frame/region/state model.

The team agreed to work on documenting the overall wp.media architecture, and @omar offered to try to focus the team at Yoast on helping with documenting wp.media as part of their ongoing effort to document core JavaScript.

Discussion continued around the reason developers find working with media and other core JS so difficult. Is it the complexity? The lack of documentation? Or is the architecture itself the problem? Probably all of the above.

The discussion touched on the history and evolution of our use of JavaScript in core, and the consensus was that moving forward, new view/UI components should be built in a more modern framework such as React or Vue. The specific framework is a conversation for another day, the decision was that we need something new to be able to achieve the experiences we want to build. At the same time, we need to maintain what we have and ensure developers can use it. There was some discussion of core documentation and a proposal to add JSHint to core’s build process.

Discussion continued to backward compatibility, and the issue of “losing” PHP hooks when we switch old functionality from wp-ajax to the REST API. Do we need to provide backward compatibility for all PHP hooks? Or can we offer new approaches for developers to extend WordPress, for example, wp.hooks?  @omar shared their experience at Yoast when they switched their content analysis from php to js.

The meeting wrapped up with ideas for next week’s meeting the team made a plan to discuss modularity/modules as well as JavaScript coding standards.

As a reminder to contributors that there are over 300 open tickets in the JS focus that can use your help!

For a full transcript of the meeting, check the slack logs.

#javascript