Core JavaScript Meeting Time Change

In response to feedback collected during and after last week’s JavaScript chat, the scheduled time of these meetings has been changed to occur one hour later, starting tomorrow at Tuesday, November 14, 2017 at 14:00 UTC and at the same time each Tuesday thereafter.

A few respondents had indicated preference for an Asia/Pacific-friendly meeting time. If enough interest can be generated, a separate meeting may be justifiable. Please indicate in the comments below if you would have interest in regularly attending at a time convenient for this region.

#javascript

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

JavaScript Chat Agenda for September 26th

Please observe the noted two-hour delay in scheduled meeting time.

The past few weeks have been eventful for the WordPress JavaScript community: First with the decision that WordPress would not use Facebook’s React project in developing core features, then a subsequent announcement by Facebook of their intention to relicense React and other open source projects. The time between was marked by lively discussion of frameworks and interoperability, which will continue as the topic of our next JavaScript chat.

Topic: The role of a JavaScript framework in WordPress, particularly as it relates to:

  • The requirements of core features
  • Considerations for plugin and theme developers
  • Framework interoperability
  • Future sustainability

When: Tuesday, September 26, 2017 at 15:00 UTC (Note: This is two hours later than the regularly scheduled time, in an effort to maximally accommodate all interested groups)

Where: #core-js Slack channel (Register)

For additional context, you may consider reviewing chat summaries from earlier this year relating to framework use in core (May 30th, May 23rd) or a recent GitHub issue which has garnered significant attention and discussion.

If you have questions related to the above agenda, please leave a comment. See you there!

#agenda, #javascript

JavaScript Chat Canceled for September 19

With the events of the past week relating to the decision to move away from React and the use of a hooks extensibility pattern, we are expecting the next JavaScript meeting to be very lively. Since many of the individuals leading these efforts and/or active in the discussions will be unable to attend, we have decided to postpone discussion until next week’s meeting on Tuesday, September 26, 2017 at 13:00 UTC.

The agenda for next week’s discussion will include:

  • The role of a JavaScript framework in current and future Core focuses (including but not limited to the Gutenberg editor)
  • Patterns of extensibility and use-cases for hooks

A reminder agenda will be posted ahead of the meeting on Monday, September 25.

#javascript

Proposal for JS Standards Revision: Removing Array/Function Whitespace Exceptions

Coding standards have been a recurring topic in the JavaScript Weekly Chat over the past few months. One rule in particular which has been the focus of much discussion are the exceptions for whitespace in arrays and function calls, which reads:

Always include extra spaces around elements and arguments:

[…]

Exceptions:

  • […] do not include a space around string literals or integers used as key values in array notation
  • Function with a callback, object, or array as the sole argument: No space on either side of the argument
  • Function with a callback, object, or array as the first argument: No space before the first argument
  • Function with a callback, object, or array as the last argument: No space after after the last argument

In the course of our chats, there has been some consensus around removing this “Exceptions” section entirely, though we considered to seek broader feedback on the decision, particularly in how it impacts overlapping PHP standards and existing code.

Why should this exception be removed?

The purpose of a coding standard should be to impose sensible rules for the sake of consistency and readability. In the case of consistency, a developer should be at ease both in writing and reading code.

The very existence of an exception is at odds with these ideals, harming consistency in that:

  • A code reader may not think to expect it if they are not familiar with the exception
  • A code writer may not know to apply it if they are not familiar with the exception. Or worse yet, one familiar with the rule may not know how to apply it.

The arrays and functions exception is notably egregious for being difficult to apply. Take, for example, the following snippet of code:

( function( wp ) {
	wp.foo = foo( 5, {});
	wp.bar(function() {
		console.log( 'Done' );
	});
	wp.baz( x, x + 5 );
	wp.baz(x => x + 5);
} )( window.wp = window.wp || {} );

This code is valid in its use of whitespace, but took considerable effort on the part of a developer well-versed in the standards to understand precisely where the exceptions do and do not apply.

