“This chat will focus largely on identifying requirements in building core features, overlap with plugin and theme authors, and patterns to reducing framework lock-in,” Duthie said. “Ideally this is higher-level than simply debating the merits of specific frameworks in a vacuum, and should be seen as an opportunity to collaborate between projects to set a path forward for WordPress which will provide flexibility and resiliency to future churn.”
Duthie began by asking what role a framework should play in a WordPress developer’s workflow and also asked framework contributors to offer their perspectives on recommendations for extendable interfaces. This question provided attendees with the opportunity to weigh in on topics such as support for web components, framework-agnostic block interoperability for Gutenberg, and how this might affect WordPress’ plugin ecosystem.
“I disagree a bit with the idea that whatever core (in this case Gutenberg) uses to power some of the intricacies of building a stateful app is going to be the de facto standard for plugin development,” Gutenberg engineer Matías Ventura said. “The actual framework here, in general terms, is going to be what WordPress exposes and the APIs.”
With a framework-agnostic approach to building Gutenblocks, the library that core decides to build on doesn’t have to become the de facto standard for plugin developers but many outside the Gutenberg team believe that it will inevitably end up that way in practice. There are entire teams of engineers waiting on this decision that are committed to adopt whichever framework WordPress bets on.
“To provide some perspective on how WP’s decision on a framework impacts developers downstream, I’m a developer at Boston University and our plan is to focus on whichever framework WP decides upon, even if Gutenberg has a completely agnostic API,” Adam Pieniazek said. “We’re primarily a WP shop (~ 1,000 site WP install powers most/a lot of our public web presence) and end up creating huge customizations on top of WP that often require diving into core to see what is actually happening in the background. I like Vue more than React personally, but if WP decides upon React, BU will focus on building expertise in React for when we need to peek/debug beyond the API. It doesn’t mean we won’t also use Vue but it won’t be our primary focus.”
Pieniazek feedback echoes that of Gravity Forms co-founder Carl Hancock, who said his team is ready to adopt whatever library WordPress selects.
“People are going to end up adopting whatever core uses for the most part despite the rainbows and butterflies some are claiming as it relates to creating an abstraction layer so plugin/theme developers can use whatever they want,” Hancock said in the #core-js channel earlier this week.
Many participants from outside the WordPress community seemed to be in agreement with a framework-agnostic approach and none were eager to force a single framework on all developers working with WordPress. The remaining concern is how this works out practically and whether it puts developers in the confusing position of using a framework on top of a framework.
“Since Gutenberg itself is going to become a platform to build for, the best level of separation is if the framework is used to build the core, but isn’t exposed as API to block builders,” AMP engineer Paul Bakaus said. “This gives one the choice to replace the underlying foundation whenever necessary.”
Gutenberg engineer Riad Benguella summarized the approach the team has been discussing:
I think what we try to communicate is something like:
– WordPress Core is going to use this X framework internally
– If you want to use it, we think it’s good
– If you want to use something else, you can just as easily as you’d use the Core’s chosen framework
Benguella also said that one of the goals for Gutenberg is “to set the basis for how we extend WordPress’ UI in the future.” Once it ships, the team will likely set its sights on other parts of the wp-admin and build them in the same way.
“If all parts of WP’s UI can be extended via a standard interface, whether it be a simple ‘data down, events up’ API, or expecting a WC, I think this would cleanly separate the concerns of ‘what framework to use for core’ vs. ‘what framework to use for extension development,’” Vue.js creator Evan You said.
When asked for his thoughts on on React becoming a primary framework for WordPress, React maintainer Dan Abromov was hesitant to advocate for WordPress adopting the library. His response underscored the necessity of having a framework-agnostic approach for extending Gutenberg and future WP interface overhauls.
“I don’t really know WordPress well, so it’s hard for me to say whether it’s a great fit for the use case or not,” Abramov said. “Generally we use React for highly interactive UIs and find that it scales well with the app size. I’m also happy to answer technical questions about it. But 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.”
“I also feel the same way,” Evan You said. “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.”
Abramov also said that people are already “very bitter and divisive” about the subject of selecting a framework. He also tweeted a similar sentiment prior to the meeting.
When I read discussion threads (e.g. about WordPress) there’s a sense that people perceive every team as hostile to others. That’s false.
— Dan (@dan_abramov) September 26, 2017
Think of it like tending a garden. You’re welcome to hang out at ours. Other gardens are great too 🙂
— Dan (@dan_abramov) September 26, 2017
“I believe it’s important (and technically feasible) to separate ‘which framework to use for core’ and ‘which framework community devs use for extensions,’” Evan You said.
“Yes, I think there’s a goal here to be unopinionated for what we’re exposing to plugin authors, so long as the APIs/interfaces we do expose are sufficiently flexible (and easy) to build the UIs and interactions they need to implement,” Andrew Duthie said.
The topic of supporting web components interoperability for Gutenblocks was also part of the discussion during the meeting.
“While less powerful than most of the actual frameworks at this point, they are likely to become a W3C standard, ensuring that they will stick around and evolve,” Felix Arntz said. “Plus once browser support is fully there, there’s less functionality to implement by an actual framework built on top.”
Polymer.js representative Justin Fagnani said he disagreed that they are “less powerful” and noted that web components already are a W3C standard.
“I think WP is also uniquely positioned to help drive forward support for web components natively everywhere,” EventEspresso core dev Darren Ethier said. “Pretty much all the frameworks have the ability to work with the web component spec now. It’s just a matter of proper implementation.”
Several participants referenced custom-elements-everywhere.com, a site that displays popular JS frameworks’ progress on communicating Custom Elements in a way that promotes interoperability. Matías Ventura asked React and Vue core devs how web components (and their future) fit into each framework at the moment.
“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, especially since adding Web Components hasn’t made a lot of sense in a first-party application where you control the whole stack – but we do have some support for them nonetheless and I’m happy to entertain adding more, either now or in the future,” Sophie Alpert said.
“On the high level I think frameworks like React/Vue provide what is not really addressed in web components: efficient and declarative DOM updates reacting to state changes,” Evan You said. “This is also why Polymer exists on top of WC. I have always acknowledged the value of WC as an interop interface.”
Overall, attendees at the meeting were respectful, collaborative, and eager to contribute their expertise to help WordPress contributors find the best way forward in the framework selection process. The discussion will continue at next week’s meeting and likely in the comments of a forthcoming Make/Core post summarizing the meeting.
This is a great discussion. I’m following the debate and will choose whatever the core team selects, just like other people. While learning other frameworks is doable, we don’t want to waste our resources on things other than what will benefit most.