WordPress Core JavaScript Framework 선택 토론은 오픈 소스 커뮤니티 리더의 의견으로 계속됩니다.

WordPress의 #core-js Slack 채널은 오늘 아침 Andrew Duthie가 이끄는 활기차고 생산적인 회의를 주최했습니다. 토론에서는 특정 프레임워크 비교보다는 WordPress용 JavaScript 기반 인터페이스를 구축하는 데 있어 프레임워크가 수행할 역할에 대해 중점적으로 설명했습니다. 기고자는 React 및 Vue 커뮤니티의 핵심 개발자 및 리더, Chrome 엔지니어, WordPress 커뮤니티 외부의 기타 이해 관계자가 참여했습니다.

Duthie는 "이 채팅은 핵심 기능 구축, 플러그인 및 테마 작성자와의 중복, 프레임워크 종속을 줄이기 위한 패턴의 요구 사항을 식별하는 데 주로 초점을 맞출 것입니다."라고 말했습니다. "이상적으로는 공백 상태에서 특정 프레임워크의 장점에 대해 단순히 토론하는 것보다 더 높은 수준이며, 향후 변동에 대한 유연성과 탄력성을 제공할 WordPress의 경로를 설정하기 위해 프로젝트 간에 협업할 수 있는 기회로 간주되어야 합니다."

Duthie는 WordPress 개발자의 워크플로에서 프레임워크가 어떤 역할을 해야 하는지 묻는 것으로 시작했으며 프레임워크 기여자에게 확장 가능한 인터페이스에 대한 권장 사항에 대한 관점을 제공하도록 요청했습니다. 이 질문은 참석자에게 웹 구성 요소 지원, Gutenberg에 대한 프레임워크 불가지론적 블록 상호 운용성 및 이것이 WordPress의 플러그인 에코시스템에 어떤 영향을 미칠 수 있는지와 같은 주제에 대해 평가할 기회를 제공했습니다.

Gutenberg 엔지니어 Matias Ventura는 "상태 저장 앱을 구축하는 데 필요한 일부 코어를 구동하기 위해 사용하는 코어(이 경우 Gutenberg)가 플러그인 개발을 위한 사실상의 표준이 될 것이라는 생각에 약간 동의하지 않습니다."라고 말했습니다. "여기의 실제 프레임워크는 일반적으로 WordPress가 노출하고 API가 될 것입니다."

Gutenblocks 빌드에 대한 프레임워크 불가지론적 접근 방식을 사용하면 핵심이 빌드하기로 결정한 라이브러리가 플러그인 개발자를 위한 사실상의 표준이 될 필요는 없지만 Gutenberg 팀 외부의 많은 사람들은 실제로는 필연적으로 그렇게 될 것이라고 믿습니다. 이 결정을 기다리고 있는 전체 엔지니어 팀이 WordPress에 베팅하는 프레임워크를 채택하기 위해 최선을 다하고 있습니다.

Adam Pieniazek은 "프레임워크에 대한 WP의 결정이 개발자 다운스트림에 미치는 영향에 대한 관점을 제공하기 위해 저는 Boston University의 개발자이며 우리 계획은 Gutenberg가 완전히 불가지론적인 API를 가지고 있더라도 WP가 결정하는 프레임워크에 초점을 맞추는 것입니다"라고 말했습니다. . “우리는 주로 WP 상점(최대 1,000개의 사이트 WP 설치가 공개 웹 존재의 대부분/많은 부분을 차지함)이며 결국 WP 위에 거대한 사용자 정의를 생성하여 백그라운드에서 실제로 무슨 일이 일어나는지 확인하기 위해 핵심을 파고들어야 하는 경우가 많습니다. . 저는 개인적으로 React보다 Vue를 더 좋아하지만 WP가 React를 결정한다면 BU는 API 너머를 엿보고/디버그해야 할 때를 위해 React에 대한 전문성을 구축하는 데 집중할 것입니다. Vue도 사용하지 않는다는 의미는 아니지만 우리의 주요 초점은 아닙니다.”