Generally, exceptions increase the barrier to entry for new developers by imposing another prerequisite to becoming productive, increase overhead for existing contributors by requiring careful consideration of their application, and are anti-productive in the review hours wasted enforcing their inevitable mis-use.

Why should this exception not be removed?

All of the above notwithstanding, the exceptions concerning array or object keys at least have some basis in overlap with equivalent rules in the PHP Coding Standards. While I would argue that most all exceptions should be avoided, the focus of the first section is aimed primarily at function arguments, which tends to cause most uncertainty. It may be an agreeable compromise to remove only the exceptions impacting function arguments, leaving still the array and object key exceptions.

Standards changes should be carefully considered, as it has a large impact on existing code which applies the current standard, and on knowledge of developers who have already become familiar with the standards. However, my experience is that these exceptions aren’t particularly well-understood, and in-fact that eliminating them would be more in spirit with how whitespace is otherwise applied (“When in doubt, space it out.”).

What happens next if these exceptions are removed?

If consensus is reached, the following actions should be taken:

  • Our standards documentation are updated to remove the exception language
  • Our ESLint rules are updated to remove the exception
  • All new commits to WordPress core follow the new standards
  • Old code will only be refactored as part of a larger, codebase wide refactoring effort (see related effort at #41057)

What are your thoughts? Please share in the comments below.

#javascript, #standards

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

JavaScript Chat Agenda for June 27th

Please join us for our weekly JavaScript Chat on June 27, 2017 at 13:00 UTC, where we will discuss:

  • No more agendas
  • Modules – What should we start moving into modules? How will these modules get integrated into core, workflows? How do we get started?
  • Big ticket items –  What tickets can we finish up in 4.9? Let’s make a plan to complete them.
  • Ticket Scrub/Open Floor

Important! All JavaScript chats will now take place in the #core-js Slack channel. Please join us there.

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#agenda, #core-js, #javascript

JavaScript Chat Summary for June 20th

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

WordCamp Europe Summary

  • Contributor day drew 500 attendees and included two JavaScript-focused sessions
  • Sessions overflowing-packed, indicating huge and growing interest in using JavaScript in WordPress
  • Anyone involved in JavaScript is encouraged to consider giving a WordCamp talk to share your experience
  • During community summit, recap of framework discussion and review of recent core chats
  • Notes from Community Summit will be posted soon, including a decision surrounding the recent framework selection discussions and the rationale leading to it

Increasing JavaScript contributions in core

  • Observed very small number of contributors
  • Introduction of a new #core-js Slack channel toward goal of engaging new contributors looking to become involved in WordPress JavaScript (link to 300 open tickets)
  • Question: What factors increase developer involvement and how can we increase involvement?
  • Contributor experience: Workflow of using Trac and exchanging patches not welcoming to new generation of (JavaScript) developers using Git and GitHub
  • Gutenberg as as an example of a WordPress project being built in GitHub, easy way to become involved
  • Previous efforts relating to GitHub pull request integration with Trac (#34694, rmccue/github-to-patch)
  • Increase involvement by sharing generic modules in a WordPress modules monorepo, drawing awareness from developers engaging in these ecosystems (npm, etc)
  • In-progress side project from @atimmer to parse and publish documentation to DevHub using documentation.js
  • Lack of documentation cited as pain point for new contributors. Should improve overview-type developer guides for using and extending core JavaScript.
  • New contributors would like quick start tasks to work on. “Good First Bugs / Tasks” exist in Gutenberg and in Trac (filtered to JavaScript focus)
  • Contributions are slow to be reviewed or committed, perhaps discouraging new contributors
  • Yoast has started efforts to improve documentation for media library. We might consider moving these discussions into Trac to surface and organize them as core issues.
  • Is WordPress’s image in JavaScript communities as “old” (or otherwise undesirable) as being a deterrent? Possible solutions: Blogging about innovations, sharing useful utilities in broader JavaScript community, evolving foundation for JavaScript with efforts like Gutenberg, highlighting JavaScript improvements in release notes
  • New contributors might consider simply reviewing existing tickets, testing whether they’re still valid, taking screenshots, and commenting

Administrative

  • Weekly meeting agendas will become more minimal over time with focuses on bug scrubs and deciding larger item tickets (dates, hooks, etc)

#javascript, #summary

JavaScript Chat Agenda for June 20th

Please join us for our weekly JavaScript Chat on June 20, 2017 at 13:00 UTC, where we will discuss:

  • WordCamp Europe recap. JavaScript was a popular topic during the events surrounding WordCamp Europe, notably last week’s Community Summit and Contributor Day. Let’s recap these discussions and the action items set forth.
  • Increasing JavaScript contributions in core. How do we increase contributor involvement in core JavaScript and the number of contributors? This is an extension of an identical discussion which had taken place during WordCamp Europe’s Community Summit.

Important! All JavaScript chats will now take place in the newly-created #core-js Slack channel. Please join us there tomorrow.

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#agenda, #core-js, #javascript

JavaScript Chat Summary for June 6th

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

Pre-Discussion

Topic: Managing Complexity

  • WordPress is first development experience for many, and we should ensure JavaScript onboarding is similarly positive
  • Documentation as lacking
    • Current state of the wp global documentation
    • Documentation is always an after-thought
    • We can try automated documentation, but it’s not human-oriented and helps only if you know already what you’re looking for
    • We’ll need a combination of both automated and hand-written documentation
    • Need higher-level documentation to answer the questions of “How do I do X?”
    • User-submitted code examples like those on developer.wordpress.org are effective beyond just what the API is, but also how it’s to be used
    • To start, we need a 10,000 foot view explaining surface area of JavaScript in WordPress (expanding Core Handbook)
    • Who is the target audience of documentation: those looking to integrate, or contribute directly to the core codebase? Each requires different writing approaches.
  • Identifying challenges
    • Preparing a development environment and knowing where to find source files, especially in light of desire to more heavily adopt Webpack into workflow
    • Understanding decisions made: Why a framework, how do we approach data, how data is stored
    • Ideal workflow to npm start and be set to develop
    • Testing, build tools, module patterns
  • What to document?
    • Documenting UI components is new consideration. React Storybook was raised an example for demonstrating shared UI library (proposed in Gutenberg)
    • Bridging the divide between Backbone + Non-Backbone (“new”) system
  • Where to draw the line between complexity and unfamiliarity?
    • No amount of documentation can make up for a confusingly complex design
    • Some level of unfamiliarity is expected because it’s a different language with different paradigms than what a PHP developer might be most familiar with (example: declarative, reactive components)
    • We sell ourselves short if we limit only to what people already know
  • Incrementally introducing more complex functionality
    • What are the small tasks that developers will start with in getting used to working with WordPress JavaScript? “Writing an editor (Gutenberg) block” is a more advanced case, but highlights need for emphasis on the interfaces we expose, not just the documentation
  • Audience of documentation
    • People learn differently: Video works best for some, text for others
    • Might consider building personas to represent different users of documentation
  • Tools for documenting
    • We should standardize on JSDoc, but available tooling is somewhat lacking
  • Examples / success stories
    • Vue / React / Redux – Incremental introduction
    • documentation.js – Static analysis tool for creating documentation
    • React Storybook – Interactive UI component explorer
    • Calypso (Note: pages have layout issues if not logged in to WordPress.com)
  • Thoughts on scaffolding / code generation tools, like vue-cli, create-react-app, or more granular scaffolding like those found in Ruby on Rails or Laravel workflows (models, controllers, etc).
    • Not sure yet what sorts of things we’d care to generate
    • Could be valuable in “Age of Front-End Tooling Complexity”
    • Works for some people, not for others

Open Floor

  • From a comment on the agenda, @omarreiss shared a proof of concept for React extensibility, and was happy with control React gives toward goal of extensibility
    • Other approaches were shared: Nylas plugins, Gutenberg considerations (1, 2, 3)
    • “Extensibility” proposed as a future meeting topic
  • @rmccue shared his success with rendering PHP-only columns in the List Tables prototype toward a goal of backwards compatibility, and invites for consideration whether this is something we’d want for wider use or if others have encountered similar issues.

#javascript, #summary