JavaScript chat summary for Sept. 26th

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

This week’s meeting was focused around the role of a JavaScript framework in WordPress. The meeting was attended by many guests to the conversation, speaking on behalf of their respective frameworks or web standards:

Google (Web Components / Chrome / Polymer / AMP) – Justin Fagnani (Chrome / Polymer), Alex Russell (Chrome), Wendy Ginsberg (Polymer), Paul Bakaus (AMP), Alberto Medina (AMP)
Facebook (React) – Sophie Alpert, Dan Abramov, Dominic Gannaway
Vue – Evan You

 

What role should a framework play in a WordPress developer’s workflow, and in which contexts? For what purposes do we rely on a framework?

@youknowriad started off the discussion by offering three things as important for the role of the framework

  • Build UI and handle dom updates
  • Build reusable “components”. Reused in Core and potentially for plugins
  • Ability to extend the UI (using the same framework or not)

@dmsnell added it should provide a well-defined interface for isolated components to interact with so that people can have the freedom to build pieces how they want.
@mrahmadawais added that A framework should have a great development community, great documentation
@herregroen added [it]… should make it as easy as possible for components to communicate through more than simply DOM updates.
@peterbooker raised the importance of ease of access, for  … the [WordPress] development community… used to PHP, HTML, CSS, etc.
@mrmaniac (Paul Bakaus) added the best level of separation is if the framework is used to build the core, but isn’t exposed as API to block builders. This gives one the choice to replace the underlying foundation whenever necessary.
@mcsf said that for a project of the nature of WordPress, a framework should be relatively self-effacing, and its interface surface should be minimized and as agnostic as possible, mimicking the evolving JS specs.
@westonruter pointed out that If the underlying framework is being loaded on the page anyway, it should be available for plugin authors to utilize since otherwise they’d have to each include their own bundled frameworks… if core is shipping with one framework, then it would become the de facto framework by virtue of it being available out of the box.
@matias disagreed a bit with the idea that whatever core uses… is going to be the de facto standard for plugin development. The actual framework here, in general terms, is going to be what WordPress exposes and the APIs.
@flixos90 said I think core shipping a default framework and thus somewhat defining a standard to use is necessary to prevent compatibility issues by people using whatever framework (version) they like.
@mrmaniac (Paul Bakaus) suggested maybe there’s a middle ground, where, if you happen to use the same framework as the core, you benefit from the bundling, but if the core ever switches to another one, the framework gets lazy loaded in, and we create a mechanism that does this reliably.
@evanyou added I believe it’s important (and technically feasible) to separate “which framework to use for core” and “which framework community devs use for extensions”

 

The discussion moved on to interoperability and specifically ideas for providing a generic interface which can adapt to future change.

As background, @aduth put together two pull requests in Gutenberg on interoperability, one exploring combination of generic data structure / DOM access, and another using web components as the common interface:
https://github.com/WordPress/gutenberg/pull/2463 – Framework-agnostic block interoperability (Vanilla, Vue)
https://github.com/WordPress/gutenberg/pull/2791 – Support block `edit` defined as tag name for web components interoperability

@slightlyoff sees two major classes of interop: ease of development of leaf components and ease of integration of leaves into a larger whole.
@Justin Asked does anyone think that the custom elements lifecycle is not sufficient? At least for a foundation?

 

Discussion continued, largely focused around web components – how they could be leveraged for interoperability and how well they are supported in each framework.

@sophiebits (Sophie Alpert) added that in React, we have some web component support but haven’t made it a large priority since use cases have seemed slim in the past… but we do have some support for them nonetheless and I’m happy to entertain adding more, either now or in the future
@evanyou commented on the high level I think frameworks like React/Vue provides what is not really addressed in web components: efficient and declarative DOM updates reacting to state changes.. this is also why Polymer exists on top of WC
@Justin said that is ok: Web Components don’t need to answer _every_ question about components: they’re a foundation and interop layer
@trueadm added One major advantage of abstract components over web components is the fact they don’t live in the DOM. This gives several advantages – such as not being a global register custom element and being able to easily change/alter to an underlying layer as times change
@gaearon (Dan Abramov) added I’m not convinced custom elements are best interop layer. I would prefer plain JS hooks. On top of that, you can always add everything including them.

 

Discussion continued to patterns for pluggable interfaces, including the current use of react-slot-fill in Gutenberg and comparing it to <slot>. The meeting wrapped up with some discussion of how the choice of a framework for core impacts the wider community.