Pieniazek 피드백은 Gravity Forms 공동 창립자 Carl Hancock의 피드백을 반영합니다. 그는 자신의 팀이 WordPress가 선택한 라이브러리를 채택할 준비가 되었다고 말했습니다.

Hancock은 #core-에서 "사람들은 플러그인/테마 개발자가 원하는 것을 사용할 수 있도록 추상화 레이어를 만드는 것과 관련이 있다고 주장하는 무지개와 나비에도 불구하고 대부분의 경우 핵심 용도가 무엇이든 채택하게 될 것입니다."라고 말했습니다. 이번 주 초에 js 채널.

WordPress 커뮤니티 외부의 많은 참가자는 프레임워크에 구애받지 않는 접근 방식에 동의하는 것처럼 보였고 아무도 WordPress로 작업하는 모든 개발자에게 단일 프레임워크를 강요하려고 하지 않았습니다. 나머지 문제는 이것이 실제로 어떻게 작동하는지와 개발자가 프레임워크 위에 프레임워크를 사용하는 혼란스러운 위치에 놓이게 하는지 여부입니다.

AMP 엔지니어 Paul Bakaus는 "구텐베르그 자체가 빌드용 플랫폼이 될 것이기 때문에 프레임워크가 코어를 빌드하는 데 사용되지만 블록 빌더에 API로 노출되지 않는 경우 최고의 분리 수준이 됩니다."라고 말했습니다. "이는 필요할 때마다 기본 기반을 교체할 수 있는 선택권을 제공합니다."

구텐베르크 엔지니어인 Riad Benguella는 팀이 논의한 접근 방식을 다음과 같이 요약했습니다.

우리가 의사 소통하려고하는 것은 다음과 같습니다.

– WordPress Core는 내부적으로 이 X 프레임워크를 사용할 것입니다.
– 사용하고 싶다면 좋은 것 같아요
– 다른 것을 사용하고 싶다면 Core에서 선택한 프레임워크를 사용하는 것처럼 쉽게 할 수 있습니다.

Benguella는 또한 Gutenberg의 목표 중 하나가 "향후 WordPress의 UI를 확장하는 방법에 대한 기반을 설정하는 것"이라고 말했습니다. 일단 배송되면 팀은 wp-admin의 다른 부분에 초점을 맞추고 동일한 방식으로 빌드할 것입니다.

"간단한 '데이터 다운, 이벤트 업' API이든 WC를 기대하든 WP UI의 모든 부분이 표준 인터페이스를 통해 확장될 수 있다면 '코어에 사용할 프레임워크 ' 대 '확장 개발에 사용할 프레임워크'”라고 Vue.js 작성자 Evan You는 말했습니다.

React가 WordPress의 기본 프레임워크가 되는 것에 대한 그의 생각을 물었을 때 React 유지 관리자인 Dan Abromov는 WordPress가 라이브러리를 채택하는 것을 옹호하는 것을 주저했습니다. 그의 응답은 구텐베르그와 미래의 WP 인터페이스 정밀 검사를 확장하기 위한 프레임워크 불가지론적 접근 방식의 필요성을 강조했습니다.

아브라모프는 “나는 워드프레스를 잘 몰라서 워드프레스가 유스케이스에 딱 맞는지 아닌지 말하기 어렵다”고 말했다. “일반적으로 우리는 고도의 대화형 UI를 위해 React를 사용하고 앱 크기에 따라 잘 확장된다는 것을 알게 되었습니다. 이에 대한 기술적인 질문에도 기꺼이 답변해 드립니다. 그러나 일반적으로 사람들은 예를 들어 템플릿 대 표현력에 대해 강한 의견을 가지고 있다고 생각합니다. 모든 사람에게 React를 강요하는 것이 최선의 방법은 아니라고 생각합니다.”

에반 유는 “나도 같은 생각이다. "어떤 프레임워크에 관계없이 모든 사람에게 단일 프레임워크를 강요하는 것은 좋은 생각이 아닙니다. IMO는 해당 프레임워크에 속하지 않는 개발자 그룹을 소외시키고 더 큰 장기적 안정성 위험을 부과하기 때문입니다."