@gaearon (Dan Abramov) said I don’t really know WordPress well, so it’s hard for me to say whether [React is] a great fit for the use case or not… I think in general people have strong opinions about, for example, templating vs expressiveness, and I don’t feel like forcing React upon everyone is the best way. 

To which @evanyou responded I also feel the same way – forcing a single framework on everyone, regardless of which one, is IMO not a good idea because it is bound to alienate the group of devs who are not into that framework, and imposes a bigger long term stability risk.

 

Thanks to everyone who participated – especially to our guests from outside of the WordPress community: we welcome further collaboration with you in the future.

It is very clear (and refreshing to see!) from the conversation that the developers working on React, Vue and Polymer all care deeply about pushing the open web forward in a collaborative fashion. While we may not always agree on approaches, syntax or terminology, we do all agree that developers should be free to choose the platform and tools they find to be the best fit for their requirements. For WordPress core, this means that regardless of the framework we choose to use internally on projects like Gutenberg, we should ensure that the API we expose externally remains framework agnostic.

 

Add your voice and assistance!
We can use help especially testing @aduth‘s pull requests exploring interoperability: https://github.com/WordPress/gutenberg/pull/2463 and https://github.com/WordPress/gutenberg/pull/2791. Please read thru these PRs and test them out – see what works and what is missing, and give us your feedback.

Please join us next week at our regularly scheduled time Tuesday, October 3, 2017 at 13:00 UTC for the next JavaScript chat.

#core-js, #javascript, #summaries

New Contributors Meeting Recap – July 19

Last week’s New Contributors Meeting was held on Wed July 19th at 19:00. Once again, there were lots of great questions asked in the #core channel. Read the full chat archive here.

Discussion Highlights:

Tickets Discussed:

  • #41155 – WordPress 4.8 Admin Sidebar Sub Menu Navigation Issue
  • #41317 – Consistent sub menu item spacing when count indicator is present
    • Congrats to @JDTrower for pushing it along and getting it in the 4.9 Milestone!
  • #41314 – If the required fields are not set on user profile’s save, every field’s value will be dropped

The next meeting will take place in the #core slack channel on Wed, July 26th at 19:00. Please feel free to drop in with any questions or tickets you’d like to discuss!

Thanks to everyone that attended! As always, please feel free to leave a comment below or reach out to any of the moderators with questions on Slack.

Moderators: @flixos90, @welcher, @stevenkword, @desrosj

#new-contributors, #summaries

New Contributors Meeting Recap – July 12

This week’s New Contributors Meeting was held on Wed July 12th at 19:00. Once again, there were lots of great questions asked in the #core channel. Read the full chat archive here.

Discussion Highlights:

Tickets Discussed:

  • #40921 – Inconsistent Handling of mp4 by Audio Widget
  • #40138 – Bundled themes: the tag cloud widget should output a list
  • #22669 – iPad: Can’t Scroll Plugins Modal
  • #41168 – Identify the active theme when editing a site’s themes

The next meeting will take place in the #core slack channel on Wed, July 19th at 19:00. Please feel free to drop in with any questions or tickets you’d like to discuss!

Thanks to everyone that attended and please feel free to leave a comment below or reach out to any of the moderators with questions.

Moderators: @flixos90, @welcher, @stevenkword, @desrosj

#new-contributors, #summaries

New Contributors Meeting Recap – July 5

The inaugural New Contributors Meeting was held on Wed July 5th at 19:00 and had a great turnout with lots of questions asked in the #core channel (read the full archive ).

The informal agenda was to try and answer as many general questions as possible and then move over to a bug scrub/ticket review portion.

Discussion Highlights

Tickets Discussed:

  • #33756 – Improve docs for sanitize_title()
  • #38828 – Update_blog_details() performance improvement ideas
  • #38310 – Improve “wp_update_term” documentation

 

The next meeting will take place in the #core slack channel on Wed, July 12th at 19:00. Please feel free to drop in with any questions or tickets you’d like to discuss!

Thanks to everyone that attended and please feel free to leave a comment below or reach out to any of the moderators with questions.

Moderators: @flixos90, @welcher, @stevenkword, @desrosj

#new-contributors, #summaries

JavaScript Chat Summary for June 27th

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

  •  A post about the JavaScript framework decision for core is delayed to give more time for feedback.
  • The Weekly JavaScript chats will continue on the current schedule, however, we will no longer be posting agenda’s and summaries will be brief if posted unless something significant is happening, such as a new feature being merged.
  • A lengthy discussion about packages/modules ensued (related – #40834) and a packages repository was created to start collaborating on creating core WordPress JavaScript packages – https://github.com/WordPress/packages.
  • Several candidates were discussed and Yoast offered to donate their a11y package.
  • Discussion of namespacing,  repository management and documentation.
  • @youknowriad suggested we talk about build and test tools at the next meeting make sure to stay consistent with modules and how we use them.

Please join us next week at July 4, 2017 at 13:00 UTC in the #core-js slack channel, or visit at any time to get involved in contributing to WordPress core JavaScript.

#javascript, #summaries

Dev Chat Summary: August 3, 2016

Current status of WordPress 4.6

  • The 4.6 branch was created this week.
  • RC2 was scheduled for today, but because https://core.trac.wordpress.org/report/6 has so many open tickets its being delayed by 24 hours.
  • The first draft of the About page was committed today. Please help review it to make it ✨ Shiny ✨
  • @hugobaeta is looking for feedback on the images he’s created for the About page. The feedback will be heard and discussed in the #design weekly chat on August 4th, 2016 at 20:00 UTC.

Schedule for the next 13 days

The schedule is as follows:

  • August 10 is RC3 with the hard string freeze. The about page must be finalized by then.
  • August 12 will be code freeze. Everything should be done by this date. Only version bumps and the video should committed after this.
  • August 15 is the dry run for WordPress 4.6. We’ll check everything, prepare w.org, do a dry run for release day, and with @davidakennedy and @karmatosed we’ll release the new versions of our default themes as well.
  • And well, August 16, 2016. WordPress 4.6!

About page

As already mentioned, a first pass is committed. Check your dashboard and let us know what you think. Maybe ask some friends who aren’t involved in the release since that’s our target group.

Call for volunteers

The call for future release leads has been published. Leading a release can be a rewarding challenge. If you have questions, feel free to ping @jorbin or @helen. Everyone interested, please express it on the post, pinging @jorbin or @helen isn’t enough. They are more so available for answering questions. https://make.wordpress.org/core/2016/08/01/release-leads-call-for-volunteers/

Component announcements/updates and Open discussion

Currently the contributor handbook is lacking in documentation in regards to contributing via git. Core has supported git contributions for over 2 years. If you have a git work flow, use git, or have git knowledge in general, please consider looking over https://make.wordpress.org/core/handbook/contribute/ and adding docs where appropriate. Please remember that supporting git does not mean using GitHub.

Find full chat logs here: https://wordpress.slack.com/archives/core/p1470254406001902

#4-6, #dev-chat, #summaries

Taxonomy meeting summary – 2015/09/03

Present: @boonebgorges, @swissspidy, @masonjames, @drewapicture, @georgestephanis, @khromov, @srwells, @michaeltieso, @dpegasusm, @kraft, @mrahmadawais, @samuelsidler, @leatherface_416, @jblz, @tyxla, @jeroenvanwissen, @lindsaymac, @eric, @jbrinley, @brashrebel, @pdufour, @joehoyle, @timothybjacobs, @ryanduff, @krogsgard, @aaroncampbell, @rahe

Logs: https://wordpress.slack.com/archives/core/p1441310435002734

  • Had a general discussion about term meta: who’s used plugins for it, who’s used workarounds, various use cases. We talked a bit about some arguments against term meta: that it will not perform well at scale, that it encourages poor data modeling – but decided that they could be set aside for the most part.
  • Outlined the interpretation, including database table name and schema, function names, and other API additions to support term meta. @boonebgorges will work up a RFC for make/core for feedback.
  • Talked about various ways in which existing term meta libraries might conflict with the core implementation: duplicated function names, duplicate table names, incompatible table schemas, etc. @boonebgorges is assembling a list of plugins in the repo that may conflict with the core implementation. Once the outline of the core implementation is pretty much settled, @aaroncampbell, @krogsgard, @masonjames, and @boonebgorges (and anyone else who is interested) are going to collaborate on reviewing these plugins to see which ones will conflict in serious ways (via a Google Doc, which @boone will share once we’re ready to go). This will help us gauge the extent of potential problems, and get a sense of what outreach will look like.
  • We talked a little about combining the wp_terms and wp_term_taxonomy database tables #30262. We outlined some backward compatibility concerns, and strategies for minimizing conflicts. Put out a general call for thoughts and initial patches on the ticket, though we probably won’t move forward with schema changes for at least one more release cycle.
  • Had a very brief discussion about WP_Term #14162. Initial implementation – probably doable for 4.4 – will be simple, and will focus on strict typing for term data as well as cache invalidation. Future releases may see more functionality moved to the class.

#4-4, #chats, #meeting, #summaries, #taxonomy