Abramov는 또한 사람들이 이미 프레임워크 선택 주제에 대해 "매우 씁쓸하고 분열적"이라고 말했습니다. 그는 회의에 앞서 비슷한 트윗을 트윗하기도 했다.

토론 스레드(예: WordPress에 대한)를 읽을 때 사람들이 모든 팀을 다른 팀에 적대적으로 인식한다는 느낌이 듭니다. 그건 거짓이야.

— 단(@dan_abramov) 2017년 9월 26일

정원을 가꾸는 것과 같다고 생각하십시오. 당신은 우리에 어울리기를 환영합니다. 다른 정원도 훌륭합니다

— 단(@dan_abramov) 2017년 9월 26일

Evan You는 "'코어에 사용할 프레임워크'와 '개발자가 확장에 사용할 프레임워크 커뮤니티'를 구분하는 것이 중요하고 기술적으로 실현 가능하다고 생각합니다."라고 말했습니다.

"네, 우리가 노출하는 API/인터페이스가 구현해야 하는 UI 및 상호 작용을 구축하기에 충분히 유연하고(쉽게) 있다면, 플러그인 작성자에게 노출하는 것에 대해 의견이 없는 것이 목표라고 생각합니다. "라고 앤드류 듀티가 말했습니다.

Gutenblocks에 대한 웹 구성 요소 상호 운용성을 지원하는 주제도 회의 중 토론의 일부였습니다.

Felix Arntz는 "현재로서는 대부분의 실제 프레임워크보다 덜 강력하지만 W3C 표준이 되어 계속 발전할 것입니다."라고 말했습니다. "게다가 브라우저 지원이 완전히 완료되면 그 위에 구축된 실제 프레임워크로 구현할 기능이 줄어듭니다."

Polymer.js 대표 Justin Fagnani는 웹 구성 요소가 "덜 강력하다"는 데 동의하지 않으며 웹 구성 요소가 이미 W3C 표준이라고 언급했습니다.

EventEspresso의 핵심 개발자인 Darren Ethier는 "WP는 기본적으로 모든 곳에서 웹 구성 요소에 대한 지원을 추진하는 데 도움이 되는 고유한 위치에 있다고 생각합니다."라고 말했습니다. “거의 모든 프레임워크가 이제 웹 구성 요소 사양과 함께 작동할 수 있습니다. 적절한 구현의 문제일 뿐입니다.”

여러 참가자는 상호 운용성을 촉진하는 방식으로 사용자 지정 요소를 통신하는 데 있어 인기 있는 JS 프레임워크의 진행 상황을 표시하는 사이트인 custom-elements-everywhere.com을 참조했습니다. Matias Ventura는 React 및 Vue 핵심 개발자에게 웹 구성 요소(및 그 미래)가 현재 각 프레임워크에 어떻게 맞는지 물었습니다.

“React에서는 일부 웹 구성 요소 지원이 있지만 과거에는 사용 사례가 희박해 보였기 때문에 우선 순위를 크게 지정하지 않았습니다. 특히 웹 구성 요소를 추가하는 것이 여러분이 전체 스택을 제어합니다. 하지만 그럼에도 불구하고 우리는 이들을 지원하고 있으며 현재 또는 미래에 더 추가하는 것을 기쁘게 생각합니다.”라고 Sophie Alpert가 말했습니다.

Evan You는 "높은 수준에서 React/Vue와 같은 프레임워크는 웹 구성 요소에서 실제로 다루지 않는 기능, 즉 상태 변경에 반응하는 효율적이고 선언적인 DOM 업데이트를 제공한다고 생각합니다."라고 말했습니다. “이것이 WC 위에 Polymer가 존재하는 이유이기도 합니다. 저는 항상 상호 운용성 인터페이스로서 WC의 가치를 인정해 왔습니다.”

전반적으로 회의 참석자들은 존중하고 협력했으며 WordPress 기고자들이 프레임워크 선택 프로세스에서 최선의 방법을 찾는 데 도움이 되도록 자신의 전문 지식을 기꺼이 제공했습니다. 토론은 다음 주 회의에서 계속될 것이며 회의를 요약하는 다음 Make/Core 게시물의 코멘트에서 가능할 것입니다.