Gutenberg: Gutenberg를위한 JavaScript 프레임 워크 선택 (~ WordPress)

내 투표는 VueJS입니다.

나는 VueJS를 선택한다

Vue는 훌륭한 커뮤니티를 가지고 있으며 앞으로의 선택이어야합니다.

Angular JS

VueJS에 투표하겠습니다. 위에서 설명한 것처럼 초보자에게 친숙하며 Laravel에서 성공적으로 사용됩니다. 그것은 완벽한 선택입니다.

Vue JS에도 투표하겠습니다.

"I prefer Vue"또는 "I want XY"라고 외치는 것만으로는 여기서 결정을 내리는 데 도움이되지 않습니다. 투표를하고 싶다면 다른 프레임 워크를 평가할 때 결과를 문서화하는 장소 역할을 할 수있는 스레드를 복잡하게 만드는 대신 이모티콘 반응 또는 이와 유사한 것을 사용하는 것이 좋습니다.

Vue와 함께 갈 게요. 배우고 적응하는 것이 더 쉽습니다. 또한 Preact보다 논란이 적습니다.

때때로 발생하는 "핵심 사용자 의존성"문제에 대해 모든 WordPress 기능 플러그인 또는 알려지지 않은 기술이 무엇입니까? Koop은 오래된 미디어 처리를 구축했고 Weston은 수많은 Customizer 작업을 수행했으며 Matías와 몇몇 다른 사람들은 Gutenberg에서 작업하고 있습니다. 또는 그것을 이해합니다.

나는 이것을 잘못된 방식으로 볼 수 있지만 어떤 선택에 대한 "핵심 사람 의존성"은 붉은 청어처럼 보입니다. 채택을 통해 핵심 인력 의존성이 완전히 제거됩니다. WordPress는 한때 핵심 인물 (Mike 및 Matt) 의존성 프로젝트였습니다. 입양을 피하기위한 약한 주장이라고 생각합니다.

다시 말하지만, 나는 이것에 대해 완전히 잘못 생각할 수 있지만, 때때로 나타나는 생각의 공통된 실이며 겉보기에 높은 중요성을 이해하지 못합니다.

@swissspidy 의 댓글에

VueJS에 투표하겠습니다! 커뮤니티에서 적응하는 것이 가장 쉽습니다.

웹 구성 요소 (Polymer가 없지만 가상 DOM이 필요한 경우 lit-html 또는 이와 유사한 것)는 심각하게 고려해야한다고 생각합니다. 플랫폼과 표준을 사용하는 것은 어떤 라이브러리 나 프레임 워크보다 훨씬 낫습니다! 모든 프레임 워크와 자연스럽게 상호 운용 할 수있는 강력하고 미래의 안전한 구성 요소 구조를 만듭니다. (Vue, Angular, React-현재 다른 정도 : https://custom-elements-everywhere.com/)

• https://blog.revillweb.com/why-web-components-are-so-important-66ad0bd4807a
• https://medium.com/@velmu/go -long-on-web-components-b1e0689f64e4

필요한 경우 Vue 또는 웹 구성 요소를 사용해 보는이 프로젝트를 돕게되어 기쁩니다.

또한 Gutenberg에 대한 PR # 2463 _ "Framework-agnostic block interoperability (Vanilla, Vue)"_

몇 가지 이유로 Vue.js에 기대어 보는 것이 좋습니다.

1. PHP 프레임 워크 Laravel 내에서 입증 된 실적.
2. 더 많은 사람들이 기여할 수 있도록 픽업 및 채택이 쉬운 것 같습니다.
3. 우리가 React에서 멀어지면 깨끗하고 확실하게 멀어지게 만드십시오 (Preact를 사용하면 어떤 의미에서 (React)에 집착하는 것처럼 보입니다).

내 의견이지만 더 나은 선택 인 것 같고 다른 많은 사람들이 Vue를 선호하는 것 같으며 적어도 어쨌든 고려해야 할 사항입니다.

Vue는 Preact보다 더 큰 추진력과 더 나은 커뮤니티 지원을 제공하는 것 같습니다. (상태 관리와 함께 제공되기 때문에) 더 많은 문제를 해결하고 더 부드러운 학습 곡선을 가지고 있습니다. 문서는 _excellent_입니다.

Preact에 대한 나의 관심은 법적으로 안전하다고 느끼기에는 React와 너무 흡사하고 (React의 특허는 Preact를 포함 할 수 있음) React와는 달리 단순한 포트 (도우미 라이브러리, 플러그인 등을 깰 수있는 _ 충분한 차이가 있음)라는 것입니다.

Vue 끝까지 베이비 !!

• [x] [Gitlab] (https://about.gitlab.com/2016/10/20/why-we-chose-vue/)
• [x] [HN] (https://news.ycombinator.com/item?id=14410190)
• [x] [PixelJets] (http://pixeljets.com/blog/why-we-chose-vuejs-over-react/)

Github 별-> 여기
Vue.js 🖖이라면 WordPress 개발자에게 절대적으로 기뻐할 것입니다.

Vue는 시간이 지남에 따라 훌륭한 커뮤니티와 프레임 워크에 대한 정기적 인 업데이트 / 업그레이드를 개발했습니다.

추신. 멋진 커뮤니티 경험을 위해 https://chat.vuejs.org에 가입하세요.

@jbreckmckye 대화를 탈선시키려는 것은 아니지만 특허 조항이 무엇인지 이해합니까? 다른 회사의 특허 소송으로부터 페이스 북을 보호하는 것입니다. 예를 들어 우리 회사가 스마트 냉장고를 만들고 UI에서 반응을 사용한다고 가정 해 보겠습니다. 우리가 이것에 대한 특허를 가지고 있고 FB가 그 특허를 침해하기 시작한다고 가정 해 봅시다. 만약 우리가 소송을 제기하면 우리는 더 이상 반응을 사용할 수 없습니다.

반응하는 특허와는 아무 관련이 없습니다 (페이스 북이 ...

Vue.js 핵심 멤버로서 버스 팩터 문제를 해결하고 싶습니다. 우리는 이것이 현재 매우 제기 된 요점이라는 것을 알고 있으며, 이제 일부 우려 사항을 해결하기위한 조치를 취하고 있습니다.

1) npm 용 Vue.js 조직 계정으로 팀으로 더 쉽게 게시 할 수 있습니다.
2) 운영을 유지하기 위해 내부적으로 세부 정보를 관리 (웹 사이트 등)
3) 기여자를 유인하고 성장하는 커뮤니티를 지원하기 위해 개방형 집단을 시작합니다. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4) Vue 생태계가 빠르게 성장했으며 점점 더 많은 핵심 저장소 기여가 커뮤니티 자체에서 나옵니다. https://www.youtube.com/watch?v=993X1kiisFE
5) 공식 Vue 리포지토리를 살펴보면 실제로 많은 수의 리포지토리가 Evan보다 더 많은 다른 핵심 팀 구성원에 의해 관리되고 있음을 알 수 있습니다.

전체적으로 Vue.js는 빠르게 성장하고 있으며 '버스 팩터'가 크게 감소했습니다. @philiparthurmoore가 지적했듯이 Evan은 항상 큰 참여를 할 것이며 그것은 좋은 일입니다.

여기에 VueJS 팬이 많은 것 같습니다. 실제로 React에서 Vue로 대규모 코드베이스를 마이그레이션 한 사람이 있습니까? 마이그레이션 경로는 어떻습니까?

내가 볼 수 있듯이 Preact는 React와 API 호환이 가능하다는 점을 감안할 때 훨씬 더 실용적인 선택처럼 보입니다. Vue로 마이그레이션하려면 훨씬 더 광범위한 재 작성이 필요합니다.

@patrickgalbraith 사실 Preact를 고려하는 잘못된 이유입니다. 마이그레이션이 더 쉽기 때문에가 아니라 장점으로 판단해야합니다. Preact에서 다음 문제를 볼 수 있습니다.

• VueJS에 비해 더 작은 커뮤니티
• Code Smells — 매우 유사한 라이브러리로의 전환으로 인해 잘못된 사례가 발생할 수 있습니다 (더 빠른 경로라는 분명한 이유 때문).
• Preact를 고수하는 것은 어쨌든 React를 고수하는 것과 같습니다 (스레드에서 읽으십시오)

한정된 방식으로 만 프리 액트를 사용했기 때문에 이것이 바로 제 생각입니다.

@ blake-newman 들려 주셔서 감사합니다. 💯

마이그레이션이 더 쉽기 때문에가 아니라 장점으로 판단해야합니다.

예. 이것은 장기적인 결정입니다.

@patrickgalbraith 전체 프로젝트가 완료되면 공정한 주장이라고 생각합니다. 라이센스 문제를 피하기위한 마이그레이션 부분이기 때문입니다.

프로젝트가 아직 초기 단계이므로 @ahmadawais 는 문제가 적습니다.

또한 Vue, React 및 Preact는 매우 유사한 패러다임을 가지고 있습니다. 둘 사이를 쉽게 전환 할 수 있으며 차이점이 있습니다.

이 경우에는 완전히 실용적이지는 않지만 마이그레이션 평화를 도울 수있는 도구도 있습니다. https://github.com/SmallComfort/react-vue

동일한 도구를 비교하지는 않지만이 기사에서는 고려해야 할 중요한 사항을 제시합니다. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ blake-newman 개발에 6 개월 이상 걸린다는 점을 고려할 때 실제로 초기 단계입니까? 또한 Calypso는 2 년이 넘었습니다.

어쨌든 나는 당신이 React와 Vue 사이를 전환하는 것이 쉽다고 말한 것을 감안할 때 문제가되지 않을 것이라고 확신합니다.

스텐실도 유망 해 보입니다.

https://github.com/ionic-team/stencil-starter

내 의견은 다음 두 가지 사항이 Vue에 대한 강력한 사례를 만든다는 것입니다.

• 초보자 친화적이고 ..
• 엄청난 양의 커뮤니티 지원

제 생각에는 둘 다 WordPress 프로젝트의 핵심 기둥 중 두 가지입니다.

나는 혼자 일지 모르지만 지난 6 개월 동안 Evan의 Patreon을 꽤 면밀히 지켜 봤고, 그가 그것을 통해 자금을 얻지 못하면 더 많은 일을해야 할 것이라고 읽었습니다.

프로젝트의 자금이 적고 기본적으로 한 사람이 작성하면 (6 개월 미만 전) 실제 위험이됩니다. 그의 Patreon 번호는 실제로 최근에 감소했습니다. 주인공이 재정이 맞지 않으면 일을 할 수 없을 수도 있다고 말하면 재정이 매우 위험합니다. 하나의 (멋진) 개발자가 SF 임대료를 지불 할 수 있는지 여부에 의존하는 대규모 장기 프로젝트의 프레임 워크 선택은 큰 문제입니다.

물론 Vue는 다른 회사에서 아낌없이 지원할 수 있지만 그것을 알기가 어렵습니다.

커뮤니티 채택은 프레임 워크 수명을 보장하지 않습니다. 눈치 채지 못했다면 프레임 워크는 항상 '죽습니다'.

즉, 핵심 Vue 팀의 구성원이 실제로 단독 기여자 문제 / 버스 요인을 이름으로도 해결하기 위해 나타나서 단일 개발 문제가 문제가되지 않을 수있는 몇 가지 이유를 제시 한 것에 깊은 인상을 받았습니다. 그러나 그것은 아주 최근에 진짜 문제였습니다.

나는 Vue에 투표한다

• 간단한 API / 일주일 이내에 가장 기본적인 것을 배울 수 있습니다.
• vuex를 통한 간단한 플럭스 구현
• 빠른 결과 : P
• 성장하는 커뮤니티
• MIT

위에 언급 된 모든 이유로 Vue에 대한 또 다른 투표. 메일 알림이 활성화 된 사람에게 사과드립니다!

@ michaelbdavidson7 , Vue는 궁극적으로 Evan의 의견을 갖게 될 것이며 Patreon 캠페인은 그가 더 훌륭한 Vue 작업을 수행하도록 지원하는 것이 었습니다. 그는 Patreon을 통해 충분하지 않고 다른 작업을 수행하는 것이 Vue를 위태롭게한다고 생각하지 않습니다. @ blake-newman (핵심 Vue 기여자)이 제안했듯이 (그리고 몇 달 전 Evan 자신도) Vue는 더 이상 한 사람에게만 의존하지 않습니다. WordPress는 한 사람에게 의존하지 않습니다. 우리는 Matt를 가지고 있습니다. 그러나 WordPress는 Matt 없이도 일부 화신을 계속할 수 있습니다. Vue도 마찬가지입니다 (Evan;)).
@ahmadawais 도 "핵심 인 의존성"에 관해서는 정확하지 않다고 생각합니다.

이 목표가 충족되면 개인 수익 창출 채널 (예 : 지원 / 컨설팅 계약)에 대해 생각하는 시간을 줄이고 대신 전체 Vue 커뮤니티에 도움이되는 콘텐츠에 대해 더 많이 작업 할 수 있습니다.

^ 그 목표는 달성되지 않았고 가깝지도 않았습니다. 그가 여전히 계약에 대해 생각하고 있다고 말한 것을 의미한다고 가정하고 그것이 변경되면 그것은 매우 최근의 발전으로 간주되어야합니다. 지금은 아직 거기에 있습니다. 핵심 담당자가 임대료를 지불하기로 계약하는 경우 프레임 워크에서 작업을 계속하지 않을 위험이 있으며 변경된 경우 최근에 변경되었습니다.

이름으로 프레임 워크를 외치는 여러분 모두 지난 몇 년 동안 아무것도 배웠습니다.

@ michaelbdavidson7 에반이 풀 타임으로 작업 할 수 있도록 목표를 달성했습니다. 추가 목표는 그를 더 멀리 그리고 부분적으로 지역 사회를 지원하는 것입니다. 따라서 커뮤니티를 지원하는 유일한 목적을위한 개방형 공동 캠페인의 탄생입니다.

나는 또한 Patreon 캠페인이 기부를 통한 유일한 수입원이 아니라는 점을 지적 할 것입니다. 안타깝게도 Patreon은 모든 회사가 후원하기에 적합하지 않습니다. 따라서 일부 기부금은 별도로 지급되고 청구됩니다.

숫자가 감소한 이유는 스폰서 중 한 명이 중국 출신이고, 중국에서 연간 지출 할 수있는 금액에 제한이 있기 때문입니다. 이것은 일시적인 것이며 다시 지원할 것입니다.

에반이 워크숍을 통해 얻는 다른 수입 채널은 공동체에 도움이 될뿐만 아니라 그에게도 도움이됩니다. 이런 식으로 그는 도서관이 어떻게 사용되고 사용되는지 배우는 데 직접 노출 될 수 있습니다. 따라서 실제로 보이는 것만 큼 나쁘지는 않습니다.

Vue는 지속 가능하며 Evan을 대신하여 말하지는 않지만 그가 현재 재정 상황에 매우 만족하고 있다고 확신합니다.

내가 React에 대해 감사 한 것은 접근성 문서 였습니다. 저는 이것이 새로운 프레임 워크에 대해 생각할 때인지하고 고려해야 할 사항이라고 생각합니다. 방어 적으로 작성된 모든 웹 앱에 적용되는 접근성 원칙이 여기에 언급되어 있지만 일부 프레임 워크 별 문서가 있으면 도움이 될 수 있습니다.

Vue.js에는 접근성에 대한

궁극적으로 a11y에 대한 프로그래밍 방식 테스트를 간단하고 자동으로 만드는 프레임 워크가 있으면 대부분의 a11y 오류와 경고를 제거 할 수 있습니다.

라이선스 때문에 쉽게 전환하고 싶다면 InfernoJS를 고려할 수 있습니다. https://github.com/infernojs/inferno 더 작은 풋 프린트와 더 빠른 런타임으로 동일한 API에 가깝습니다. 그것의 MIT 라이센스. 저는 Inferno의 유지 관리자 중 한 명이며 전환을 도울 수 있습니다.

@Havunen에 들러 주셔서 감사합니다. 요 전에 Inferno를 조사하고 있었지만 아직 시도하지 않았습니다. 어쨌든 유망 해 보인다!

맥락을 위해 Inferno의 저자는 Facebook에 고용되었습니다.

나는 markoJS http://markojs.com/에 투표합니다

Gutenberg는 Inferno와 Preact 모두 지원하지 않는 몇 가지 새로운 React 16 기능 (예 : Portal 및 Fragments )을 사용하므로 이러한 기능의 사용이 구텐베르크에 중요한 경우 React와 유사한 libs에 대해 이야기 할 때 고려할 수 있습니다.

API 측면에서이 시점에서 React 16과 가장 가까운 DIO 8을 제안합니다.

즉, 언급 된 React-like libs에 별칭을 지정하여 Gutenberg를 설정하고 기꺼이 변경 / 문제없이 작동하는지 확인하는 것은 좋은 호기심 실험이 될 수 있습니다.

정확히 동일한 지 확실하지 않지만 포털의 경우 vue 핵심 팀 구성원 중 한 명인 @LinusBorg가 개발 한 vue-portal이 있습니다. :)

@youknowriad 저는 페이스 북에 고용되었습니다. @Havunen 과 Inferno 팀은 저 없이도 훌륭한 일을하고 있습니다. 그들이 Inferno에서하고있는 작업은 굉장하며 기회가 있다면 Inferno를 확인해 볼 가치가 있습니다. :)

저는 Marko.js 의 저자 중 한 명이며 Marko.js를 고려할 수 있도록 링에 던지고 싶습니다. 많은 커뮤니티 회원이 우리에게 연락하여이 GitHub 문제를 지적했습니다. Marko.js는 오픈 소스 친화적 인 MIT 라이선스를 가지고 있으며 eBay.com을 구축하는 데 사용되고 있으며 강력하고 성장하는 커뮤니티를 보유하고 있습니다. React와 Vue에서 좋은 아이디어를 많이 가져 왔지만 컴파일 타임 최적화를 통해 더 간단하고 빠르게 만들기 위해 많은 노력을 기울였으며 가능한 한 상용구를 제거했습니다. 아래의 몇 가지 기능을 강조하고 싶었습니다.

UI 구성 요소

Marko의 컴포넌트 모델은 개념적으로 React와 매우 유사합니다 (입력, 상태, 이벤트 바인딩, 라이프 사이클 이벤트, 가상 DOM 렌더링, DOM 비교 / 패치 등). Calypso의 전환에는 많은인지 오버 헤드가 필요하지 않습니다. Marko는 단일 파일 UI 구성 요소도 지원합니다. Marko UI 구성 요소는 다음과 같습니다.

class {
  onInput(input) {
    this.state = { 
      count: input.count || 0 
    };
  }
  increment() {
    this.state.count++;
  }
}

style {
  .count {
    color:#09c;
  }
}

<div.count>${state.count}</div>
<button on-click('increment')>
  Click me!
</button>

통사론

Marko는 JSX를 사용하지 않지만 JS 표현식을 지원하는 HTML의 상위 집합입니다. HTML과 매우 유사하지만 Vue와 같은 방식으로 HTML에 완전히 제한되지는 않습니다. 이것은 루프 및 조건과 같은 것에 대해 더 좋은 구문을 제공하고 표준 HTML 문자열에 비해 표현식이 사용되는 위치를 더 명확하게합니다. Marko.js 템플릿은 매우 읽기 쉽고 유지 관리가 용이하다고 생각합니다 (Marko는 간결한 들여 쓰기 기반 구문도 지원합니다).

서버 측 렌더링

WordPress에 얼마나 중요한지 모르겠지만 Marko는 비동기 및 스트리밍 렌더링을 지원하는 Node.js에서 고성능 서버 측 렌더링도 지원합니다.

추가 읽기 :

• Marko 대 React
• Marko, Preact, Rax, React 및 Vue를 사용한 서버 측 렌더링 슛 아웃
• Marko가 빠른 이유는 무엇입니까?
• 10 가지 놀라운 Marko 기능
• Meetup : UI 구축-React, Vue 및 Marko의 비교 (Marko 작성자)- 비디오 | 슬라이드

나는 Marko에게 투표한다 !! 🙂

WordPress 팀 (@ahmadawais? @m? @swissspidy?)의 누군가가 Marko에 대한 질문에 답변하기 위해 빠른 채팅을 원하면 Marko 팀이 기꺼이 그렇게 할 것입니다. : call_me_hand : 😸

@I는 @m의 블로그에 댓글을 달았습니다,하지만 더 공개 형태로 여기에 게시하고 싶었 :

Ember와 Glimmer.js를 포함한 Ember 생태계를 추천합니다.
드롭 인 편집기 및 기타 콘텐츠 동작과 같은 소규모 웹 구성 요소의 경우 Glimmer는 훌륭한 경험을 제공하고 프레임 워크 외부에서 실행할 수있는 웹 구성 요소를 드롭합니다.

라우팅, 복잡한 상태 관리, 액세스 제어, 콘텐츠 관리 등이 필요한 Guttenberg 및 Calypso와 같은 대규모 프로젝트의 경우 : Ember는 최고의 도구 세트와 생태계를 제공합니다.
많은 기여자들과 함께 : Ember의 세트 패턴, 애드온 및 빌드 시스템은 애플리케이션이 확장됨에 따라 애플리케이션의 성능을 유지하고 유지 관리 할 수 ​​있도록 도와줍니다.
Ember 엔진 및 리포 내 애드온은 애플리케이션의 선택적 부분을 모듈 형으로 유지하고 최종 사용자가 설치할 수 있도록 도와줍니다.

Ember는 다른 콘텐츠 관리 시스템에서 많이 사용되고 있으며 이러한 노력을 바탕으로 학습하고 공유 할 수 있습니다.
@m 블로그의 이전 댓글에서 언급했듯이 Ghost 는 관리자 및 편집자로 Ember를 사용하지만 Ember는 Drupal 헤드리스, Cardstack 및 Conde Nast , Bustle 등과 같은 콘텐츠 회사에서도 사용됩니다.
즉, 태그 목록, 구성 요소 기반 편집기 (특히 Mobiledoc 편집기 ) 등과 같은 일반적인 기능이 Ember Addon 에코 시스템의 일부로 제공됩니다.

커뮤니티 및 개발자 경험에서 Ember는 Wordpress 에코 시스템과 가장 잘 어울립니다 (Wordpress에서 5 년 이상 일한 개발자로서).
Ember는 내장되어 있거나 잘 문서화되어 있거나 애드온을 통해 사용할 수있는 많은 모범 사례를 가지고 있습니다. 이렇게하면 "내 앱에서 작동 할 것인가"라는 질문이 줄어들고 가능한 보안 또는 성능 버그를 더 효과적으로 줄일 수 있습니다.
Ember는 사용자 정의 가능한 추상화를 기반으로하여 최종 개발자로부터 복잡성을 추상화 할 수 있고 어려운 코드의 범위를 제한하여 사용자 정의를 쉽고 재미있게 할 수 있습니다.
Ember 애드온은 Wordpress 플러그인과 테마가 자동으로 검색되고 기본 구성이 기본 구성되어 있기 때문에 거의 일치하지만 최종 사용자의 요구를 충족하도록 추가로 사용자 정의 할 수 있습니다.
가장 인기 있고 가장 잘 유지되고 가장 안정적인 애드온을 찾는 데 도움이되는 Ember Observer 라는 Ember 애드온에 대한 기존 큐 레이션 도구가 있습니다.

Calypso와 Guttenberg는 성숙한 요구를 가진 크고 야심 찬 프로젝트입니다. Ember 커뮤니티에는 접근성, 국제화 및 최신 웹 애플리케이션의 기타 요구 사항에 대한 성숙한 솔루션이 있습니다.

저는 Ember.js 학습 팀의 일원이며 핵심 기여자들과 긴밀히 협력하고 있습니다. Ember 및 Glimmer가 귀하의 필요에 어떻게 부합 할 수 있는지에 대해 다른 Ember 팀원들과 이야기하거나 대화를 나누고 싶습니다.

React 포털에 대한 언급이 있다는 것을 알았고 Ember에는이 기능을 제공하기 위해 Ember Wormhole 이라는 잘 유지 관리되는 애드온이 있으며 대화 상자, 문서 헤드 변경과 같은 기능을 제공하기 위해이 위에 많은 애드온이 빌드된다는 또 다른 2 ¢를 추가하고 싶습니다. , 그리고 더.

Marko가 네이티브 비동기 렌더링 지원과 빠른 서버 측 성능에 투표했습니다. !!!

@ patrick-steele-idem & @mlrawlings —

더 자세히 살펴 보겠습니다.

저는 앱이 다른 앱 내에서 실행되는 대규모 엔터프라이즈 조직과 소규모 독립 실행 형 애플리케이션이있는 소규모 스타트 업에서 모두 Ember.js와 함께 작업했습니다. Ember.js의 강력한 의견과 관습은 팀과 애플리케이션이 성장함에 따라 생산적이고 유지 가능한 코드베이스를 유지하는 데 도움이되었습니다. 프로젝트간에 코드 (엔진 또는 애드온을 통해)를 공유 할 수있을뿐만 아니라 규칙을 배운 개발자가 거의 모든 Ember 애플리케이션에서 생산성을 발휘하고 기여할 수 있습니다.

Ember의 가장 큰 장점은 정체없는 안정성입니다. 템플릿을 변경할 필요없이 우리는 렌더링 엔진을 완전히 리팩토링 한 새 버전의 Ember가 출시되었을 때 엄청난 성능 이점을 얻었습니다. 추상화 수준은 성장하고 먼 미래로 확장해야하는 최신 리치 웹 애플리케이션에 적합합니다.

변경이 필요한 경우 마이그레이션이 핵심 관심사이며 지원 중단 가이드가 모든 단계에 도움이됩니다 (가장 최근에는 JavaScript AST / CST 변환을 사용하여 애플리케이션을 자동으로 업그레이드 함).

@rtablada가 언급하지 않은 Ember를 사용하는 다른 인기있는 웹 응용 프로그램에는 Twitch.tv , Heroku 대시 보드 , Travis CI 및 Discourse가 있습니다.

@SaladFork 업데이트에 감사 드리며, 콘텐츠 관리 분야의 대부분 회사 이름으로 시작했습니다.

대규모 오픈 소스 Ember 애플리케이션의 몇 가지 예는 다음과 같습니다.

• 트래비스 CI
• Hospital Run- 특히 아프리카의 낮은 연결성에서 오프라인 사용을 위해 구축 된 EMR (전자 의료 기록) 시스템
• 유령

그가 얼마나 자세히 설명 할 수 있을지는 모르겠지만 , 그가 최근 React에서 Ember로 앱을 전환 한 팀의 일부를 공유 할 수 있는지 확인하기 위해 보냅니다 .

성능, 유연성 및 매우 명확하고 이해하기 쉬운 구문으로 Marko에 투표하겠습니다!

Marko도 +1합니다. 내가 머리카락을 잃고 회색으로 변하기 시작하기 전에 프론트 엔드 작업을 잘 해왔 기 때문에 (오래 전처럼) 내가 수년 동안 찾아 왔던 프론트 엔드 프레임 워크 / 라이브러리였다. 이것이 내가 eBay에서 @ patrick-steele-idem & @mlrawlings 와 함께 일하는 것을 좋아하는 큰 이유입니다.

Marko JS가 투표했습니다. 사용 용이성과 성능을 고려할 때 매우 과소 평가되었습니다.

효율적인 marko와 함께 marko-widget을 좋아합니다. 단순히 뛰어나고 간결한 프레임 워크. 다른 프레임 워크보다 더 빠릅니다. 벤치 마크는 여기

나는 MarkoJS에 투표했고, 우리는 수년 동안 핸들 바 가게였습니다.

마이크로 서비스로 이동하고 플랫폼에 대한 구성 요소 기반 아키텍처를 활성화하기위한 전략적 움직임을 만들었을 때 서버 측 렌더링과 클라이언트 렌더링이 균형을 이루는 올바른 프레임 워크를 찾고있었습니다. 우리는 데이터가 큰 관심사 인 남아프리카 및 멕시코와 같은 신흥 시장을 포함하여 6 개의 다른 시장에서 분류 한 플랫폼이며, 몇 년이 지나도 적은 데이터. 또한 사용자는 자신이 구매하고 싶은 항목을 찾을 때까지 사이트를 앞뒤로 탐색 할 것입니다. 즉, 사용자가 탐색 할 때 정말 빠른 서버 렌더링이 발생해야합니다.

신중한 고려 끝에 MarkoJS가 지원하는 사실을 선택했습니다.

1. 우수한 서버 성능으로 빠른 서버 렌더링
2. 가능한 한 빨리 첫 번째 바이트를 푸시합니다.
3. 데이터가 준비 될 때 사소한 구성 요소를 빌드하고 비동기 적으로 렌더링하는 기능
4. 플러그 앤 플레이 구성 요소 아키텍처 구축 능력
5. React / Vue의 동일하거나 더 나은 아키텍처로 클라이언트 렌더링을 최대화합니다.
6. 렌더링 테스트뿐만 아니라 구성 요소 상태에 사용할 수있는 구성 요소 기반 테스트

(eBay Classifieds의 성공 사례)

Angular의 경우 +1 (AngularJS가 아님).

Angular CLI는 모든 프레임 워크 중에서 가장 뛰어나며, 버전 간 원활한 마이그레이션을위한 마이그레이션 계획이 있으면 매우 적합합니다.

Plus Angular는 엔터프라이즈 영역에서 잘 채택되어 WordPress가 컨설턴트와 프리랜서의 플랫폼으로 계속 성장하고 바닥을 향한 경쟁을 중단한다면 WordPress가 약간의 사랑을 사용할 수 있습니다.

모든 수준의 강력한 개발자 커뮤니티가 있습니다. 핵심 팀은 항상 Google에서 일하는지 여부에 대해 이야기하는 것이 좋습니다. WordPress는 대부분 (대부분의 고급 개발자에게) 참여하는 커뮤니티이므로 커뮤니티 현명한 Angular는 매우 적합합니다.

최근에 Vue in Server-Rendered Environments에 대한 강연을했고 ( 여기 슬라이드 ), 지난 몇 달 동안 .NET 환경에서 Vue와 함께 작업 한 적이 있습니다. 환경에서 작업 할 수있는 다른 옵션이 없다고 확신합니다. 그렇게. 백엔드가 대부분 사이트를 계속 제어 할 수 있도록 허용하면서 무거운 상호 작용을 위해 JS로 가져와야하는 것을 구성 할 수있는 정말 훌륭한 조합을 얻게됩니다.

즉, WordPress가 현재 가지고있는 것을 기반으로 구축하기에 매우 완벽합니다. 다른 서버 렌더링 JS 라이브러리에는 대부분 노드가 필요합니다. Vue는 그렇지 않습니다. <gutenberg-editor> 와 같은 구성 요소를 등록하고 WordPress에서 문자 그대로 HTML로 <gutenberg-editor> 를 보내도록 할 수 있습니다. Vue는 WordPress에서 보낸 HTML을 사용하여 페이지를 부트 스트랩 할 수 있습니다. 그 점에서 웹 구성 요소와 비슷하며 서버 렌더링을 얻기 위해 다른 BE 기술이 필요하지 않습니다.

Laravel과 같은 프레임 워크가이를 기본값으로 선택한 이유 중 하나입니다. 비 노드 백엔드에 통합하기가 매우 쉽습니다. WordPress도 같은 이유로 채택해야한다고 생각합니다.

나는 Vuejs에 투표했다.
그의 의견에 @borantula 와 같은 경우

저의 CTO는 Vuejs를 팀에 소개했습니다. Front-end를 처음 접한 사람들이 바로 Vuejs에 합류하여 Vuejs에 만족하고 있습니다. 우리 팀은 많은 프로젝트에서 WordPress를 사용합니다.
현재 우리는 Vuejs와 Custom Element를 사용하여 백엔드에서 WordPress를 사용하는 프로젝트의 프런트 엔드를 만들고 있습니다. 매우 원활하게 작동합니다.

@ blake-newman과 Evan이 말했듯이 Vuejs는 더 이상 단일 핵심 사람에게 의존하지 않으므로 @ahmadawais가 언급 한 CONS가 더 이상 존재하지 않는다고 말할 수 있습니다.

MARKO는 웹 앱에서 잘 작동합니다. 프로그레시브 렌더링은 매력처럼 작동합니다.

Preact 또는 MarkoJS (주석에서 많이 언급 됨)에 대해서는 아무 말도 할 수 없지만 1 년 전에 Vue 팀에 소개 (주로 당시 php + jQuery 작업)하면서 Vue에 대해 이야기 할 수 있으며 점차적으로 자바 스크립트에 대한 이해가 바뀝니다. jQuery 상태에서 벗어나기.

구텐베르크뿐만 아니라 워드 프레스의 장기적인 목표 인 인터페이스에 자바 스크립트가 더 많은 API 지향 플랫폼으로 전환하는 것이 좋은 선택이라고 생각합니다. 더 쉬운 학습 곡선과 친숙 함은 다른 WP 개발자도 참여하도록 장려합니다.

저는 VueJS가 Laravel 커뮤니티에서 어떻게 번창하는지 보았고 거의 대부분의 사람들에게 사실상의 선택이되었습니다. WordPress 커뮤니티에서도 그렇게 될 것이라고 믿습니다.

Backbone.js

/에스

저는 MarkoJS 뒤에 저의 지원을 던지고 싶었습니다.

2 년 전에 회사 인프라를 ExpressJS 및 Jade (현재 PUG)에서 Marko JS로 옮겼습니다. 우리 회사는 전체 생태계에서 복잡하고 재사용 가능한 구성 요소를 만들고 싶었습니다. 개발자들은 속도와 재사용 성을 원했습니다. 설계자들은 감소 된 설계 부하를 원했습니다. 우리는 그 이후로 돌아 보지 않았습니다.

이제 Marko로 작성된 여러 클라이언트 대면 웹 사이트와 전체 CMS 시스템도 있습니다.

궁극적으로 다음을 위해 MarkoJS를 선택했습니다.

• Koa 및 또는 ExpressJS와 같은 프레임 워크에서도 빠른 서버 렌더링
• 페이지 데이터의 비동기 렌더링 처리
• 더 큰 에코 시스템을위한 플러그 앤 플레이 구성 요소를 구축하는 기능
• React / Vue보다 더 나은 성능
• 매우 쉬운 템플릿 구문

또한 MarkoJS 팀이 말 그대로 우수하다는 점을 지적하고 싶습니다. @ patrick-steele-idem 및 @mlrawlings 는 항상 새로운 아이디어를 도입하고 문제를 해결하며 개인을 돕기 위해

👍 MarkoJS 용

Preact는 React-API 호환 라이브러리로, Preact는 React의 에코 시스템과 사용 가능한 많은 OSS 패키지 / 구성 요소로부터 직접 혜택을받습니다. Vue의 에코 시스템은 비교해 볼 때 훨씬 작습니다. 타사 Vue 패키지 / 구성 요소에 대한 설명서는 중국어로되어 있습니다.

더 이상 "나는 XYZ에 투표"하지 마십시오. 그들은이 문제를 구독하는 사람들에게 불필요한 답장을 보내는 것 외에는 대화에 추가 할 일이 없습니다.

🔥 각도

• PRO : React의 가장 큰 경쟁자
  많은 사람들에게. 질문은 종종 "Angular 또는 React?"입니다. / "반응 또는 각도?". Angular 커뮤니티는 React 대안 중에서 가장 크고 빠르게 성장하고 있습니다.

• 장점 : 많은 학습 리소스
  공식 API 문서 및 가이드 외에도 Angular는 모든 주요 학습 플랫폼에서 무료 및 상업적인 교육 자료, 블로그 게시물, 서적 및 많은 많은 비디오 코스로 구성된 가장 큰 에코 시스템과 워크숍 및 컨퍼런스에서이를 가르치는 Google GDE를 보유하고있을 것입니다.

• PRO : Redux와 잘 통합
  직접 또는 RxJS 권한 부여 Ngrx를 통해 (Angular 팀 구성원 지원)

• PRO : 동급 최고의 도구 지원

  • CLI에는 다른 것보다 훨씬 많은 기능이 있습니다.

  • 특히 언어 서비스와 함께 VS Code에서 매우 우수한 편집기 지원

  • TypeScript 용으로 작성되었으며 최상의 TypeScript 경험을 제공합니다.

• PRO : 기능이 풍부하고, 의견이 많으며, 기본적으로 구성됨
  Angular 모듈 (NgModule)을 통한 논리적 분리와 양식, HTTP 호출, 라우팅 등에 대한 표준 기능은 다른 개발자가 코드를 더 쉽게 읽고 기여할 수 있도록합니다.

• PRO : RxJS와 최고의 통합
  일반적으로 많은 API 스트림 및 한 페이지의 많은 이벤트 스트림에 유용합니다.

• PRO : 내장 DI (종속성 주입) 시스템
  특히 RxJS와 결합 된 경우 확장 성 지점 및 플러그인 시스템을 만드는 데 유용합니다.

• 장점 : 다른 라이브러리에서 다루는 다른 많은 상자를 표시합니다.

  • 허용 라이센스가있는 UI 라이브러리
    PrimeNg, Angular Material 2, ngx-bootstrap 등이 있습니다.

  • 지연 로딩
    지연로드 경로에 대한 기본 지원 및 수동으로 지연로드 모듈도 지원

  • 구성 요소 별 CSS
    CSS 범위가 구성 요소로만 지정되고 구성 요소가로드 될 때만로드되며 전역 CSS에 대한 후크가 있는지 확인합니다.

  • 서버 측 렌더링
    이미 Node 및 ASP .NET Core로 작업하고 있으며 요즘 더 집중하고 있습니다.

  • 테스팅
    Angular는 단위 테스트를 매우 쉽게 만드는 단위 테스트 프레임 워크에 구애받지 않는 테스트 도우미를 제공합니다. Jest로 쉽게 전환 할 수있는 Jasmine을 사용하여 CLI에서 기본적으로 테스트를 생성합니다. 그들은 또한 E2E 테스트를 더 쉽게 만들기 위해 선택적인 Selenium wrapper Protractor를 제공합니다 (실제로 필요하지는 않지만 Angular 앱에 Selenium .NET을 사용합니다. Angular와 관련이 없지만 더 쉽게 만들려고 노력합니다).

  • 모바일 / PWA 지원
    Google은 PWA의 가장 큰 지원자이며 서비스 워커와 유니버설 (서버 측 지원), Ionic (Cordova 지원) 및 NativeScript (네이티브 앱)를 통해 이미 Angular CLI에 지원이 표시되고 있습니다.

• PRO : 브라우저 지원에 집중
  문서에 전용 폴리 필 페이지가 있고 CLI에 기본적으로 폴리 필을 삽입 (주석 처리 된)하는 Angular는 IE <= 11에 필요한 정확한 폴리 필의 루프를 유지하므로 훨씬 더 큰 폴리 필을로드 할 필요가 없습니다. 이유없이 설정됩니다. 브라우저 지원에 관심이 있기 때문입니다.

• 장점 : 대기업 지원
  Angular는 대기업에서 지원하는 몇 안되는 라이브러리 중 하나입니다.
  여기를 지원함으로써 몇 가지 프로젝트에서이를 사용하고 생태계에 다시 기여한 회사가 아니라 개발자와 기술 작성자에게 풀 타임으로 일하고 커뮤니티 리더 (이 경우 GDE 및 DevRel)에 투자하는 공식 유지 관리자가됩니다. Google의).
  이것은 추가 조항, 해지 메모 또는 일부 사람들에게 혼란 스럽거나 두려울 수있는 기타 사항이없는 MIT 라이센스와 함께 제공되기 때문에 PRO가 아닙니다.

플러그인, REST API와 같은 일부 프로젝트에 대해 Vuejs 를 구현

요즘 Vuejs는 빠르게 성장하고 있습니다. Vuejs 가 WordPress 코드에 통합되면 현명한 선택이 될 것입니다.

@cyberwani @thephilip @evoratec 및 기타.

@ntwb 는 이미 다음 댓글에 답장했습니다.

더 이상 "나는 XYZ에 투표"하지 마십시오. 그들은이 문제를 구독하는 사람들에게 불필요한 답장을 보내는 것 외에는 대화에 추가 할 일이 없습니다.

그러니 쓸모없는 말은 그만해주세요. 지원을 보여주기 위해 github 이모티콘을 사용하여 라이브러리를 선호하는 댓글에 좋아요를 표시 할 수 있습니다.

Vue.

그런데 현재 Vue 뒤에 Alibaba가 있으며 모바일에서 Vue API를 사용할 수있는 Weex Apache 프로젝트도 있습니다.

난 정말 여기에 약간의 절제를 넣었 어, 분명한 논쟁없이 너무 많은 팬 보이들

이것은 마지막 경고입니다. 다음 단계는 댓글 삭제를 시작하는 것입니다.

저, 저는 Marko, Preact 또는 Vue.js를 사용하지 않았습니다. 솔직히 말해서 그들 중 어느 것도 익숙하지 않습니다. 워드 프레스 커뮤니티가이 프레임 워크에 대해 말하는 것을 듣고 읽고 싶습니다. 그들 각각, 각각의 기술적 장점, 각각의 주변 생태계, 빌드 도구, 그리고 마지막으로이 프로젝트 뒤에있는 사람과 커뮤니티. 😄

"내 투표는 XYZ에 대한 것입니다"를 읽고 싶지 않습니다. 투표를 추가하려면 위로 스크롤하여 이미 위에서 언급 한 선택한 프레임 워크에 이모티콘 _ 좋아요 _ 반응을 추가합니다. 👍

이전 댓글 이후 두 개의 새 댓글이 표시되는 데 오래 걸리지 않았습니다 .😞

이를 위해 ... https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942 이후에 댓글이 추가되었고 _ "나는 XYZ에 투표합니다"_ 또는 그에 대한 텍스트 만 있으면 귀하의 댓글이 삭제 될 가능성이 매우 높으면 동일한 ilk의 향후 댓글 도 삭제됩니다 .

이 문제로 돌아가서 댓글이 삭제 된 이유가 궁금하다면

@ahmadawais 몇 가지 의견이 있습니다.

구텐베르크의 React에서 ...?

에 관해서:

@patrickgalbraith 사실 Preact를 고려하는 잘못된 이유입니다. 마이그레이션이 더 쉽기 때문에가 아니라 장점으로 판단해야합니다. Preact에서 다음 문제를 볼 수 있습니다.

• VueJS에 비해 더 작은 커뮤니티
• Code Smells — 매우 유사한 라이브러리로의 전환으로 인해 잘못된 사례가 발생할 수 있습니다 (더 빠른 경로라는 분명한 이유 때문).
• Preact를 고수하는 것은 어쨌든 React를 고수하는 것과 같습니다 (스레드에서 읽으십시오)

사소한 줄의 코드가있는 프로젝트가있을 때는 매우 조심해야한다고 생각합니다. 엔지니어는 무언가를 다시 작성하고, 새로운 언어와 프레임 워크를 배우고, 해당 코드를 다시 작성할 수 있다면 더 나은 일을 할 것이라고 생각합니다. Joel은 아주 오래 전에 재 작성의 위험에 대해 말했습니다 .
Preact를 사용하면 많은 시간을 절약 할 수 있습니다. 완전히 새로운 프레임 워크로 이동하는 데 걸리는 시간을 과소 평가할 수 있습니다. 나는 당신이 "사실 Preact를 고려하는 잘못된 이유입니다"라고 쓴 이유를 잘 모르겠습니다. 엔지니어로서 솔루션을 평가하고 선택하는 데 사용하는 기준 목록에서 비용과 출시 시간이 높습니다.
문제가 실제로 Facebook 특허라면 Preact는 비용을 최소화하면서 문제를 해결합니다. Preact는 React 및 Vue보다 더 성능이 뛰어납니다 : 더 작은 풋 프린트와 더 빠른 런타임 렌더링. Addy Osmani의 글 도 확인하십시오.

Preact 커뮤니티의 규모를 어떻게 평가 하셨는지 잘 모르겠습니다. 생태계와 사용 가능한 구성 요소에 대해 이야기하고 있다면 Preact를 사용하면 React의 오픈 소스 구성 요소 대부분을 사용할 수 있습니다. 따라서 실질적인 문제를 위해 Preact에서 명시 적으로 작업하지 않더라도 여전히 활용할 수있는 코드를 생성하는 사람들이 있습니다. 여전히 React의 생태계를 Preact 생태계의 일부로 고려할 수 있습니다.

Vue가 여전히 선호하는 옵션 인 이유는 무엇입니까?

여기서 세 번째 요점은 "Preact로 고정하는 것은 어쨌든 React를 고수하는 것과 같다"는 것이 Preact를 선택하는 것을 주저하는 주된 이유 일 것입니다. 내가 잘못? 특허 외에 React의 문제점은 무엇입니까?

큰 그림을 보면서

구텐베르크를 위해 선택한 모든 것이 칼립소에도 사용될 것이라고 읽었습니다.
Gutenberg는 프론트 엔드에서만 React를 사용하고 있습니다. 서버 측 렌더링을 보면 상황이 더 복잡해 지지만 Preact는 여전히 더 쉬운 마이그레이션 옵션으로 보입니다.

기준을 봐야한다고 생각합니다. 재 작성을 진지하게 고려하고 동형 렌더링을 유지하는 것이 중요 하다면 MarkoJS 가 후보 목록에서 높은 것으로 보입니다.

처음부터 시작하여 React 생태계를 무시하고 싶다면 MarkoJS는 생각할 필요가 없습니다.

공연을보고 있는데 MarkoJS는 라이벌이없는 것 같습니다 . React보다 40 배 빠르며 Vue보다 6 배 빠릅니다. 내 책에서 30 % 개선은 무관하지만 10 배 이상 개선되면 진지하게주의를 기울여야합니다.
적당히 성공적인 존재감을 가지고 있고 100 대가 아닌 10 대의 서버를 사용하거나 20 대가 아닌 2 대를 사용할 수 있다면 큰 차이를 만듭니다.

완전한 공개 나는 Preact 또는 MarkoJS에 대한 감정적 애착이 없습니다 . 나는 그들이 엔지니어링 전망의 대안보다 더 의미가 있다고 생각합니다.

당신의 결정에 행운을 빕니다 😃

@BTS_twt ᄏ ᄏ ᄏ ᄏ ᄏ ᄏ ᄏ ᄏ ᄏ

나는 Drupal 세계에서 왔기 때문에 (우리는이 문제를보고 있습니다. : D) 저는 이것에 대한 이해 관계가 없습니다. 그러나 주석을 읽으면 여기에 약 5 개의 "상위"프레임 워크가 있으며 모두가 선택한 프레임 워크를 좋아하므로 소품을 제공 할 것입니다.

요즘에는 속도 측면이 무의미합니다. 고려해야 할 유일한 두 가지 요소는 a) 정말로 모든 것을 다시 작성하고 싶습니까? b) React 개발자의 전환은 어떻게 될 것이며 새로운 개발자의 경우 우승 한 fw를 배우는 방법입니다.

쉬운 전환을위한 preact-compat, inferno-compat ... 레이어가 있지만 성능이 저하됩니다. 반면에 시간이 지남에 따라 전환이 우아하게 이루어지며 모든 것을 한 번에 다시 작성할 필요는 없습니다. 비즈니스 POV에서 이것은 생각할 필요가 없습니다. 커뮤니티 POV와 미래에서는 차이가 없습니다.

이제 DX는 모든 것이있는 곳입니다. 반응 형 fws에 경험이있는 사람은 개념이 동일하고 구문 만 다르기 때문에 새로운 fw로 전환하는 데 문제가 없어야합니다. 그러나 초보자, 그것이 중요한 사람입니다. 새로운 fw에서 생산성을 높이는 것이 얼마나 어렵고 / 쉽습니까? 기존 코드를 읽고 이해하는 것이 얼마나 어렵고 / 쉽습니까? 그리고 이것은 오로지 a) 좋은 문서와 b) 커뮤니티 (포럼, SO, 채팅룸, 블로그 ..)에만 있습니다.

내가 말했듯이 나는 WP 사람이 아니기 때문에 어떤 FW를 선호하는지 말하지 않을 것입니다. 그러나 저는 전 세계 수천 명의 개발자에게 영향을 미칠 큰 결정에 대해 머리를 시원하게 유지하기 위해 2c를 제공하고 싶었습니다.

@ntwb : 제 댓글은 삭제하지 않았는데 , 팬 분들의 댓글도 일종의 검열이라고 생각 해요.

왜:

귀하의 댓글이 # 2733 (댓글) 이후에 추가되었고 "XYZ에 투표합니다"라고 말했거나 귀하의 댓글이 삭제 될 가능성이 매우 높은 텍스트 일 ​​경우, 동일한 ilk의 향후 댓글 도 삭제됩니다. .

그 위에 팬 보이들의 댓글이 많이 보입니다. 그들은 왜 남아 있습니까?
이중 기준 인 것 같습니다.

Angular는 분명한 선택입니다. Roy와 Meligy가 환상적인 포인트를 만들어 100 % 지원한다고 생각합니다. WordPress는 사용 중일뿐만 아니라 개발 방법론 측면에서도 Enterprise 영역으로 이동하고 있습니다.

재미있는 소스를 연결하겠습니다. https://vuejs.org/v2/guide/comparison.html 특히 : "... Angular의 복잡성은 주로 크고 복잡한 응용 프로그램 ... ". 그 간단한 진술은 머리에 못을 박았다. WordPress는 강력하고 복잡한 응용 프로그램이며 앞으로도 계속 될 것입니다.

@ChrisCinelli 단순히 우리가 사람들에게 "나는 xyz에게 투표한다"라고 말하지 말라고 요청했기 때문에, 나는 당신이 어디에서 왔는지 이해하지만 그 코멘트를 제거하는 것은 형편없는 형식이라고 생각합니다. 그들 중 하나를 제거

권장하지 않은 프레임 워크 (위의 Angular 권장)를 공격하고 싶지 않았기 때문에 더 일찍 가져 오지 않았지만, 완성도를 위해 Preact 및 기타 React와 유사한 라이브러리로 정리해야 할 것이 있습니다. . 여기에 넣을 것이고, 그것이 걱정거리인지 여부를 결정하는 것은 WordPress의 몫입니다.

다음은 React 라이센스 에 대한 특허 / IP 변호사가 작성한 게시물 의 인용문입니다 ( 굵은 강조 표시는 소스에서 복사 됨).

저는 "그럼 모두 [여기에서 대체 프레임 워크]를 사용합시다."를 많이 받았습니다. 잠깐만 기다려 봐. Facebook 특허가 React (차별, 구성 요소 화 등)를 포함하는 경우 해당 특허는 Preact / Vue / et al을 포함 할 가능성이 높습니다.

그러나 React는 당신에게 특허를 부여합니다! 대체 프레임 워크를 사용하면 처음부터 침해자가됩니다. 이 모든 것은 Facebook이 특허를 보유하고 있는지 여부와이를 시행하려는 욕구로 귀결되지만,이 게임을 n 번째 수준까지 전쟁시키고 싶다면 React 대안이 더 위험 합니다.

이제 내 이해가 맞다면 WordPress는 라이센스 자체에 대해 걱정하기 때문에 React를 떠나지 않고이 라이센스를 사용자에게 전달해야하므로 혼란과 결정을 방어해야 할 필요성이 있습니다.

React 대안으로 가면 대안 라이센스가 허용되는 경우 방어 할 것이 적을 수 있지만 WordPress에 여전히 약간의 혼란이있을 수 있습니다.

이것이 걱정할 것인지 아닌지를 결정하는 것은 WordPress의 몫입니다.

@ChrisCinelli 는 건설적인 비판에 감사드립니다. 나는 열린 손으로 그것을 환영합니다.

엔지니어로서 비용과 시간이 가장 높다는 것을 알고 있습니다. 그러나 여기에 문제가 있습니다. 이것은 특정 기업의 프로젝트가 아닙니다. 여기서 목표는 다릅니다.

목표는 커뮤니티에 좋은 JS FW를 찾는 것입니다. 구텐베르크는 아직 출시되지 않았습니다. 작동한다면 Preact가 확실한 승자가 될 것입니다.

지금 우리는 이것을 처리해야합니다 :

• JS FW는 더 많은 커뮤니티에서 쉽게 채택 할 수 있습니다.
• 우리가 선택한 JS FW에는 자체 커뮤니티와 생태계가 있어야합니다.
• PHP 기반 프로덕션 FOSS 소프트웨어로 입증 된 실적은 장점입니다. Vue + Laravel
• 마이그레이션이 더 쉽기 때문 만이 아니라 장점을 기반으로 JS FW 선택

11 년 동안 워드 프레스와 함께 일했고, 정기적 인 핵심 기여자로서 Preact를 선택하는 것이 많은 혼란을 야기 할 것이라고 믿습니다. 중급 / 신규 개발자에게는 이미 학습 곡선이 엄청납니다.

WordPress 개선의 새로운 단계를 시작할 때 Preact-React 호환성 문제를 해결하면 WordPress 커뮤니티를 떠나 유사한 학습 곡선으로 다른 것을 배울 수 있습니다. (_HINT_ : WordPress + Preact + React 대신 Laravel + Vue) 그리고 BTW는 Drupal 8에서 일어나는 일을 잊고 있습니까?

민사 댓글을 삭제하지 마세요. 이 문제에 대한 의견을 표명하려는 욕구가 압도적입니다. 사람들이 워드 프레스에 관심이 있고 듣고 싶어한다고 말하면서 좋은 일이라고 생각합니다. 개발자뿐만 아니라 WordPress 커뮤니티가 피드백을 제공하기 위해 Github로 이동했습니다. 정말로 +1 댓글을 허용 할 수 없다면 상단에 사용자 이름을 유지하는 집계를 추가하세요.

합리적인 토론을 찾고 있다면 "X, Y 또는 Z에 투표합니다."라는 댓글이 많이 소음처럼 보일 수 있지만 Vue.js를 지원하는 사람들의 명확한 패턴이 나타납니다. 제가 생각하는 것은 구텐베르크에 코드를 기여할 사람이 수백 명, 수백 명이지만 그와 상호 작용하는 플러그인과 테마를 작성하는 사람은 수만 명이라는 것입니다. Gutenberg의 성공은 최종 사용자 경험뿐만 아니라 개발 경험이기도합니다. 이것이 유일한 것은 아니지만 WordPress를 성공으로 이끄는 중요한 것은 쉽게 확장 할 수 있다는 것입니다.

특정 프레임 워크를 염두에 두지는 않지만 우리가 염두에 두어야 할 한 가지는 브라우저 지원이 웹 구성 요소, 웹 구성 요소를 활용하는 프레임 워크 또는 최소한 다음과 같이 구축 된 자체 구성 요소와 함께 자리를 잡기 시작한다는 것입니다. 그들은 미래의 증거가 될 것입니다. 웹 구성 요소를 지원하지 않는 브라우저로 가져 오는 polyfill도 있습니다.

앞서 언급했고 알림을 끄려고 여기에 왔지만 약간 무게를 두겠습니다.

단일 페이지 앱을 처음부터 빌드하고 시간이 가장 중요하며 잘 지원되고 문서화되고 테스트 가능한 프레임 워크를 원하면 시간과 소중한 시간이 훨씬 저렴하다는 것을 보여주는 구체적인 경험이 많습니다. Ember와 함께 가십시오.

PWA를 더 많이 구축하거나 서버 렌더링 페이지에 구성 요소를 드롭하는 경우 Ember는 좋지 않은 선택이며 Vue와 같은 것이 매력적인 이유를 알 수 있습니다.

나는 컨벤션 중심의 측면에서 Ember를 사용하여 90 이상의 등대 점수로 몇 개의 PWA를 만들었습니다.

이 작업을 수행해야하는 마지막 프로젝트에서 해당 등대 점수를 얻고 서버 측 렌더링이 활성화 된 상태로 앱을 배포하는 데 1 시간 미만이 걸렸습니다.

높은 등대 점수에 필요한 SSR 및 서비스 작업자 캐시는 매우 까다로운 프로세스 일 수 있습니다.
Ember를 사용하면이 프로세스는 매우 쉽고 잘 문서화되고 유지 관리되는 애드온 몇 개만 설치하면됩니다 (대부분의 앱에서).
내 경험상 Preact는 Preact CLI에서 이러한 두 기능을 기본적으로 제공하지만 SSR 결과를 깨뜨릴 수있는 인기있는 (P) React 규칙이 있습니다.
Vue와 함께 공식 문서는 Nuxt.js를 사용하거나 전체 SSR 가이드 를 따를 것을 권장합니다. 이 두 가지 모두 기본 Vue 문서를 넘어서 따라야 할 더 많은 패턴을 소개합니다.

아무에게도 말하지 않고 욕설이나 욕설이 아닌 한 문제에 대한 댓글 삭제를 보류합시다. 대화를 돕고 집중하려는 사람들을 완전히 얻지 만, 댓글을 삭제하는 나선형에 빠지면 안됩니다.

VueJS @rtablada 와 비교하여 Ember에 대해 "잘 문서화되어있는"것이 무엇인지 잘

개인적으로 Vue 또는 React와 비교하여 Ember로 시작하는 문제가 있습니다.

@ahmadawais 모두가이 결정이 큰 영향을 미칠 것이라는 사실을 잊어 버리고 몇 년 안에 프레임 워크를 변경하고 싶을 것입니다. 따라서 현대적인 프레임 워크의 장점을 사용하고 싶지만 라이브와 죽음에 묶여 있지는 않습니다. 불가능한 것 같나요? 아니야!

얼마 전에 비슷한 문제가 있었는데 연구와 시도 끝에 물과 불을 연결하려는 해결책을 찾았습니다. 간단히 말해서 웹 구성 요소의 사용자 정의 요소, 원하는 기술 (예 : Vue, React, Angular)을 래핑하고 표준 DOM API를 노출합니다.

이러한 솔루션에는 여러 구성 요소가 있으며 각 구성 요소는 다음과 같습니다.

• 원하는 프레임 워크 (물론 바람직하게는 하나만)
• 다른 구성 요소가 쉽게 사용할 수있는 표준 DOM API입니다. 일반 JavaScipt를 통해 조작 할 수도 있습니다.

당시 Vue와 함께 작업하면서 Vue 용 Custom Element의 어댑터 ( https://github.com/karol-f/vue-custom-element)를 작성했습니다 . 따라서 우수한 호환성 (예 : Vue의 $ emit send 표준 DOM 이벤트 일반 JS 또는 예 : React / Angular) 및 IE9 + 호환성을 통해 캡처됩니다.

나는 당신과 같은 해결책을 보는 것이 좋습니다.

• 미래 보장
• 오늘 선택한 프레임 워크와 연결되지 않습니다.
• 사용자는 표준 HTML 요소를보고 원하는 프레임 워크 또는 일반 JS와 상호 작용할 수 있습니다.
• 브라우저가 페이지에있는 경우 구성 요소를 자동으로 초기화하고 알려주기 때문에 수동 Vue 초기화가 없습니다 (이러한 방식으로 구성 요소를 지연로드 할 수도 있음).

그리고 더 많은.

이러한 솔루션은 Vue와 관련이 없습니다. 원하는 다른 프레임 워크를 사용할 수 있습니다. 또한 웹 구성 요소의 사용자 정의 요소는 표준 브라우저 기능이며 어디로도 사라지지 않을 것입니다!

문안 인사!

제가 생각하는 것은 구텐베르크에 코드를 기여할 사람이 수백 명, 수백 명이지만 그와 상호 작용하는 플러그인과 테마를 작성하는 사람은 수만 명이라는 것입니다. Gutenberg의 성공은 최종 사용자 경험뿐만 아니라 개발 경험이기도합니다. 이것이 유일한 것은 아니지만 WordPress를 성공으로 이끄는 중요한 것은 쉽게 확장 할 수 있다는 것입니다.

Vue를 지원하는 데 중요한 포인트이기 때문에 @dmccan의 위 주석을 인용합니다.

WordPress는 단순히 게시하는 것 이상을 민주화했습니다. WordPress의 접근성으로 인해 얼마나 많은 성공적인 기술 경력과 비즈니스가 시작되었는지 궁금합니다. 물론입니다.

나는 VueJS를 위해 내 모자를 던질 것입니다. 현지 JavaScript 모임은 VueJS의 핵심 팀원 중 한 명이 공동으로 진행하며 참석 한 사람들이 다른 사람들보다 훨씬 빠르게 참여할 수있는 것 같습니다. 제 이전 경험은 AngularJS에 대한 것이었고 VueJS는 배우기가 매우 쉬웠고 처음부터 시작하더라도 코딩을 시작했습니다.

일부 사람들은 기업과 Angular에 대해 이야기하고 있지만 WordPress는 해당 분야에서 약간의 사랑이 필요할 수 있지만 결정은 온 보딩 개발자의 용이성을 기반으로해야한다고 생각합니다. 우리가 메타 박스와 그 밖의 것에 대해 본 토론을 통해 플러그인 작성자는 클래식 편집기가 사라질 경우 포기하는 대신 작업을 "Gutenberg-ify"하도록 유도했습니다.

Vue.js 에 대해 언급해야 할 몇 가지 추가 사항 : (그냥 개인적인 생각, 다른 libs, FW 및 옵션은 높이 평가되며 확실히 고유 한 기능과 프로가 있습니다)

• PRO 트랜스 파일러가 필요하지 않거나 사용 방법을 강요 할 필요는 없으며 jquery가 할 수있는 것처럼 웹에서 직접 실행할 수 있습니다.

이것은 플러그인 개발자가 Wordpress UI와 통합하는 데 놀랍도록 도움이 될 것입니다. 페이지의 모든 부분에 새 vue 인스턴스를 위젯으로 연결할 수 있습니다. 또한 큰 Wordpress 프로젝트는 Vue 가 어떻게 사용 될지에 대해 가정하지 Vue.js로 점진적으로 채택 할 수 있습니다. 이것이 Laravel / Vue가 인기 있고 함께 잘 작동하는 성공의 열쇠라고 생각합니다. :)

• PRO JSX 및 css-in-js도 지원됩니다!

React / JSX 코드가있는 현재 WordPress 프로젝트를 변경 요구 사항이 적은 vue.js로 빠르게 마이그레이션하는 데 도움이 될 수 있습니다. (바벨 플러그인도 있습니다 : babel-plugin-transform-react-to-vue )

• FACT Vue는 Preact와 마찬가지로 Angular / React와 달리 Google이나 Facebook과 같은 대기업이 소유 한 오픈 소스 프로젝트가 아닙니다.

이것은 Wordpress와 같은 거대한 프로젝트가 잠재적 인 공급 업체 종속에서 벗어나기 위해 매우 중요합니다. 회사 소유가 아닌 오픈 소스 프로젝트라면 누군가 시작해야합니다 (따라서 "주요 인 의존성"은 CON 으로 언급되는 것은 의미가 없습니다).

VueJS에 투표합니다.
내가 그것에 대해 아무것도 알고 있기 때문이 아니라 영어로 발음되는 방법에 대한 단서가 없기 때문입니다. 그러나 나는 Joomla를 수년간 사용했고 항상 틀렸다고 발음했습니다.

농담은 제쳐두고.
여기에서는 이전 메타 박스 및 사용자 정의 필드를 지원하는 데 어떤 프레임 워크가 더 나은지 논의하는 사람이 많지 않습니다. 우리가 지금 알고 있듯이 React는 매우 나빴습니다.

이제이 호를 구독 취소하겠습니다.

토론에 집중하기 위해 여기에 작업 문제를 만들었습니다 : https://github.com/WordPress/gutenberg/issues/2741

Laravel 때문에 Vue를 제안하고 싶습니다. 많은 WordPress 사용자들이 WP를 두 번째 선택으로 유지하면서 Laravel을 기본 CMS 프레임 워크로 사용하는 것으로 전환했습니다. Preact는 Novell DOS가 MS DOS, PC DOS 및 그 반대의 경우와 비슷한 복제 및 대규모 호환성 계층입니다.

cu, w0lf.

Vue.js 끝까지!

당신은 확실히 Hyperapp 을
장점

1. Elm (모델,보기, 업데이트) 아키텍처와 매우 유사합니다.
2. "액션"(모델 및 인턴 뷰를 업데이트하기 위해 호출 됨)이라고하는 Reducer와 같은 내장 Redux가 있습니다.
3. JSX 사용
4. "기능적 프로그래밍"설계 장려
5. 1kb 이므로로드하기 쉽고 이해하기 쉽습니다.

단점

1. 아직 새롭고 에코 시스템도 마찬가지입니다. 그러나 당신은 그것에 영향을 미치고 기여할 수 있습니다.
2. 아직 밝혀지지 않은 문제가있을 수 있습니다.

Gutenberg 블록의 원칙은 Web Components 의 원칙과 잘 일치합니다. 낮은 수준의 프레임 워크에 구애받지 않고 새로운 표준 (성숙하고 테스트 된 폴리 필 포함)으로 WordPress에 완벽하게 적합합니다.

참고 : Polymer- 설탕이 포함 된 웹 구성 요소.

Vue는 환상적인 옵션이며 여기에 제가 그렇게 믿는 이유가 있습니다.

저는 2016 년 초에 Vue를보기 시작했습니다. 저는 Vue를 좋아했고 그것이 "수요"인지 아니면 그 성장이 집에 쓸만한 것이 있는지 결정하고 싶었습니다. 당시 Github에는 16,000 개의 별이 있습니다. 멋지고 모든 것이었지만 사람들은 Angular 대 React 쓰레기의 한가운데서 실제로 적응하지 못했습니다.

2016 년 9 월 17 일부터 모든 데이터를 잃어 버리고 다시 시작했습니다. 정확히 1 년 전, 오늘입니다. ( 여기 내 현재 데이터 세트입니다. )

지난 1 년 동안 저는 Vue의 인기가 _ 기록을 깨는 _ 비율로 증가하는 것을 보았습니다 (인터넷에서 언급하고 Github 스타를 추적하는 측면에서). Vue는 365 일 동안 별 40,000 개를 모았습니다. 이는 하루 평균 109 회입니다. 이에 비해 전 세계적으로 사랑받는 _React_는 같은 기간에 49,000에서 75,000으로 성장했습니다. (하루 71) Vue는 사용자 평가 측면에서 향후 몇 개월 내에 React를 능가 할 것입니다.

모두가 React의 성장이 역대 가장 놀랍다 고 이야기하는 동안 Vue가 실제 타이틀 보유자라는 사실을 알지 못했습니다. 그들은 Vue가 유명한 지원 (Facebook) 때문이 아니라 도구로서 진정으로 사랑하는 사람들 때문에 성장하고 있다는 것을 알지 못했습니다.

Vue는 1 년 넘게 매일 매일 Github의 인기 리포지토리 목록에 포함되어 있습니다. 99 %는 React보다 높습니다. 하루의 10 %, React는 삭감하지 않습니다.

이 모든 것은 "인기가 더 많이 증가했기 때문에 Vue를 사용하십시오!"라고 외칩니다. 그러나 제가 의미하는 것은 Vue가 모든 규모의 애플리케이션을위한 훌륭하고 직관적이며 강력한 도구 (종종 "작은 앱에 적합"로 잘못 표시됨)이기 때문에 사람들이 진정으로 좋아하기 때문에 성장했다는 것입니다. 그러나 도구 만이 아닙니다. Vue는 생태계입니다. 대규모 지원 커뮤니티도 함께 제공됩니다.

추가할까요 ... .vue 파일은 천재입니다. CSS 모듈에 명백한 문제가 있고 외부 파일에 스타일이 있기 때문에 React에서 스타일링을 처리하기 위해 많은 도구가 구축되고 있습니다. (Idk ...)하지만 Vue에는이 문제가 없습니다. Vue에는 구문에 구워진 제어문이 있으며 (위에서 사용자 지정 요소 주석을 보았으므로) 사용자 지정 요소와 잘 작동 할뿐만 아니라 논리적 사용자 지정 요소를위한 라이브러리 / 프레임 워크입니다.

Preact는 훌륭합니다. 솔직히 오늘 또 다른 프로젝트를 시작했습니다. 그러나 Preact를 보면 브랜드가 아닌 React가 보입니다. 혁신적이거나 웹 기반 소프트웨어를 만드는 방식을 발전시키기 위해 만들어지지 않았습니다. 기존 도구처럼 보이고 작동하지만 더 나은 성능을 제공하기 위해 만들어졌습니다.

그것은 내 2 센트입니다. 이제 나는 파산했습니다.

귀하의 최종 결정이 귀하를 행복하게하고 제품의 미래를위한 훌륭한 토대가되기를 바랍니다.

@ahmadawais :

• 출시 시간은 엔터프라이즈 프로젝트와 오픈 소스 프로젝트 모두에 중요합니다. 너무 오래 걸리고 배송되기 전에 쓸모 없게되어 배송되지 않은 프로젝트의 예를 찾을 수 있습니다. 일부 프로젝트는 메이저 릴리스를 향한 작업 중에 중단되었습니다.
• Preact에 반대한다는 것은 "라이센스 이외의 이유로 React에서 실수를했다"는 의미입니다. "중급 / 신규 개발자에게는 학습 곡선이 이미 거대합니다."라는 말은 워드 프레스 개발자가 React로 인해 이미 길을 잃었다는 의미라고 생각합니다. 놀랍지 않습니다. 그러나 Vue가 덜 장황하더라도 학습 곡선 문제를 해결할 것이라고 믿기는 어렵습니다. 오래된 PHP WP 엔진과 단일 페이지 응용 프로그램의 자바 스크립트 프레임 워크는 매우 다릅니다. Vue와 React는 서로 매우 유사합니다.
  왜 Wordpress와 Laravel 간의 경쟁을 보는지 잘 모르겠습니다. 나는 여기 순진 할 수 있습니다. 나는 Drupal 8 이야기에 대해 거의 알지 못합니다.
  내 관점에서 Wordpress는 CMS이며 기술 사용자가 아닌 대규모 사용자 기반과 이미 내장 된 기능 때문에 개발자를 끌어들입니다. 많은 템플릿이 있으며 개발자는 비 개발자가 사용자 정의 할 수있는 새 사이트를 매우 빠르게 구축 할 수 있습니다.
  Laravel은 내가 아는 한 CMS의 많은 기능을 제공하지 않는 PHP 프레임 워크입니다. 개발자는 더 많은 자유가 필요하기 때문에 선택합니다.
• Vue + Laravel로 몇 가지 성공을 거두었다는 것이 "Vue가 Wordpress에 좋다"라는 의미인지 잘 모르겠습니다. 나는 PHP 및 JS 프레임 워크 사이에 아주 작은 고유 시너지 효과가 있다고 생각합니다. 커뮤니티에 좋은 프레임 워크를 찾는 것이 중요하다는 데 전적으로 동의합니다. 워드 프레스가 의존하는 현재 개발자 커뮤니티의 대부분이 Vue에 익숙하고 Vue를 좋아한다면 최종 결정에 큰 비중을 차지합니다.

엔지니어링 측면에서 Marko JS와 Vue는 모두 새로운 프레임 워크라고 생각합니다. 그들은 React에서 많은 것을 배웠고 그것에 대한 자세한 내용을 제거 할 수있었습니다. 그런 의미에서 Marko는 Vue보다 더 많은 상용구 코드를 제거하는 것 같습니다. 특히 Marko는 동일한 위치에 유지하는 것이 좋은 응집력있는 코드를 유지하고 HTML이 좋은 것은 HTML에 남겨두고 Javascript가 좋은 것은 Javascript에 남겨 둡니다. 또한 10 배 더 빠릅니다. 그래서 최근 Vue에 많은 팬이 있다는 사실 외에는 Marko보다 Vue를 선호하는 이유가 많지 않습니다.

미안하지만 Marko의 구문과 설정은 VueJS에 비해 끔찍합니다. 성능면에서 나는 MarkoJS가 작동 방식을 이해하는 데 시간을 추가하지 않고 중요한 방식으로 더 빠른 소스를 본 적이 없습니다.

@ bovas85 구문은 주관적이지만 Marko의 구문이 " Marko의 현재 구문을 도입 한 릴리스는 사용자들로부터 매우 호평을 받았습니다.

우리는 HTML과 JS를 이해하는 개발자들에게 익숙해 지도록 Marko 구문에 많은 생각을했고 최소한의 상용구로 가능한 한 간단하고 강력하기를 원했습니다. 나란히 비교하면 Marko 템플릿에 더 적은 코드가 필요하다는 것을 알게 될 것입니다 (가독성과 유지 관리에 매우 좋습니다).

다음은 Marko 구문과 Vue 구문의 차이점에 대한 개요를 볼 수 있도록 빠르게 정리 한 문서입니다.

구문 : Marko 대 Vue

이전에 연결했지만 Marko와 Vue (및 React) 간의보다 심층적 인 비교는 다음을 참조하십시오.

Meetup : UI 구축-React, Vue 및 Marko의 비교 (Marko 작성자) - 비디오 | 슬라이드

성능과 관련하여 확인할 수있는 몇 가지 벤치 마크가 있습니다. https://github.com/marko-js/isomorphic-ui-benchmarks

다음은 Marko 및 Vue가 활성화 된 벤치 마크의 빠른 실행입니다.

서버 측 렌더링 성능

_Node.js ( v8.4.0 ) _

Running "search-results"...

Running benchmark "marko"...
marko x 5,180 ops/sec ±2.09% (87 runs sampled)

Running benchmark "vue"...
vue x 135 ops/sec ±3.81% (68 runs sampled)

Fastest is marko

Running "color-picker"...

Running benchmark "marko"...
marko x 10,206 ops/sec ±0.72% (87 runs sampled)

Running benchmark "vue"...
vue x 1,664 ops/sec ±5.20% (66 runs sampled)

Fastest is marko

클라이언트 측 성능

_Chrome 버전 63.0.3218.0 (공식 빌드) canary (64 비트) _

Running "search-results"...
Running benchmark "marko"...
marko x 351 ops/sec ±1.18% (58 runs sampled)
Running benchmark "vue"...
vue x 206 ops/sec ±1.61% (57 runs sampled)
Fastest is marko

Running "color-picker"...
Running benchmark "marko"...
marko x 7,516 ops/sec ±2.90% (41 runs sampled)
Running benchmark "vue"...
vue x 4,593 ops/sec ±3.03% (54 runs sampled)
Fastest is marko

그것들은 우리가 Marko.js를 위해 만든 벤치 마크이므로 당연히 그 결과를 약간의 소금으로 가져 가지만 우리는 공정하기 위해 모든 노력을 기울였습니다.

또한 Marko.js 및 사용 편의성에 관한 몇 가지 의견을 추가하고 싶었습니다.

Marko는 항상 Node.js와 가장 간단한 통합을 목표로했습니다. npm을 통해 marko 패키지를 설치 한 후 HTTP 응답 스트림에 템플릿을 렌더링하는 데 필요한 모든 코드는 다음과 같습니다.

require('marko/node-require'); // require .marko files!

const http = require('http');
const template = require('./template');

http.createServer().on('request', (req, res) => {
  template.render({
    name: 'Frank',
    count: 30,
    colors: ['red', 'green', 'blue']
  }, res);
}).listen(8080);

여러분이 얻을 수있는 것만 큼 간단하다고 생각합니다.

Marko는 또한 널리 사용되는 JavaScript 모듈 번 들러와 함께 작동합니다. http://markojs.com/docs/bundler-integrations-overview/

최상위 Marko UI 구성 요소를 DOM에 렌더링하려면 여기에 필요한 모든 것이 있습니다.

require('./fancy-button')                  // Import the Marko UI component
  .renderSync({ label: 'Click me' })   // Render the button with the provided input
  .appendTo(document.body);         // Mount the UI component to the DOM

@ patrick-steele-idem http://www.stefankrause.net/wp/?p=431 벤치 마크에 따르면 markoJs
Vue et al.

따라서 일반적인 클라이언트 측 스크립팅에서 Markojs와 Vue가 동일하게 성능을 발휘한다고 결론을 내릴 수 있습니다.

물론 내가 링크 한 벤치 마크에는 ssr이 포함되어 있지 않습니다. 그래서 나는 그것에 대해 언급하지 않을 것입니다.

Vue에 투표합니다. jQuery는 이미 WordPress를 사용하기위한 거의 요구 사항입니다. jQuery에 익숙한 사람들은 Vue 구문에 익숙해야합니다. DOM에 대한 이데올로기는 Angular와 같은 극단적 인 것은 아닙니다. 사용자의 편의를 위해 WordPress 주체로 돌아갑니다.

약 2 년 전에 Calypso에 대해 제안했듯이 HyperScript API를 사용하는 Mithril.js는 React를 대체하는 좋은 선택이 될 것입니다. 표준 MIT 라이센스가 있습니다.

React에서 다른 vdom 라이브러리로 변환하기 위해 최소한의 무거운 작업을 자동으로 수행하기위한 새로운 도구에 대한 작은 투자는 Automattic이 헤지하기 위해 미리 수행 할 제안으로 해당 문제에서 언급했듯이 개발자 시간을 절약 할 수 있습니다. React에 대한 내기.

vdom이 아닌 라이브러리를 고려하지 않아도 고려할 수있는 vdom 라이브러리 (예 : inferno.js, maquette 등)는 25 개가 넘습니다. 이 목록 은 vdom 옵션을 고려하여 다른 프로젝트를 위해 모아 놓은 목록 입니다.

다음은 Mithril.js 또는 HyperScript API를 강조하는 (또는 최소한 지원하는) 다른 vdom이 최선의 선택 인 몇 가지 기술적 이유입니다.

개인적으로 React의 JSX 또는 Angular의 자체 템플릿 접근 방식과 같은 JavaScript 기반 UI를 만드는 데 대한 템플릿 접근 방식이나 Vue를 포함한 다른 많은 UI 시스템의 템플릿 시스템이 구식이라고 생각합니다. 왜? 복잡한 CSS 스타일 시트 (이전 WordPress 플러그인과 같은)를 사용하여 서버 측 생성 HTML 템플릿 기반 웹 앱을 작성하기위한 환경 설정 및 "모범 사례"는 단일 페이지 웹 응용 프로그램을 작성하는 "최악의 사례"가되고 있습니다. 복잡한 최신 단일 페이지 클라이언트 쪽 응용 프로그램을 작성하기위한 기술적 요구 사항은 클라이언트 쪽 코드의 복잡성이 증가하기 때문에 주로 서버 기반 코드와 다릅니다. 요컨대, 템플릿과 복잡한 CSS 스타일 시트 를 사용하는 오래된 "모범 사례"는 확장되지 않아 코드 유지 관리가 어렵습니다.

새로운 대안은 무엇입니까? 최신 웹앱은 Mithril + Tachyons + JavaScript / TypeScript를 사용하여 모든 코드가 JavaScript / TypeScript 인 단일 파일에 구성 요소를 작성할 수 있습니다. 이러한 앱은 프로그래밍 언어의 일부를 (나쁘게) 다시 구현하는 CSS 또는 HTML의 일부 비표준 변형으로 부분적으로 작성할 필요가 없습니다. (음, Tachyons 또는 유사한 라이브러리 위에 필요한 사용자 정의 CSS가 약간있을 수 있지만 매우 적습니다.)

다음은 그 접근 방식을 사용하는 몇 가지 예제와 함께 내가 작성한 코딩 놀이터의 예입니다 .

따라서 HyperScript (및 vdom 라이브러리 포함)를 사용하여 UI를 작성하면 Mithril과 같은 백엔드를 거의 모든 다른 vdom 또는 비 vdom 솔루션으로 대체 할 수 있습니다. 따라서 선택권이있을 때 HyperScript API를 사용하도록 선택하는 것은 버그 나 라이선스 문제가있는 기본 라이브러리의 위험을 완화하는 방법입니다.

Tachyons 또는 유사한 라이브러리를 사용하여 응용 프로그램이 커짐에 따라 유지 관리 할 수없는 CSS 파일의 위험을 완화합니다.

물론 저는 많은 웹 개발자가 HTML을 조정하면서 자랐고 HTML 모양의 템플릿을 좋아한다는 것을 알고 있습니다. 따라서 그들은 JSX 또는 무엇이든 좋아하고 애플리케이션 중간에서 코드가 아닌 것들을 리팩토링하거나 유효성을 검사하는 것이 얼마나 어려운지 무시하고 기뻐합니다. 물론 일부 IDE는 JSX 템플릿 리팩토링에서 더 나아지고 있습니다. 하지만 저는 데스크탑에서 웹 개발을 시작하고 (보통) 코드에서 직접 UI를 생성하는 시스템 (예 : Swing, Tk, wxWidgets 등을 사용하여)과 함께 작업하는 임베디드 개발에 왔습니다. 표준 도구가 내가 작업하는 모든 코드를 리팩토링하고 많은 불일치를 감지하는 데 도움이 될 수 있다는 생각이 마음에 듭니다.

여기에서 실행되는 모든 프레임 워크가 선택한 브라우저의 속도 때문에 사용자에게 눈에 띄는 차이가 없다고 가정하면 어떤 프레임 워크가 최선의 선택인지 평가하기위한 메트릭으로 프런트 엔드 성능 사용을 중지 할 수 있습니다.

하지만 서버 측 렌더링을 사용 한다면 SSR 성능을주의 깊게 살펴 봐야합니다. 칼립소는 SSR을 목표로하는 것 같습니다. 그리고 성공하면 언젠가 Calypso는 wordpress.com에서 대부분의 사이트를 운영 할 것입니다.

회사는 브라우저의 CPU가 아닌 서버의 CPU에 대해 지불합니다. 따라서 비용 측면에서 Marko 의

Wordpress가 그것을 무시할 수 있다면 기꺼이 회사에서 일하고 10 배의 시장 급여를 받고 Vue를 사용할 것입니다. 그건 그렇고, 좋은 React 대안이라고 생각합니다 =)

프레임 워크가 가벼울수록, 즉 기본 제공되는 기능이 적을수록 성능이 더 빨라집니다. 한심할 정도로 분명합니다. 다양한 알고리즘의 성능을 비교하는 것이 하나이지만 가장 큰 요인은 다른 "작업"이 수행되는 정도일 때 테스트를 작성할 필요가 없습니다.

https://hueniverse.com/performance-at-rest-75bb8fff143

@ahmadawais Angular 핵심 팀-우리는 CMS / 위젯 스타일 개발과 관련된 많은 흥미로운 작업을 진행하고 있습니다. 여기에는 Custom Elements 지원에 대한 투자가 포함됩니다.

대화 목록을 더 복잡하게 만드는 대신 관심이 있으시면 오프라인으로 채팅을 드리겠습니다. Google 닷컴의 robwormald에 연락주세요. 행운을 빕니다,이 전화를해야 부럽지 않습니다 ;-)

사람들이 원하는 것에 대한 통찰력을 얻는 데 사용할 수있는 간단한 설문 조사를 여기에서 작성했습니다.

현재 결과 페이지 및 인증 작업 중입니다. (Firebase 신규)

추신. Vue 🖖을 사용하여 만드는 데 약 1 시간이 걸렸습니다.

@vinayakkulkarni 설문 조사에 Mithril.js를 추가하는 것은 어떻습니까?

@pdfernhout : 👍

끝난. MithrilJS를 목록에 추가했습니다.

• [x] VueJS
• [x] 각도
• [x] 정확한
• [x] 엠버
• [x] 마르코
• [x] 인페르노
• [x] 아우렐 리아
• [x] 미트 릴

사람들이 무엇을 결정하는지 보자 ..
추신. @ahmadawais 의 트위터 설문 조사 도있었습니다.

안녕하세요. 저는 Drupal 핵심 관리자입니다. @ivanjaros 가 이전 의견에서 언급했듯이 Drupal의 관리 UI의 향후 일부 비트에 대해 Preact, Vue 또는 다른 것을 평가하고 있습니다. 우리는 당신이 선택한 것과 다른 것에 정착 할 수 있지만, 당신이 선택한 것은 우리가 선택할 때 고려할 최소한 하나의 요소가 될 것입니다.

지금까지이 두 가지 Drupal 문제를 열었고 더 많은 문제가 올 것입니다. 이러한 문제 / 토론이 유용 할 경우 여기에서 상호 참조하십시오.

• 여러 루트 노드를 반환하는 구성 요소
• 슬롯 대 vnode 소품

이 두 가지 문제에도 불구하고 나는 여전히 Vue를 강력하게 좋아합니다. Vue의 다른 모든 이점을 얻기 위해 우리가 함께 사는 것이 괜찮을 수 있습니다.

Vue의 저자로서 저는 분명히 편향되어 있기 때문에 여기서 어떤 프레임 워크를 선택할 것인지에 대한 언급을 피할 것입니다. 하지만 몇 번 던진 "Marko는 Vue보다 10 배 빠르다"라는 말을봤을 때 좀 더 설명 할 가치가 있다고 생각합니다. 나는 또한 기술적 인 논쟁으로 토론을 탈선시키고 싶지 않기 때문에 관심있는 사람들을 위해이 요지 에 몇 가지 생각을 적어 놓았습니다.

재정적 문제에 대해 @ michaelbdavidson7 : 저는 Vue에서 1.5 년 넘게 풀 타임으로 작업 해 왔으며 Patreon 지원은 정말 안정적이었습니다. Patreon 서약 변동을 추측하는 대신 Vue의 커밋 활동을 확인하여 스스로 판단 할 수 있습니다. 또한 개방형 재정 기여 채널을 보유한다는 것은 WP / Automattic이 주요 후원자가 됨으로써 Vue의 지속 가능성을 쉽게 보장 할 수 있음을 의미합니다 (Matt 자신은 이미 개인 후원자입니다!). 실제로 두 프로젝트의 이익과 일치합니다.

나는 Vuejs에 투표한다

@ tungbt94 왜?

확실히 VueJS

더 큰 질문은 왜이 특허 문제 전에 반응을 선택했는지입니다. 특허가 아니더라도 리 액트를 사용 하시겠습니까? preact를 선택하지 않는 것에 대한 많은 포인트는 react를 선택하지 않는 것과 동일합니다.

내 투표는 Preact

React 이외의 다른 것에 대한 경험이 많지 않기 때문에 어떤 프레임 워크를 선택할지에 대해서는 중요하지 않습니다.
그러나 나는 "큰 공동체"주장이 덜 중요 할 수 있다고 생각한다. 왜? Automattic이 프레임 워크를 결정할 때 그 농장은 수천 명의 신규 사용자를 확보 할 것이기 때문입니다. 그리고 내가 WP 커뮤니티가 옳다는 것을 안다면 그들 중 많은 사람들이 그 프레임 워크에 기여하기 시작할 것이고 인기가 높아질 것입니다.

구텐베르크와 칼립소가 현재 어디에 있는지를 고려할 때 여전히 Preact가 최고의 엔지니어링 선택이라고 생각합니다.

그러나 React와 닮은 다리를 태우는 것에 대해 여전히 강하다고 느끼거나 처음부터 시작해야한다면 MarkoJ 가 최선의 선택이라고 믿습니다. 커뮤니티 지원이 여전히 걱정거리라고 생각합니다.

Github 스타가 어떻게 든 커뮤니티와 상관 관계가 있다고 가정하면 Vue는 MarkoJ에 비해 여전히 10 배이지만 그래프를 보면 빠르게 변경 될 것입니다.

Vue는 선형 적으로 성장하고 있습니다.

그러나 MarkoJ 는 기하 급수적 인 성장의 변곡점에있는 것 같습니다.

MarkoJs 의 주 저자 인 @ patrick-steele-idem은 항상 https://gitter.im/marko-js/marko 에서 매우 반응이 좋았습니다 .

사람들이 궁극적으로 MarkoJ를 선택하지만 실제로는 모든 종류의 커뮤니티를 선택할 때 JFK의 인용문을 의역하는 느낌이

개인적으로 관련 JS 라이브러리 옵션을 사용하고 지원하는 많은 JS 개발자 로부터 상당한 참여를 @ahmadawais 에게 축하를 전하고 싶습니다.

이 문제는 지금까지 다른 어떤 구텐베르크 통신보다 구텐베르크를 통해 더 많은 자바 스크립트 기반 개발로 WordPress가 이동하는 것에 대해 더 많은 JS 개발자에게 알리는 데 도움이되었다고 생각합니다.

AngularJS를 사용하지만 매번 주요 업데이트가 마음에 들지 않으므로 VueJS를 사용하겠습니다.

Marko에 +1. 우리 팀이 사용하고 매우 만족 한 훌륭한 라이브러리. 비동기 렌더링, 초고속 (서버의 문자열 및 브라우저의 vdom으로 렌더링), 단일 또는 다중 파일 구성 요소 및 IMO가 최고의 템플릿 구문입니다.

@WebReflection 의 hyperHTML 을 고려하십시오.

나는 Angular를 좋아한다

Angular에 투표합니다.

나는 각도를 선택

그냥 각도

나는 각도를 선택

모난

Angular에 투표합니다.

Angular에 투표합니다.

프레임 워크에 투표하고 싶다면 정확한 이유와 그것이 구텐베르크에 어떻게 도움이되는지 아는 것이 좋습니다.

"나는 X에 투표합니다"라고 말하려고 여기 오는 친구들에게 우리도 X에 투표해야하는 이유를 알려주세요. "I vote X"는 당신이 X를 좋아한다는 것 외에는 아무 것도 말해주지 않습니다.

나는 각도를 선택합니다. Angular는 version2 이후로 큰 변화가 있습니다. 지금, 그것은 완전히, 훌륭하고 강력하고 널리 사용되는 프레임 워크입니다. 이온처럼 빠르게 공부하지는 않지만 강력하게 연구하십시오.

너무 많은 스팸으로“나는 투표프레임 워크”, github가 저에게 삐걱 거리고 있습니다.

저는 동료 개발자들이 'I vote…'를 게시하는 대신 https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ 에서 귀하가 선택한 프레임 워크에 대해 친절하게 투표 할 것을 촉구합니다.

또 다른 제안은이 대화를 잠그는 것입니다. 대부분의 주요 개발자는 이미 이에 대해 발언권을 가지고 있습니다.

2017 년 9 월 18 일 오후 8:01에 Mingyue [email protected] 은 다음과 같이 썼습니다.

나는 각도를 선택합니다. Angular는 version2 이후로 큰 변화가 있습니다. 지금, 그것은 완전히, 훌륭하고 강력하고 널리 사용되는 프레임 워크입니다. 이온처럼 빠르게 공부하지는 않지만 강력하게 연구하십시오.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898 에서 보거나 https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg- 스레드를 음소거합니다.

_hyperHTML_에 대해 언급 해 주신

좋아하는 JS 프레임 워크를 공유하지 말고 그 이유도 공유하세요.

그러니 제가 해보겠습니다 ...

: zap : 하이퍼 HTML :

• PRO : 초보자에게 친숙하고 P / React 사용자에게 친숙 함 (JSX 대신 템플릿 리터럴을 작성 함)
• PRO : 빠르고 VDOM없이 타오르는; 메모리 소비 감소 (신흥 시장 전화 친화적)
• PRO : 도구가 필요하지 않습니다 (IE <11에 대해서만 트랜스 파일 된 템플릿 리터럴 필요)
• PRO : JS / DOM / HTML 표준을 완전히 기반으로하지만 TypeScript 와도 호환 가능
• PRO : 추가 폴리 필 또는 브라우저 패치없이 5K (최소 압축) 미만에 적합
• PRO : IE9 특유의 100 % 코드 커버리지
• PRO : NodeJS와 동일한 API를 공유합니다. 100 % 서버 측 렌더링 호환
• PRO : 그것은 SSR 레이아웃 / 노드를 부수고없이 존재 DOM을 채택 할 수있다
• PRO : P / React보다 사용자 정의 요소와 더 잘
• PRO : React , Vue.js , Polymer , Angular 또는 Marko 가하는 일을 할 수 있으며 각각의 크기 / 대역폭 / 성능 측면에서 승리합니다.

이제이 스레드에서 지금까지 사용 된 메트릭에 따라 CONS

• 단점 : 전투 테스트를 거쳐 완전히 테스트되고 동결 된 API를 사용하더라도 상대적으로 젊은 프로젝트 (2017 년 3 월)이므로 인기도, 채택률 또는 기여자 수 측면에서 경쟁 할 수 없습니다.
• 단점 : 커뮤니티가 많은 것을 돕고 있으며 프로젝트가 성장하고 있지만 지금까지 주요 기술 공헌자는 저입니다. 저는이 프로젝트에 100 % 전념하고 있으며 가능한 한 많이 추진할 의향이 있습니다. 또한 다음 대규모 프로젝트에서 _hyperHTML_을 사용하는 것에 대해 거의 "_bigs_"와 논의하고 있습니다 (더 이상 추측하지는 않겠습니다. 이 후반부를 무시해도됩니다.)

: dart : 저는 진정으로 웹의 미래는 플랫폼을 가능한 많이 사용하는 것이라고 믿습니다. 10 년 전보다 확실히 더 나은 방법이며, 최신 ECMAScript 사양 덕분에 쓰기, 읽기 및 유지 관리가 더 쉽습니다. _hyperHTML_은 잠재력 측면에서 "_ 현재 웹 아트 상태 _"를 나타내며,이 목록에있는 다른 모든 경쟁자는 ES6 이전 시대에 태어났습니다.

커뮤니티 규모, 기여자 및 GitHub 별표가 중요하다는 것을 이해하지만 테스트, 크로스 브라우저 코드 범위 및 버그 양도 고려해야한다고 생각하며 _hyperHTML_ 및 친구의 수를 가까이에서 유지하기 위해 최선을 다하고 있습니다. 0 (버그가 아닌 토론 옆에 실제로 0입니다).

마지막으로, 아무도 새로운 솔루션에 기회를주지 않고 별과 과대 광고만으로 판단하지 않는다면 새로운 솔루션이 인기를 얻는 데 더 오래 걸릴 것입니다.

물론, 나는 나의 최신 솔루션에 대해 이야기했고, 나의 고려 사항은 주관적인 것으로 간주 될 수 있지만, 특히 새로운 솔루션에 대한 기회를 제공하는 것에 대한 나의 후자의 문장은 내 라이브러리뿐만 아니라 매우 일반적이었습니다.

친애하는

나는 각도를 좋아한다

각도와 Google이어야합니다.

나는 각도를 좋아한다

Angular는 실제 프레임 워크 일뿐입니다!

AngularJs가 아닌 Angular를 선택합니다.

각도 만이 실제 프레임 워크입니다!

의심하기 시작했습니다.이 댓글은 봇이 작성한 것입니다.

@OP :이 스레드를 잠그십시오.

Angular (AngularJS가 아님)에 투표합니다.

Angular 는 플랫폼입니다. Google 팀은 종속성 주입을 사용하여 구성 요소, 모듈, 라우터를 포함하여 개발 진행을 더 쉽게 만들기 위해 많은 작업을 수행합니다. 모든 종속성을 정렬하는 데 많은 작업을 절약 할 수 있습니다. angular-cli를 사용하면 새로운 프로젝트를 시작하기 위해 많은 작업을 절약 할 수 있습니다. 상자를 열기 만하면 앱이 aot, 트리 쉐이킹 및 기타 여러 최적화로 잘 컴파일됩니다.

TypeScript 는 angular를 사용하는 또 다른 훌륭한 도구입니다. MicroSoft에서 제공합니다. 즉 전체 angular 플랫폼은 ts로 빌드됩니다. TS로 앱을 빌드하세요! 코드의 양이 점점 커질 때 삶을 더 쉽게 만드는 훌륭한 도구입니다. 클릭 한 번으로 IDE에서 (vscode와 같은) 리팩토링을 수행 할 수 있습니다. 정적 유형 검사를 사용하면 가능한 한 빨리 버그를 찾을 수 있습니다. TS는 또한 OOP의 좋은 구현을 제공하므로 훨씬 더 나은 방법으로 코드를 정렬하고 재사용 할 수 있습니다.

또한 meterial design2, primeng과 같이 각도를 기반으로 구축 된 많은 구성 요소가 있으며 우리 팀에서 만든 Jigsaw를 추천하고 싶습니다. ZTE China의 빅 데이터 제품에 채택되었습니다. 현재 ZTE의 모든 앱을 지원하고 있습니다.

Anglar는 훌륭한 선택입니다 !!

모든 봇에게 : 🖕

아마도 누군가가 AngularJs 커뮤니티에 게시했을 것입니다. 나는 사람들이 더 이상 메시지를 받고 싶지 않으면 스레드를 음소거 할 수 있다고 생각합니다.

결국이 주제에 대한 비슷한 대화가 워드 프레스 기여자 만있는 곳에서 일어나야한다고 생각합니다.

제가 EmberJS 슬랙 커뮤니티 그룹에서 이미 표현한이 문제에 대한 제 생각을 공유하고 싶습니다. 10 분 동안 토론을 읽어 보시면 추천하겠습니다 : https://embercommunity.slackarchive.io / wb-marketing / page-2 / ts-1505456102000189 거기에 꽤 많이 있지만 토론에 대한 미묘한 이해를 얻으려면 그것을 확인하는 것이 좋습니다.

그 토론의 주요 요점은 다음과 같습니다.

• Ember 프레임 워크에서 무언가를 구현하는 2-4 주 스파이크를 다른 라이브러리와 비교할 때 다른 라이브러리는 단기적으로이기는 경향이 있지만 Ember는 어떤 장기 프로젝트에서도 이깁니다.
• 함께 사용할 라이브러리 또는 프레임 워크를 고려할 때 기술 구현뿐만 아니라 "소프트 스킬"측면 (커뮤니티 규모, LTS 지원에 대한 헌신, 프로젝트의 핵심 결정에 대한 커뮤니티 참여)도 고려하는 것이 중요합니다.
• Ember는 응용 프로그램 코드를 업그레이드 할 필요없이 ember-cli "내부"를 사용하여 구축 된 응용 프로그램에 대한 주요 개선 사항을 제공 한 실적이 있습니다. 또한 응용 프로그램 코드에 대한 사소한 업그레이드 ( ember-watson 같은 것을 사용하는 포함 된 code-mod 포함)의 경우도있어 상당한 성능과 생산성 향상을 얻을 수 있습니다.

위의 요점에 대해 10,000 단어의 에세이를 행복하게 쓸 수 있었기 때문에이 주석에서 너무 자세하게 다루고 싶지 않습니다. 그러나 "Ember 사고 방식"을 가진 사람과이 문제를 논의하고자하는 사람에게 시간을 제공하고 싶습니다.

의사 결정권자 중 누구라도 더 넓은 Ember 생태계에 대해 더 뾰족한 질문을하기 위해 1 시간 동안 전화를 걸고 싶다면 기꺼이 그렇게 할 것입니다. 제 트위터 에서 저에게 연락하실 수 있습니다. (DM 오픈) 저는 핵심 팀원은 아니지만 1.0 이전부터 Ember 앱을 구축하고 있으며 다양한 앱으로 모든 업그레이드 프로세스를 거쳤습니다 👍

나는 eBay에서 "My eBay"를 위해 일합니다. 첫 번째 단일 페이지 앱을 출시했습니다. 우리는 MarkoJS를 사용하여 모든 개발 단계를 즐겼습니다. 저처럼 노드의 스트리밍 프로그래밍 패러다임 을 좋아한다면 MarkoJS는 스트리밍 및 비동기 렌더링을 지원합니다. 내가 MarkoJS에 대해 좋아 한 다른 사실 :

• 서버와 브라우저에서 렌더링 된 UI 구성 요소의 동작을 효율적으로 바인딩합니다.

• 매우 효율적인 이벤트 위임

• 서버에서 브라우저로의 빠른 상태 직렬화

@vinayakkulkarni 당신의 아이디어는 좋은 것 같지만 문제는 브라우저를 변경하여 1 개 이상의 투표를 남길 수 있다는 것입니다 (같은 브라우저로 시도하지 않았습니다).

트위터 설문 조사를 사용하거나 (이미 존재합니다) 투표를 고유하게 만들기 위해 로그인 시스템을 구현해야합니다.

서버 렌더링은 여기서 대화와 관련이 없습니다. Node는 필수 WordPress 스택의 일부가되지 않으므로 Node에서 이러한 프레임 워크가 렌더링되는 속도는 결정과 관련이 없습니다.

Vue.js! 이 프로젝트를보세요 https://github.com/bstavroulakis/vue-wordpress-pwa

저는 Angular (AngularJS가 아님)를 선택했습니다. 그것은 가장 큰 커뮤니티, 안정적이고 완전한 생태계를 가지고 있습니다.

Angular는 매우 느리고 v4에서는 typescript를 기반으로하므로 워드 프레스 개발에 쓸모가 없습니다.

플랫폼의 성숙도에 따라 Angular를 선택합니다.

배우기가 더 쉽고 내가 가장 좋아하는 프레임 워크 인 Ember Js가 작업에 비해 너무 크고 Glimmer Js가 아직 너무 새롭기 때문에 Vue에 투표하겠습니다. :-)

서버 렌더링은 여기서 대화와 관련이 없습니다.

제 경우에는 다른 사람들이 관련성이 있다고 생각하는 기능을 방금 언급했습니다.

노드는 필수 WordPress 스택의 일부가되지 않습니다.

_hyperHTML_은 PHP를 포함하여 모든 서버 측 렌더링 콘텐츠를 선택할 수 있습니다. 저는 Zend 인증 엔지니어이며 이미 WordPress를 사용하여 언론인 / 출판사와 함께 일해 왔습니다.

따라서 이러한 프레임 워크가 Node에서 렌더링되는 속도는 결정과 관련이 없습니다.

프레임 워크가 백엔드에서도 작동하고, 서버 측 렌더링 된 콘텐츠를 선택할 수 있으며, 심지어 NativeScript 와도 호환 될 수 있다는 사실은 현재와는 무관 한 장점 일 수 있지만 개방형 프로젝트가 고려할 수있는 기능을 가지고 있으면 미래에 호환되는 좋은 기능입니다.

@webreflection 나는 특별히 당신을 선택하는 그 코멘트를 의미하지 않았습니다. Marko의 "스트리밍 패러다임"을 강조한 위의 의견에 대한 응답으로 더 많이 언급되었지만 BE 렌더링 성능에 대한 모든 의견을 다루기위한 것이 었습니다.

전망

https://ma.tt/2017/09/on-react-and-wordpress/의 @mAAdhaTTah :

그 게시물은 게시되지 않고 대신 구텐베르크 팀이 한 발 뒤로 물러나서 다른 라이브러리를 사용하여 구텐베르크를 다시 작성할 것이라고 말하려고합니다. 구텐베르크는 최소한 몇 주 정도 지연 될 것이며 내년으로 출시 될 수도 있습니다.

그리고 더 중요합니다.

Automattic은 또한 Gutenberg가 Calypso를 다시 작성하도록 선택한 모든 것을 사용합니다.

Calypso는 이미 서버 측 렌더링을 사용하고 있습니다. 참조 : https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

그래서 내 이해는 SSR 공연이 관련이 있다는 것입니다.

앵귤러도 좋아해요!
AngularJS js 실제 프레임 워크!

Angular에 투표합니다.

@chriscinelli WordPress가 아닌 Automattic입니다. WordPress 자체는 노드로 서버 렌더링을 수행하지 않으므로 이러한 조건에서의 성능은 프로젝트와 관련이 없습니다.

분명히 Angular가 최선의 선택입니다.

Angular에 투표합니다.

Angular에 투표합니다.

Vue.js에 투표합니다.
특히 뷰 레이어를 다룰 때 대부분의 시간을 절약합니다.

Vue에 투표해야합니다 !!!

각진 파동을 던져

@trotyl 그 댓글은 받아 들일 수 없습니다. 댓글을 수정하여 삭제했습니다.

오, AngularJS는하지 마세요
이제 Angular입니다.

wikipedia의 @mAAdhaTTah :

WordPress 는 설립자 인 Matt Mullenweg와 Mike Little에 의해 2003 년 5 월 27 일에 b2 / cafelog의 포크로 출시되었습니다.

주로 주변 커뮤니티에 의해 개발되었지만 WordPress 는 Matt Mullenweg가 설립 한 회사 인 Automattic 과 밀접한 관련이 있습니다.

이것은 Calypso입니다 : https://developer.wordpress.com/calypso/ 그리고 Calypso는 SSR을 사용합니다.

이전 댓글 에서 썼 듯이 Matt의 ReactJS 지원 을 원한다는 것이 매우 분명합니다. Automattic은 SSR을 사용하여 서버에서 Calypso 페이지를 제공합니다.

이 결정과 관련하여 SSR 성능을 만들기에 충분하다고 생각합니다.

그러나 먼 미래에 Wordpress 개발자가 Preact (또는 Vue 또는 Marko 또는 다른 프레임 워크)에 익숙해지면 새로운 미친 프로젝트가 나올 수 있으며 노드를 통해 Wordpress의 더 많은 부분을 제공하기로 결정합니다. 그러면 SSR이 더욱 중요해집니다. 따라서 SSR 성능이 훨씬 더 중요 할 수 있습니다.

SSR에 대해 논의하기 위해 대화가 진행됨에 따라 이것이 Ember에게 매우 높은 우선 순위이며 Ember-Fastboot 의 출현과 함께 상당히 광범위하게 고려되었다는 점을 언급하는 것이 현명하다고 생각합니다.

몇 가지 클라이언트 응용 프로그램과 함께 Fastboot를 사용하는 동안 (대단한 효과를 위해) 이것은 높은 수준의 기술 토론 이므로 @tomdale에 문의하는 것이 좋습니다.

@chriscinelli WordPress 커뮤니티 프로젝트와 Automattic 회사는 여전히 별도의 엔티티입니다. Automattic이 SSR로 인해 둘 중 하나에 찬성하여 논쟁을 벌일 수는 있지만 여전히 WordPress 커뮤니티가 WordPress 코어를위한 프레임 워크를 고려하는 방식을 바꾸지는 않습니다. 실행하려면 노드가 필요합니다.

어쨌든,이 스레드에서 구독을 취소했습니다. 이 토론을 오프라인으로 계속하려면 내 이메일이 내 프로필에 있습니다.

노드 실행을 요구하지 않으며 실제로도 할 수 없습니다.

SSR 기능을 차별점으로 삼지 마십시오. 노드 SSR이 가능한 프레임 워크는 노드 SSR 없이도 사용할 수 있습니다. 이는 단지 추가 기능 일뿐, 요구 사항도 아니고 종속성도 아닙니다.

Vue.js에 투표하겠습니다.

나는 MIT에 갔고 합리적으로 똑똑해야하는 수석 아치입니다. 저는이 일을 수년 동안 해왔고 여기저기서 몇 명의 개발자를 인터뷰했습니다. 나는 웹이 똑똑한 사람들로 가득 차 있다는 것을 알고 있지만 Vue의 단순함이 Angular의 복잡성과 동등하다고 생각하는 사람은 "복잡함"을 구성하는 것에 대한 관점을 잃었습니다. Google이 생각한 것처럼 구성 요소 기반 Javascript는 완전히 사소하지 않습니다. 엄청나게 복잡합니다. Vue는 그렇지 않습니다. Vue는 PHP만큼 쉽습니다. "Vue가 배우기 더 쉽다"는 것은 Vue가 Angular보다 얼마나 쉬운 지 설명하는 데 가깝지 않기 때문입니다. 그리고 여기에 문제가 있습니다. React보다 훨씬 쉽다고 생각합니다.

React는 평범한 사람들에게 easy-peasy와 google-level 사이의 경계를 걷고있었습니다. 소규모 상점의 경우 React가 소규모 팀에 도전 할 수있을만큼 복잡하다고 말하고 싶습니다. React는 예를 들어 PHP / Wordpress보다 더 복잡합니다. React를 선택함으로써 Wordpress / Automattic은 개발자가 Wordpress 개발 환경에 진입하기위한 요구 사항을 높였습니다. 수백 명의 사람들이 "React is easy", "웹이 점점 더 스마트 해지고 있습니다"라고 외칠 것이라고 확신합니다.하지만 하루가 끝나면 더 복잡한 것은 여전히 ​​더 복잡합니다.

나는 Vue로 돌아가는 것이 WP 뿌리에 더 가깝고 WP 커뮤니티 전체에 대한 기술적 부담이 적을 것이라고 겸손하게 생각합니다. 웹 패러다임은 제쳐두고-때로는 단순한 것이 좋습니다.

Angular와 Vue는 서로 다른 두 가지입니다.

Vue, React, MarkoJS, Inferno, Preact 등은 뷰 레이어만을 다루는 라이브러리입니다. Angular를 포함하여 모두 HTML을 생성하고 선언적인 방식으로 DOM을 변경하는 방법이 있습니다. Angular는 프런트 엔드 개발을위한 전체 프레임 워크를 제공하기를 원하며 뷰 레이어를 넘어서는 더 많은 것을 가지고 있습니다.

React의 구문은이 샘플에서 가장 오래된 것입니다. Facebook은 매우 제한된 프로토콜 표면에서 많은 작업을 수행하는 (너무 많을 수도 있음) 매우 복잡한 라이브러리를 바인딩하는 데 꽤 좋은 일을했습니다. React를 사용하고 생산성을 높이기 위해 React 내부의 복잡성을 알 필요가 없습니다. 실제로 기본을 배우고 반나절 만에 사용할 수 있습니다.

이 목록의 다른 모든 라이브러리는 React에서 배웠습니다. 그들은 구문을 단순화하고, React의 성능을 향상시키고, 동일한 작업을 수행하는 데 필요한 Javascript 코드의 크기를 줄이고 그 위에 몇 가지 기능을 추가하려고했습니다.
Preact는 3Kb에서 React와 매우 유사한 인터페이스를 유지하는 데 큰 역할을했습니다.
Inferno와 Marko는 렌더링 성능을 대폭 최적화했습니다.
Marko와 Vue는 상용구 코드를 줄이기 위해 구문을 많이 단순화했습니다.
Marko는 또한 코드를 더 건조하게 유지하기 위해 선택적 Jade / Pug 유사 구문을 추가하고 사용자를 위해 모든 것을 간단하고 직관적으로 유지하는 비동기 템플릿을 생성하는 기능을 추가했습니다.

그러나 Angular 외에 이러한 모든 라이브러리는 엔지니어가 데이터, 라우팅 등을 가져 오는 전략과 메커니즘을 제공해야합니다. Redux와 미들웨어는 Gutemberg가 데이터 계층을 관리하는 데 사용하는 인기있는 방법 중 하나입니다.

React에서 마이그레이션 할 때 Gutenberg는 "변경할 다른 것"이 필요하지 않습니다. Angular가 사용자에 대해 독립적 인 상태를 유지하려고 노력 했더라도 https://github.com/angular-redux/ng-redux 와 같은 라이브러리가 개발되고 지원 되었음에도 불구하고 Redux 및 Javascript (vs Typescript)와 함께 사용하는 것은 자연스러운 선택이 아닙니다. Javascript를 사용할 수 있습니다. 게다가 지금까지의 투표를 보면 구텐베르크 커뮤니티가 구글의 프레임 워크에 강하게 반대하는 것 같습니다. 따라서 Angular는 옵션이 아닐 것입니다.

PHP와 이러한 자바 스크립트 프레임 워크는 완전히 다른 짐승입니다.

PHP 백엔드와 단일 페이지 앱 프런트 엔드를 가질 수 있지만 시너지 효과가없고 유사점이 거의 없습니다.

모든 자바 스크립트 앱은 jQuery를 뿌린 일반 PHP 코드를 작성할 수있는 것보다 적어도 한 단계 더 복잡합니다. 모든 최신 자바 스크립트 앱은 상태 저장 및 비동기 흐름 이라는 두 가지 큰 복잡성을 처리해야합니다. 이는 지난 몇 년간 불변성과 async / await 에 의해서만 완화되었습니다. 애플리케이션이 성장함에 따라 개발자 흐름이 느려집니다. 일부 코드를 변경하면 다시 컴파일하고 다시 시작해야하며 앱은 다시 초기화를 거쳐야합니다. 핫 재 장전을 구현하기 위해 막대한 양의 툴링이 구축되었으며 멋지더라도 여전히 완벽하지는 않습니다.
뷰 레이어에 대해 어떤 라이브러리를 선택하든 추가 복잡성을 처리해야합니다.

PHP에서는 코드를 변경하고 파일을 저장하며 빌드하거나 다시로드하지 않고도 페이지를 즉시 다시로드 할 수 있습니다. 모든 것이 작동합니다. 그리고 더 중요한 PHP는 완전히 stateless 입니다. 페이지를 다시로드 할 때마다 빈 슬레이트가 있습니다. 전역 변수조차도 각 요청마다 깨끗한 상태를 갖습니다 (그러나 그것들을 사용하는 것은 좋은 변명이 아닙니다 = P). 몇 년 동안 PHP 코드를 작성하지 않았지만 여전히 단순함과 개발자 경험이 그리워요. CakePHP, Symphony 또는 Laravel과 같은 최신 프레임 워크를 사용하는 경우 정교한 엔지니어가 더 환영하는 다른 언어 및 프레임 워크에 비해 많은 것을 놓치지 않습니다. 예외는 속도입니다. PHP는 런타임 성능으로 단순함을 제공합니다. 페이지를 다시로드 할 때마다 모든 코드를 다시 실행해야합니다. HHVM 및 PHP7을 사용하면 성능이 크게 향상되었지만 일반적으로 node.js로 달성 할 수있는 것과는 거리가 멀습니다.

결론

최근에 프런트 엔드에 사용한 라이브러리는 중요하지 않습니다. 당신이 그것을 좋아한다고하더라도 그것이 구텐베르크를위한 최선의 선택을 의미하지는 않습니다.
_ 구텐베르크의 핵심 기여자 대부분이 특정 라이브러리를 좋아할 수 있다는 사실은 중요합니다.

결국 :

자신의 의지에 반하는 사람은 여전히 ​​같은 의견입니다

이 스레드에는 다양한 실행 가능한 라이브러리의 장단점에 대한 정보가 상당히 많이 있다고 생각합니다.

구텐베르크와 워드 프레스의 기고자들은 프론트 엔드 팬보이 들과는 거리가 먼 "닫힌 문"에서 만날 수 있습니다.
당신의 가치, 목표 및 제약을 명확히하고 결과를 극대화하는 것을 기반으로 프레임 워크를 선택해야 할 때입니다.

그리고 당신의 결정에 다시 행운을 빕니다 😃

Vue에 투표했습니다. 초보자에게 친숙하고 견고합니다. Vue를 처음 사용하기 시작했을 때 WordPress로 처음 개발을 시작했을 때 느꼈던 느낌을 받았습니다. + 💯

@ colorful-tones는 초보자에게만 사용하기에는 충분하지 않습니다! 모든 프로젝트에는 라이프 서클이 있으며 대부분의 작업은 유지 보수 진행에 있습니다.

@ChrisCinelli 몇 가지 설명 및 의견 :

Angular는 프런트 엔드 개발을위한 전체 프레임 워크를 제공하기를 원하며 뷰 레이어를 넘어서는 더 많은 것을 가지고 있습니다.

Vue에는 라우팅, 상태 관리, 테스트, Linting 등을위한 공식 라이브러리와 공식 CLI 도구가 있습니다. 이들 모두는 vuejs 조직 아래에 있으며 핵심 구성원이 유지 관리하고 Vue 자체와 동기화되지만 가장 좋은 부분은 배우거나 사용할 필요가 없다는 것입니다 (따라서 'Progressive Framework'철학). React와 달리 이것은 공식적인 형태의 프레임 워크를 효과적으로 만듭니다. 약간의 말장난 :이 모든 것이 Angular보다 배우기 쉽고 빠르며 가볍습니다. :미소:

Marko는 또한 선택적인 Jade / Pug 유사 구문을 추가했습니다.

.vue 파일은 템플릿, 스크립트 또는 스타일 (예 : pug, typescript, coffescript, sass, stylus ...)에 모든 전처리기를 사용할 수 있습니다. 프로젝트에 가장 적합한 것을 사용하십시오!

엔지니어가 데이터를 가져 오기위한 전략과 메커니즘을 제시하도록 요구

이것은 단지 예일 뿐이지 만 데이터를 가져 오는 데 과도한 엔지니어링이 필요하지 않습니다.

async created () {
  const result = await fetch('/api/items')
  this.items = await result.json()
}

거기에서 매우 간단한 Vue 플러그인을 만들어 코드를 더욱 간결하게 만들 수 있습니다.

항상 더 나은 전용 라이브러리가 있기 때문에 Vue 자체가이 작업에 적합한 라이브러리가되어서는 안됩니다 (이것이 예를 들어 우리가 기본적으로 날짜 필터를 제공하지 않는 이유입니다. 어쨌든 대신에 moment 또는 다른 훌륭한 라이브러리를 사용하기 때문입니다) . 또한 여러 비즈니스 및 사용 사례에 대한 권장 경로와 관행이 포함 된 요리 책을 작성하는 중입니다.

일부 코드를 변경하면 다시 컴파일하고 다시 시작해야하며 앱은 다시 초기화를 거쳐야합니다.

유일한 차이점은 빌드 단계로, 오늘날 공식 vue-cli 또는 poi 와 같은 도구를 사용하여 쉽게 설정할 수 있습니다. 파일을 저장하면 앱을 거의 즉시 새로 고칠 준비가됩니다 (빌드 시간은 대규모 프로젝트에서도 매우 유용하며 Symfony와 같은 프레임 워크를 사용하여 대규모 PHP 앱을 개발 한 경험으로 볼 때 더 고통 스럽습니다). 또한 Hot Module Remplacement 기능은 PHP 세계에 존재하지 않는 큰 장점이며 (내가 아는 한) 대규모 프로젝트에서도 브라우저에서 테스트를 위해 새 코드를 사용할 수 있습니다. Sass 컴파일과 같은 비용이 많이 드는 작업-그러나 PHP를 사용할 때 동일한 문제가 발생합니다). 그건 그렇고, Vue는 webpack HMR을 매우 잘 지원합니다.

추가 복잡성을 처리해야합니다.

IMHO, 일부 매우 인기있는 PHP 프레임 워크는 Vue와 같은 일부 프런트 엔드 라이브러리 / 프레임 워크보다 더 복잡하고 배우기 어려운 것 같습니다. (그 반대도 매우 사실입니다.)

구텐베르크와 유사한 블록 기반 편집기를 구축 한 2 년 이상의 경험을 바탕으로 올바른 프레임 워크를 선택할 때 해결해야 할 몇 가지 문제가 있다고 생각합니다.

• VueJS / Marko / Angular는 드래그 앤 드롭과 어떻게 통합됩니까? Gutenberg의 드래그 앤 드롭은 어떻게 작동합니까? 드래그 할 때 고스트 요소를 복제합니까 아니면 기존 요소를 사용합니까? 놓을 때 블록을 놓을 자리 표시자를 어디에 삽입 할 수 있습니까?

• VueJS / Marko / Angular (및 가상 DOM)는 Content Editables 및 DOM Range & Selection API와 어떻게 작동합니까? 이 범위 및 선택의 브라우저 간 불일치는 여기서 확인하기가 매우 어려울 수 있습니다.

• 구텐베르크 편집기에서 복사 / 잘라 내기 / 붙여 넣기는 어떤 확장으로 작동합니까? 여러 블록 사이에서 텍스트를 선택하고 잘라 내기 / 복사 / 붙여 넣기를 수행 할 수 있습니까? 컨텐츠 편집 가능 항목은 각 개별 블록에 있습니까 아니면 모두 편집 가능한 마스터 컨텐츠에 포함되어 있습니까?

• 블로그 게시물에 YouTube 플레이어 또는 트위터 피드를 포함하는 것과 같이 iframe 삽입 가능 항목을 포함하는 Gutenberg 블록이있는 경우이 블록을 한 DOM 위치에서 다른 위치로 이동하면 iframe이 자체적으로 다시로드됩니다. 다른주의 사항으로는 이벤트를 iframe에서 편집기로 다시 전파 할 수 없다는 점이 있습니다 (편집기에서 블록 요소를 드래그하고 커서가 이제 교차 사이트 iframe 위에 있고 모든 것이 작동을 멈춘다 고 상상해보십시오).

모든 프레임 워크는 Virtual DOM으로 작업하는 데 훌륭하지만 많은 WYSIWYG 사용이 Virtual DOM 외부에 있습니다. 구텐베르크에 적합한 프레임 워크를 평가할 때 중점을 두어야 할 영역은 프레임 워크가 DOM 이벤트 처리를 얼마나 잘 처리 할 수 ​​있는지, 프레임 워크로 구축 할 수없는 최첨단 요구 사항을 처리 할 수 ​​있는지, 프레임 워크 외부에서 구축하는 것이 얼마나 관리하기 쉬운 지입니다. 다시 연결합니다.

전망

Wordpress는 새로운 개발자가 배우기에 충분히 쉬우 며 조금 더 자세히 살펴보면 강력합니다. Vue에서도 마찬가지입니다.
WP가이 프레임 워크를 사용한다면 기쁠 것입니다!

내 투표는 VUE입니다!

앞으로 매우 중요하다고 생각되는 맞춤형 웹 구성 요소를 구축하는 측면에서이 사이트는 테스트 매개 변수 및 점수와 함께 나열된 각 프레임 워크에 대한 점수를 제공합니다. 그것은 유익하므로 모든 사람이 한 번 더 주도록 권장합니다.

https://custom-elements-everywhere.com/

VueJS에 대한 나의 투표. 멋진 프레임 워크, 라 라벨이 증명했다고 생각합니다.

WP + Sage 9 (roots.io) + VueJS => 완벽한 스택

Preact에도 문제가있을 수 있습니다.

https://blog.cloudboost.io/3-points-to-consider-before-migrating-away-from-react-because-of-facebooks-bsd-patent-license-b4a32562d268

Preact를 사용하면 반응을 사용하는 것보다 더 나빠질 수 있습니다. Facebook은 귀하가 소송을 시작하지 않았더라도 react 또는 preact 사용을 차단할 수 있습니다. 이 변호사는 Preact가 법정에서 저작권을 유지할 수 없으며 대응을 침해하는 것으로 간주 될 것이라고 생각하는 것 같습니다.

내가 틀렸다면 말해줘. 법률에 대해서는 잘 모르지만 도움이되고 싶었습니다.

나는 이것을 읽었고 우리가 결정한 후 얻은 법률 자문과 유사합니다.
프로젝트에서 React를 버리십시오. 위험이 크다는 것은 아닙니다. 오히려 우리
다운 스트림 클라이언트에 대한 위험을 최소화하고자했습니다. 이 변호사는
동의하는 의견. 대신 Polymer와 Vue를 사용하고 있습니다. 둘 다 잘 작동합니다.
특정 사용 사례를 위해.

2017 년 9 월 20 일 11:04 PM에 "Coding Friend" [email protected]이 작성했습니다.

Preact에도 문제가있을 수 있습니다.

https://blog.cloudboost.io/3-points-to-consider-before-
facebooks-bsd- 때문에 반응에서-멀리 마이그레이션
특허 라이선스 b4a32562d268

Preact를 사용하면 반응을 사용하는 것보다 더 나빠질 수 있습니다. 페이스 북은
시작하지 않았더라도 react 또는 preact를 사용하지 못하도록 차단할 수 있습니다.
고소. 이 변호사는 Preact가 버틸 수 없다고 생각하는 것 같습니다.
그것은 법정에서 저작권이며 반응에 대한 침해로 간주됩니다.

내가 틀렸다면 말해줘. 법률에 대해서는 잘 모르지만 도움이되고 싶었습니다.

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

나는 끔찍한 코드를 본 후에는 WP를 다시는 만지지 않겠다고 맹세했지만 VueJS를 사용하면 Valium을 약간 사용하여 다시 고려할 수 있습니다.

면책 조항 : 저는 변호사가 아닙니다. 다음은 내 의견입니다.

@ codingfriend1 그 기사는 실용적인 장점이 거의 없습니다.

세 가지 가정이 있습니다.

1. 페이스 북은 정확한 내용을 다룰 수있을만큼 광범위한 특허를 보유하고 있습니다.
2. 예를 들어 ABC를 사용하는 회사가 특허 침해로 FB를 고소하면 FB는 반응 특허를 사용하여 ABC를 고소합니다.
3. Facebook의 특허에는 장점이 있습니다.

모든 가정에 대해 자세히 살펴 보겠습니다.

1. 페이스 북은 정확한 내용을 다룰 수있을만큼 광범위한 특허를 보유하고 있습니다.

날짜까지 이것에 대한 증거가 없습니다. 모든 특허는 공개되어 있음을 명심하십시오. 정확한 소스 코드는 공개 된 지식입니다.
더욱이 Jason Miller (정밀 저자)는 "Preact 중 어느 것도 특허를받을 수 없습니다. 너무 분명합니다."라고 주장했습니다.

그래서 저는이 가정이 사실이 아닐 것 같습니다. 가능하지만 가능성은 낮습니다.

1. 예를 들어 ABC를 사용하는 회사가 특허 침해로 FB를 고소하면 FB는 반응 특허를 사용하여 ABC를 고소합니다.

이것은 Facebook의 명성을 파괴 할 것입니다. 나는 FB가 이빨과 못과 싸울 것으로 기대하지만, 그런 식으로 react의 특허를 사용하면 FB를 "특허 트롤"로 분류 할 것입니다.

한편, FB는 법적 수단을 사용하여 싸울 충분한 자원을 가지고 있습니다. 그래서 저는이 가정도 그럴 것 같지 않다고 생각합니다.

1. Facebook의 특허에는 장점이 있습니다.

예, 이것은 사실이 아니라 가정입니다.

실제로 "특허 보유"와 "유효 특허 보유"는 두 가지 다른 것입니다.
나는 법원이 특허를 무효로 판결 한 환상적인 기사를 읽었습니다.

FB의 특허가 너무 넓어서 장점이 없을 가능성이 항상 있습니다.
이제 페이스 북이 특허를 가지고 있다면 _some_ 장점이있을 것이라고 생각할 것입니다. 그러나 논리적으로 말해서 그것이 전제를 다룬다면 그것은 너무 광범위하고 따라서 가치가 없습니다. 따라서 이것은 가정이 가정 1과 직접 충돌합니다.

페이스 북이 자신을 방어하기 위해 특허를 사용하고 있다는 점을 감안할 때 페이스 북의 특허는 집행력이 아니라 광범위하고 가치가 없을 가능성이 높습니다.

결론:

세 가지 가정은 모두 테스트되지 않았습니다. 그들 모두가 사실로 판명되고 기술적으로 가능하다면, "예, preact를 사용하는 것은 위험합니다."

그러나 실제로 세 가지 가정이 모두 참일 가능성은 너무 낮습니다. 특히 가정 1과 3을 함께 사용하면 더욱 그렇습니다.

따라서 법원이 달리 규정하지 않는 한 preact (및 기타 vdom 라이브러리)를 사용하는 것이 매우 안전하다고 말할 수 있습니다.

포인트 1과 관련하여 Facebook은 브라우저 스크립트에서 Efficient event delegation 이라는 특허를 보유하고 있습니다. 그것은 기본적으로 jQuery의 live() 함수입니다 (나중에 jQuery API에서 on() 일부가 됨)!

그러나 가정의 타당성과 관계없이 WordPress가 React에서 멀어지는 이유는 WordPress에 Facebook에 대한 우려가 있기 때문이 아닙니다 . 그리고 난에서 인용하고있어 발표 포스트 (강조 광산) 위의 문제에 링크 :

저는 Facebook의 조항이 회사가 취할 수있는 보다 실제로 더 명확 하다고 생각합니다. 페이스 북의 특허 조항이 괜찮다고 세상을 설득하는 것은 우리가 취할 수있는 것이 아닙니다.

이를 바탕으로 특허가 WordPress를 멀어지게 한 것은 인식, 혼란 및 질문입니다. 이전 의견에서 설명한 것처럼 Preact에도 동일한 우려가 적용된다고 생각합니다.

포인트 1과 관련하여 Facebook은 브라우저 스크립트에서 Efficient event delegation이라는 특허를 보유하고 있습니다. 이것은 기본적으로 jQuery의 live () 함수입니다 (나중에 jQuery API에서 on ()의 일부가 됨)!

그것은 그들이 이벤트 위임 아이디어를 발명했다는 것을 의미합니까?! 1995 년으로 거슬러 올라가는 인용문이 있습니다. 그게 무슨 뜻입니까?

@ChrisCinelli 는 Marko의 경우 "지수 적 성장의 변곡점으로 보이는 것"에 대해 언급했습니다.

저는 이것이 단순히 규모의 문제라고 믿습니다. 프로젝트에 5k 또는 10k Github 별이있는 경우, 예를 들어 Hackernews의 상단 페이지에있는 링크와 같은 단일 발생은 하루에 1 천 개의 별을 가져올 수 있으며 Marko의 경우 최근 숫자의 20 %입니다.

Vue가 가지고있는 65,000 개의 별 규모에서는 그다지 눈에 띄지 않습니다. 별 역사 스크립트가 작동하는 방식으로 인해 어느 시점에서 변동이 전혀 표시되지 않고 끝까지 직선 일뿐임을 알 수 있습니다.

이러한 상황은 Marko 자체에만 국한되지 않고 Inferno 또는 최근 Vue에서 영감을받은 마이크로 프레임 워크 인 MoonJS에서 발생했습니다. 최근 전체 React 특허 드라마로 인해 얼마나 많은 스타를 얻었는지에 따라 Preact가 비슷한 지점에 있다고 말할 수도 있습니다.

당신은 당신과 같은 소스의 다음 그래프에서 내가 말하는 것을 볼 수 있습니다.

이러한 사람들이 실제로 개발중인 프레임 워크를 사용 해보고 프로덕션에서 사용하고 나중에 계속 사용할 것인지 시간이 알려줄 것입니다. 다른 모든 오픈 소스 라이브러리와 마찬가지로 Marko가 잘되기를 바랍니다.

Vue는 큰 변동이없는 안정적인 성장입니다. 현재 속도로 크리스마스 이전에 React에서 최고가되어야합니다. 적어도 Github에서는. :)

@aurelia는 어떻습니까?
웹 사이트 : aurelia.io
@EisenbergEffect 가 이것을 만들었습니다.

저에게는 훌륭한 프레임 워크입니다!

1. 단순 규칙 (사용자 정의 가능)
2. 일반 HTML
3. 바닐라 JS
4. 프레임 워크 개입 없음!

사용하려는 라이브러리 (jQuery, Vue.js, Preact, Ember, HyperHTML 등)를 플러그인하고 Aurelia에 사용 방법을 가르 칠 수도 있습니다!

매우 간단하고 표준 기반이므로 커뮤니티 지원도 필요하지 않으며 커뮤니티 지원이 정말로 중요하다고 생각하면 도움을받을 수 있습니다 (별 1 만 개 이상).

@aurelia 리소스 :

1. Aurelia 소개
2. Aurelia 블로그
3. Aurelia 문서

React가 MIT에서 재 라이센스 된 것 같습니다 : https://code.facebook.com/posts/300798627056246

이제 결정을 뒤집어 야한다고 생각합니다.

홀리 몰리! React가 다시 돌아 왔습니다. WordPress가 그랬습니까? 확실하지 않다! 오전 3시이고 나는 이것에 대해 매우 흥분됩니다! 당신은 어떻습니까!

React, Jest, Flow 및 Immutable.js 다시 라이선스

다음 주에는 오픈 소스 프로젝트 인 React, Jest, Flow 및 Immutable.js를 MIT 라이선스에 따라 다시 라이선스 할 예정입니다. React는 웹용 오픈 소스 소프트웨어의 광범위한 생태계의 토대이기 때문에 이러한 프로젝트를 재 라이선스하고 있으며 비 기술적 인 이유로 진행 상황을 보류하고 싶지 않습니다.

이 결정은 우리 커뮤니티에 대한 실망과 불확실성의 몇 주 후에 나온 것입니다. 우리는 여전히 BSD + 특허 라이센스가 우리 프로젝트 사용자에게 몇 가지 이점을 제공한다고 믿지만이 커뮤니티를 결정적으로 설득하지 못했다는 것을 인정합니다.

라이선스에 대한 불확실성으로 인해 많은 팀이 React의 대체 라이브러리를 선택하는 과정을 거쳤 음을 알고 있습니다. 이탈에 대해 죄송합니다. 우리는 이러한 변화를 통해이 팀을 되 찾을 것으로 기대하지 않지만 문을 열어두고 싶습니다. 이 공간에서의 우호적 인 협력과 경쟁은 우리 모두를 앞으로 나아가게하고 우리는 충분히 참여하고 싶습니다.

이러한 변화는 자연스럽게 나머지 Facebook의 오픈 소스 프로젝트에 대한 질문을 제기합니다. 우리의 많은 인기 프로젝트는 현재 BSD + 특허 라이선스를 유지합니다. 이러한 프로젝트의 라이선스도 평가하고 있지만 각 프로젝트는 다르며 대체 라이선스 옵션은 다양한 요인에 따라 달라집니다.

다음 주 React 16 릴리스에 라이선스 업데이트를 포함 할 것입니다. 우리는 1 년 넘게 React 16에서 작업 해 왔으며, 대규모 사용자 인터페이스를 구축하는 모든 사람에게 도움이 될 강력한 기능을 잠금 해제하기 위해 내부를 완전히 재 작성했습니다. React를 다시 작성하는 방법에 대해 곧 공유 할 것이며, 우리의 작업이 React를 사용하든 사용하지 않든 모든 곳에서 개발자에게 영감을 줄 수 있기를 바랍니다. 우리는이 라이선스 논의를 뒤로하고 우리가 가장 중요하게 생각하는 것, 즉 훌륭한 제품을 배송하기를 고대하고 있습니다.

제 생각에는 MIT 라이선스와 가장 활발하고 가장 큰 오픈 소스 JS 커뮤니티를 통해 React가 고수 할 수있는 확실한 선택이라고 생각합니다.

내 투표는 이제 React로 돌아 왔습니다 . — 인류에 대한 믿음이 회복되었습니다.

비슷한 댓글 대신 👍로 투표하세요.

React 라이센싱의 이러한 변화에 참여한 Wordpress에 대해 큰 감사를 표하고 싶습니다.

나는 여전히 Vue가 더 나은 해결책이라고 생각합니다. Vue의 많은 강점은 여전히 ​​적용되지만, 초보자 친화적이고 빌드 단계를 사용할 필요가 없다는 점을 지적하고 싶습니다. 제 생각에는 워드 프레스 환경의 킬러 기능입니다.

질량
확실히
vueJS 용

또한 가장 큰 커뮤니티, 강력한 개발자 팀, 안정적이고 완전한 생태계를 보유한 Angular2.0 + (AngularJS가 아님)를 선택했습니다.

@CrazyBBer 가장 큰 커뮤니티 인 Angular 2/4에 대한 데이터는 어디에서 찾을 수 있습니까? 블로그 게시물에 도움이 될 것입니다.

어쨌든 끝났습니다. React는 WordPress와 함께하기 위해 여기에 있으며 Vue 애호가 로서도 React로 이미 작성된 코드의 양을 고려할 때 상황을 바꿀 수있는 최선의 방법을 발견했습니다.

@ahmadawais @gustojs Reddit의 사람들은 MIT가 저작권만을 다루기 때문에 개발자가 React를 사용할 때 특허권을 가지지 않을 것이라는 우려를 제기했습니다.

또한이 진술은 정말 나를 괴롭 힙니다.

우리는이 커뮤니티를 단호하게 설득하지 못했음을 인정합니다.

효과적으로 "우리는 틀리지 않았습니다. 개발자들은 우리를 이해하지 못했습니다."

@ahmadawais : 나는 아직도 당신이 변덕이 될 수 라이선스 어떻게 반응하는지 등의 완벽한 예를 본 적이으로 뷰와 함께가는 것이 더 나은 선택이 될 것이라고 생각 먼저 그들은했다 BSD + Patents license MIT로 전환 한 지금. 가까운 장래에 FB 소유의 라이센스 / 특허로 다시 전환하면 모든 사람이 말리기 위해 쫓겨날 것입니다. Vue는 처음부터 MIT였으며 주요 기업이 주도하는 기업보다 커뮤니티 주도적입니다.

게다가 @ atanas-angelov-dev가 말한 것.

지금 전환 할 필요가 없습니다.
Vue가 더 나은 관점을 제공한다고 생각하지만 모든 것을 다시 작성하는 것을 의미합니다.

아! 어서 오세요, Aurelia에게 기회를주세요!
Angularjs 팀의 수석 개발자 중 한 명이 만들었습니다.
Vue.js처럼 소규모 채택에서 전체 프레임 워크로 이동할 수 있습니다.

@azure 포털 팀조차도 지금 시작했다면 녹아웃 대신 Aurelia를 선택했을 것이라고 말했습니다!
그리고 누가 압니까?! 그들은 이제 조금씩 Aurelia로 마이그레이션 할 수 있습니다.

조금 시작하세요. 좋아할 거라는 걸 알아요!

Nirmal4G,
당신의 논문은 판매 적으로 너무나 말도 안되게 들립니다.
사실 저는 전체 프레임 워크에이 404 페이지와 동일한 결함이 있다고 생각합니다.
http://aurelia.io/get-started.html

@ bovas85 판매상 이 아니고, 저는 그 팀의 일부도 아닙니다 . 그들은 내가 그들의 프레임 워크를 사용하고 있다는 사실조차 모릅니다.

@ cr101 / cc

표지로 책을 판단하지 마세요

Aurelia에 대해 알기 전에도 많은 인기있는 프레임 워크를 사용해 왔습니다. 모든 기준의 균형을 맞춰 스택을 쌓아야한다면 내 애플리케이션 (대규모 애플리케이션이라고 믿으세요)의 경우 Aurelia가 1 위를 차지하고 Vue가 그 뒤를이었습니다.

전체 프레임 워크에는 게시물에서 직접 연결하는이 404 페이지와 동일한 결함이 있다고 생각합니다.

내가 게시 한 모든 링크는 404 페이지로 이동하지 않습니다. http를 https 사이트로 리디렉션하는 것은 github의 잘못입니다. 이제 수정되었습니다. 봐, 버그. 버그가없는 프레임 워크를 알려주세요. 감히 요.

다른 프레임 워크를 사용하면 많은 중복 된 (아직 유용한) 추상화가 있습니다. W3C 커뮤니티는 API에 공개 프레임 워크 디자인을 채택하지 않으므로 많은 추상화가 있습니다.

모든 프레임 워크는 이전 버전과의 호환성에 초점을 맞추고 있기 때문에 이전 버전과의 호환성을 잃지 만 Aurelia는 HTML의 W3C 및 ECMAScript 사양을 고수하는 한 코드가 잘 작동합니다.

_Aurelia가 없다면 Vue를 고수하는 것도 괜찮습니다. 차선책입니다 ._

_ 표준을 재발 명하는 새로운 방법을 만드는 것보다 표준을 받아들이는 문제입니다 ._

@ Nirmal4G 는 귀하의 주장에 대한 증거를 제공하거나 이름을 피하십시오. 특히 LOC와 관련하여 Vue가 hyperHTML보다 적 었다고 믿지 않습니다. vue와 비교하여 hyperHTML로 작성한 모든 것은 LOC가 적어 레이아웃과 로직을 결합했습니다 . 내가 LOC를 어떤 것과 관련된 메트릭이라고 믿지 않는 한, 입증되지 않은 FUD를 읽는 것은 나에게 공정하지 않은 것 같습니다.

@WebReflection 당신의 말을 잡아, 나는 당신이 Vue보다 더 나쁘다고 말하지 않았습니다. 내가 당신을 화나게했다면 미안합니다.

내 응용 프로그램은 던질 수있는 모든 것을 사용합니다. 많은 프레임 워크가있는 프로토 타입을 시도했습니다. 기준 중 하나는 LOC 였지만 시각적 관점에서는 프레임 워크 성능을 향상시킬 수 있다고 생각하는 이유가 아니라 이름과 함께 제공되는 디자인 선택입니다.

저는 HyperHTML을 평가했습니다. 성능은 인상적이었고 polyfill은 훌륭하지 않았지만 슬프게도 내 요구 사항에 맞지 않았습니다.

모든 프레임 워크에는 한 가지 더 나은 것이 있습니다. 제 소원은 누구나 신성하고 더 나은 디자인으로 모든 프레임 워크의 최고를 결합 할 수 있다면 그렇게되지 않을 것입니다. 그래서 저는 프레임 워크가 미래에 스스로 개선 될 수있는 것과 그렇지 않을 것의 균형을 찾아야합니다.

React가 이제 MIT가 될 것이라는 소식을 들으니 정말 기쁩니다.
이 프로젝트에 대해 매우 흥분하고 React와 WP API가 완전히 지원되면 오랜 시간 후에 WordPress를 다시 사용하기를 기대합니다. :)

실제 React 라이센스가 무엇인지 기다려 보겠습니다. MIT 또는 MIT + 특허 ..? ;)

개인적으로 저는 React를 좋아하지만 Vue가 더 생산적이라고 생각합니다. 어느 쪽이든 기쁘지만 ...

... 커뮤니티의 Vue에 대한 강력한 지원을 염두에두고 라이선스 외에도이를 고려할 것을 제안합니다.

Vue는 WordPress에 더 적합한 선택 인 것 같습니다.

Facebook은 소송 트랩에서 4 개의 항목을 제거했습니다. 다음은 모두 MIT 라이선스입니다.

• 반응
• 농담
• 흐름
• Immutable.js

한편, Facebook의 카테고리 X 라이선스는 다음 항목에 계속 적용됩니다.

• 네이티브 반응
• GraphQL
• 실
• 계전기
• Atom IDE
• 그리고 아마도 그들에 의해 만들어지고 "오픈"소스에서

나는 여전히 Vue를 사용한다고 말합니다. 장기적으로 볼 가치가 있습니다. 어쨌든 Wordpress에 대해 React는 전혀 이해가되지 않았습니다. PHP 커뮤니티에 너무 많이 포함되어 있기 때문에 Vue는 항상 가장 현명한 선택처럼 보였습니다 (또한 React처럼 사용하는 것이 고통스럽지 않습니다).

한편, Facebook의 카테고리 X 라이선스는 다음 항목에 계속 적용됩니다.

네이티브 반응
GraphQL
실
계전기
Atom IDE
그리고 아마도 그들에 의해 만들어지고 "오픈"소스에서

@TheJaredWilcurt 죄송하지만 해당 목록에서 원사를 제거하고 싶을 수 있습니다. 원 사는 이러한 "Facebook Category X"라이센스가 없습니다-> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

Reddit의 사람들은 MIT가 저작권 만 다루기 때문에 개발자가 React를 사용할 때 여전히 문제가 있다고 생각하는 특허권을 가지지 않을 것이라는 우려를 제기했습니다.

MIT는 훌륭한 라이센스입니다. jQuery도 MIT 라이센스입니다. 나는 당신이 그것을 알고 있기를 바랍니다.

@vinayakkulkarni 저는 변덕스러운 React 라이선싱이 어떻게 될 수 있는지에 대한 완벽한 예를 보았 기 때문에 Vue와 함께가는 것이 더 나은 선택이 될 것이라고 생각합니다. 가까운 장래에 FB 소유의 라이센스 / 특허로 다시 전환하면 모든 사람이 말리기 위해 쫓겨날 것입니다. Vue는 처음부터 MIT였으며 주요 기업이 주도하는 기업보다 커뮤니티 주도적입니다.

그것이 작동하는 방식이 아닙니다. 나는 비슷한 질문에 대해 Facebook에 대한 Samuel의 의견을 읽었습니다. MIT에 라이센스를 부여하면 라이센스를 변경하기 위해 포크하거나 할 수 없습니다. 저는 변호사가 아닙니다.

또한 개인적으로 페이스 북은 사람들을 속이는 것이 아니라 선의의 몸짓으로 한 것 같습니다. 그것은 나에게 의미가 있습니다.

또한 개인적으로 페이스 북은 사람들을 속이는 것이 아니라 선의의 몸짓으로 한 것 같습니다. 그것은 나에게 의미가 있습니다.

그것은 매우 논리적 인 진술이 아닙니다. 부정적인 일을 한 번도하지 않은 그룹에 대한 보상보다는 부정적인 일을 중단했기 때문에 한 그룹에 대한 보상입니다. 또한 위에서 언급했듯이 다른 유사한 프로젝트에서 여전히 카테고리 X 라이선스를 사용하고 있으며 이는 나에게 선의의 표시가 아닙니다.

Vue는 훨씬 더 부드러운 학습 및 채택 곡선을 가지고 있습니다.
그리고 그것은 처음부터 WordPress의 주요 기본 아이디어였습니다.

@ahmadawais 내가 알아요-MIT는 라이센스만큼 훌륭하지만 이것은 큰 "그러나"Facebook은 React에 대한 특허를 보유하고 있으며 MIT는 어떤 목적 으로든 코드를 사용할 수 있도록 허용하지만 여전히 Facebook의 저작권을 침해 할 수 있습니다. 특허 (이 모든 것을 소금 덩어리로 가져 가십시오-IANAL)

그리고 주제를 유지하기 위해 Vue에서도 WordPress를 훌륭하게 만든 많은 것을 보았습니다. 겸손한 의견으로는 Vue만큼 배우고 사용하기 쉬운 다른 적절한 라이브러리는 없습니다.

Facebook은 React에 대한 특허를 보유하고 있습니다.

React의 어떤 부분이 특허를 받았다고 생각하십니까? (리 액트의 어떤 것도 특허를 얻지 못했습니다. 먼저 연구를 시도하십시오) 링크를 보여주지 "분명히"가 아니라 .., 이것은 전혀 도움이되지 않는 종류의 코멘트입니다. 좋아하는 라이브러리를 추천하고 싶다면 FUD를 퍼뜨리는 것이 아니라 그 장점을 보여주는 올바른 방법으로 수행하십시오.

React에 특허가 없는데 원래 BSD + Patents로 이동 한 이유는 무엇입니까? 페이스 북은 그들이, 또는 그들이 무엇을하지 무엇 말했다하지 않았습니다.

왜 2 년 동안 라이센스를 엉망으로 만들고 포트폴리오의 일부만 변경하고 변경 하지 않겠다고 일관되게 말하면서 "그냥 처리하세요. 사용 여부는 상관 없습니다"라고 말한 이유입니다.

"새로운"라이선싱에서 React Native, GraphQL 등을 제외하는 이유는 무엇입니까? React의 향후 버전은 무엇으로 전환 될까요? 불만을 제기하는 사람에 따라 Facebook에서 2 단계 라이선스를 보유하고 있다는 보장은 없습니다.

React Native 코드의 일부가 React로 롤링되면 어떨까요? GraphQL 구현이 코드베이스로 작동한다면 어디에 서 있습니까 ..?

Facebook의이 조치는 답변보다 더 많은 질문을 제기하며, 여전히 React의 모든 단일 사용이 진정한 오픈 소스 프로젝트에 대한 잠재적 인 위험임을 의미합니다.

PHP 세계에 이미 구축 된 수하물이없는 라이브러리 인 Vue를 채택하기 만하면됩니다.

@bjrmatos https://www.google.com/patents/US20170221242 맞아요 !

Vue에 또 다른 +1. Facebook은 여전히 ​​프로젝트 전반에 걸쳐 두 개의 라이선스를 사용합니다. 그 좋지 않다.

@PericlesSouza 당신은 분명히 페이스 북과 같은 회사가 일을 개선하고 웹을 발전시키기 위해하는 큰 노력을 무시하고 있습니다 .MIT의 변경 사항에 대한 게시물을 읽으면 모든 질문에 답할 수 있습니다. 왜 아직도 MIT 라이선스에 대해이 비합리적인 우려를 제기하고 있는지 모르겠습니다. 변경 사항으로 인해 React는 다른 "True Open Source"프로젝트와 동일한 위치에 있습니다 (True Open Source 프로젝트라고 부르는 것이 무엇인지 모르겠습니다) btw).

@Raymonf 글쎄, 기본적으로 모든 최신 프레임 워크는 이미 해당 특허 (Vue 포함)를 위반했기 때문에 React, Vue 또는 링크에 설명 된 개념을 구현하는 다른 프레임 워크 (btw 기본적으로 모든 웹)를 사용하든 상관없이 누구나 동일한 위치에 있습니다. 프로젝트가 이미 다른 회사가 소유 한 2 ~ 3 개의 특허를 위반하고있는 경우, 현재 회사가 어떤 종류의 특허를 보유하고 있는지 알고 놀랄 것입니다.) 정말 걱정된다면 UI를 그런 방식으로 업데이트하는 프레임 워크를 사용할 수 없다는 뜻입니다. 따라서이 법적 맥락에서 더 좋거나 더 나쁜 대안은 없습니다.

나는 이러한 종류의 대화에 다시 참여하고 싶지 않습니다. 합의에 도달하는 것이 불가능하므로 내 의견을 중지 할 것입니다. React 커뮤니티는 MIT 로의 변경에 만족합니다 (원래 라이센스를 더 많이 비방하는 사람들조차도)

결정에서 워드 프레스 팀에게 행운을 빕니다. React BSD + Patents 라이센스에 대한 주요 문제가 해결되었으며 이제 결정하는 것이 그들의 임무입니다.

그래서 Facebook은 최근 React에 대한 라이선스를 변경했습니다. WordPress가 계속해서 React를 사용하거나 기본 프런트 엔드 프레임 워크를 변경한다는 의미입니까?

@bjrmatos 이것은 전혀 사실이 아닙니다.

기본적으로 모든 현대적인 프레임 워크는 이미 그 특허를 위반하고 있습니다.

예를 들어, hyperHTML은 가상 DOM을 사용하지 않고, 정규 콜백 호출 (특허 불가 )을 통해 DOM API (특허 불가)를 직접 사용하고 유일한 diffing 알고리즘을 사용하여 c hildNodes : after 노드 목록은 Levenshtein 거리 (특허 불가)와 최소 스플 라이스 작업량 (특허 불가, 내가 작성했고 ISC )을 기반으로합니다.

그리고이 시점에서 나는이 쓰레드가 쓸모없고 무의미하다고 생각하지만, FUD를 계속 퍼뜨릴 필요성을 이해하지 못합니다. 당신이 선택하고 그것을 좋아한다면, 다른 사람들에게 그들이 뭔가 잘못하고 있거나 당신과 같은 문제에 처해 있다고 말할 이유가 없습니다. 나는 우리가 이것에 동의 할 수 있기를 바랍니다.

@noncototient 그것은 백만 달러 질문입니다, 그렇지 않습니까? 💯

토론이 조금 무의미 해지면서 여기에서 구독을 취소했습니다.
좋은 점이 많이 나왔고이 호를 꼼꼼히 읽어 주신 모든 분들에게 배움의 경험이라고 생각합니다.

동의합니다. 이것은 이제 무의미합니다. 이 스레드를 잠그는 것이 좋습니다 (또는 기여자 만 해당). 이 문제에 대한 충분한 피드백이 있었고 이제는 비 건설적인 논쟁으로 이어질 지점에 도달하고 있습니다.

이 문제가 종결됩니까?
@WordPress 는 지금 새로운 JavaScript Framework로 마이그레이션하는 데 관심이없는 것 같습니다. 🤔

저는 개인적으로 @vuejs를 좋아합니다. 하지만 지금은 중요하지 않은 것 같습니다. 😅

개인적으로 나는 Vue를 선호합니다.

저와 다른 많은 사람들에게는 라이선스에 관한 것이 아닙니다. 이것은 React에서 멀어지는 변명 일뿐입니다.

Marko는 엄청나게 강력하고 쉽습니다. 우리는 현재 50,000 개의 제품으로 역동적 인 웹 스토어를 완전히 재 작성하고 있으며, 그것은 놀랍고 매우 깊은 기능입니다. 이 길을 가고 뒤돌아 보지 마십시오.

Marko 는 좋지만 Prarko 는 100 바이트 더 작고 (GZipped) 자체 최적화 테스트에서 0.01 % 더 빠르므로 다른 사람이 사용하지 않더라도 대신 사용해야합니다. 내일 Plarko 가 출시되지만 Fibre가 추가되어 _

죄송합니다. 이것이 나머지 스레드가 진행되는 방식입니다.

기다렸다가 실제 라이선스가 나왔을 때 어떤 것인지, Facebook의 2 단계 라이선스의 의미가 무엇인지 살펴보고, 문제를 철저히 조사한 후 WordPress 팀이 어떤 결정을 내 렸는지 살펴 보겠습니다.

원래는 커뮤니티가 좋아하는 엔진에 대한 의견을 요청했습니다. 그리고 그것은 사람들이 게시하는 것처럼 보이지만 어떤 사람들은 요청 된 내용과 일치하는 댓글을 보내기 위해 사람들을 뛰어 넘습니다. 좀 이상합니다.

여기에 언급 된 모든 라이브러리 / 프레임 워크는 훌륭합니다. 일부는 다른 시나리오보다 일부 시나리오에 더 적합합니다. 각각은 그들의 옹호자를 가질 것이며, 각각은 개발주기에 따라 성능 / 기능 측면에서 다른 사람들을 도약 할 것입니다.

대부분의 프로젝트에서하는 것처럼 간단한 질문으로 시작할 수 있습니다.

1. SPA 프레임 워크가 필요 합니까?

대답이 예인 경우 이유를 자세히 설명하십시오. 그러면 잠재적 인 후보를 평가할 수있는 일련의 기준이 제공됩니다. 아마도 서버 측 렌더링, 아마도 라우팅 등을 위해.

그렇지 않은 경우 다음 질문을하십시오.

1. 템플릿 엔진이 정말 필요한 가요?

VanillaJS는 지구상에서 가장 큰 커뮤니티를 보유하고 있으며 라이선스 문제가 없습니다. 또한 표준을 준수합니다.) 및 ES6 모듈을 사용하면 React, Vue, Preact, Aurelia 등과 같은 _template_ 엔진을 사용할 수있는 플러그인 지원 기능과 함께 핵심 개발에 적합한 기반을 제공 할 수 있습니다. 개발자의 요구에 따라 향후 몇 년 동안.

Matt Mullenweg가 답변을 게시했습니다 ...

지난주에 제가 쓴 특허 조항을 페이스 북이 철회 할 것이라는 소식을보고 놀랐습니다. 그들은 React 16에서 라이센스가 특허 추가없이 일반 MIT가 될 것이라고 발표했습니다. 이러한 움직임에 대해 Facebook에 박수를 보내고, 모든 오픈 소스 프로젝트에서 특허 조항 사용이 재검토되기를 바랍니다.

이전 입장을 기반으로 React에서 벗어나기로 한 우리의 결정은 WordPress 세계에서 많은 흥미로운 토론을 불러 일으켰습니다. 특히 Gutenberg에는 개발자가 Preact, Polymer 또는 Vue를 포함하여 선택한 라이브러리에서 Gutenberg 블록 (Gutenblocks)을 작성할 수있는 접근 방식이있을 수 있으며 이제 React는 공식적으로 지원되는 옵션이 될 수도 있습니다.

지금까지 토론에 참여 해주신 모든 분들께 감사드립니다. 정말 감사합니다. 여기와 Hacker News 및 Reddit에 대한 의견에서 활발한 토론과 토론은 사람들이 가져온 열정과 다양한 관점에 대해 배울 수있는 기회에 큰 도움이되었습니다. 페이스 북이 듣는 것이 더 좋았습니다.

→ https://ma.tt/2017/09/facebook-dropping-patent-clause/

@ahmadawais @m

이전 입장을 기반으로 React에서 벗어나기로 한 우리의 결정은 WordPress 세계에서 많은 흥미로운 토론을 불러 일으켰습니다. 특히 Gutenberg에는 개발자가 Preact, Polymer 또는 Vue를 포함하여 선택한 라이브러리에서 Gutenberg 블록 (Gutenblocks)을 작성할 수있는 접근 방식이있을 수 있으며 이제 React는 공식적으로 지원되는 옵션이 될 수도 있습니다.

그 상황은 모두에게 승리처럼 보일 것입니다. 이것이 실제로 어떻게 진행되는지 기다려 봅시다.

지금이 문제를 닫으세요. 세상이 얼마나 변덕 스러운지 보러갑니다. 사람들이 말을 지키지 않는 것을 보면 슬픈 일입니다.

[편집 : 불쾌감을주는 진술로 인해 제거됨]

Gutenberg를 사용해야하는 모든 사람에게 행운을 빕니다.

평화.

👋 저는 우리 모두가 여기서 많은 논의를했다고 생각합니다. 이 문제에 대해 이야기하고 논평 할만큼 관심을 가지고있는 모든 분들께 감사드립니다. IMHO 지금 우리가 가진 모든 옵션이 좋은 옵션 인 것 같습니다.

더 나은 프레임 워크에 구애받지 않는 API로 끝나면 앱에서 원하는 JS 프레임 워크를 사용할 수 있습니다. MIT 라이센스를 통해 React는 좋은 (읽기 호환 가능한) 오픈 소스 라이센스를 가진 다른 라이브러리와 마찬가지로 코어에서 사용할 수있는 강력한 위치를 차지합니다.

🎯 특정 JavaScript 프레임 워크를 응원하거나 빌드 한 경우 (핵심 팀) WordPress 개발자를위한 실제 예제를 빌드하여 사람들이 WordPress 기반 앱에서 선호하는 JavaScript 프레임 워크를 사용하는 아이디어를 가지고 놀 수 있도록 제안합니다. 짓다.

지금은이 티켓을 닫습니다. 그리고 플랫폼과 커뮤니티로서 워드 프레스의 성공에 더 많은 기여를하고자합니다. 여기 모든 사람들에게 똑같은 것을 기대합니다. 나는 이것이 WordPress 소프트웨어로 작업하는 모든 사람들에게 롤러 코스터 모험이 될 것이라고 진정으로 믿습니다.

지금부터 몇 년 전처럼 사용자 (인터넷 사이트의 약 30 %)가 더 쉽게 사용할 수 있도록 소프트웨어를 개선 할 수도 있습니다. 나는 여러분 모두처럼 여기에서 WordPress를 응원합니다!

건배!

React에서 멀어지기로 한 결정이 철회되었는지 Matts의 의견에서 명확하지 않습니다.

첫째 , 페이스 북이 사용할 실제 라이선스가 아직 게시되지 않았기 때문에 모든 것이 끝난 척하는 것은 실제로 현명한 움직임이 아닙니다.

둘째, Facebook이 따르는 2 계층 라이선스를 다루지 않습니다. React는 MIT 일 수 있지만 React Native는 + (비공개) Patents 입니다.

그래서 .. 둘 다 공유하는 구성 요소는 어떻습니까?

React에서 사용되는 React Native 코드는 어떻습니까? Fiber는 두 개의 서로 다른 라이센스간에 공유됩니까? 아니면 GraphQL 코드가 React로 들어가나요?

모든 관련 Facebook 프로젝트가 다른 라이선스로 게시되고 Facebook이 React의 일부 측면이 실제로 React Native Patent Grant 또는 Fiber의 적용을받는다고 결정하는 경우 WordPress가 React 경로를 따라 내려 가면 어떻게 되나요? 특허 부여?

진지하게, 이것에 대해 매우 신중하게 생각하십시오. 이 문제가없는 대다수가 선호하는 대안이있을 때 위험을 감수하는 이유-Vue.

바람에 따라 바뀌는 라이선스 계약을 제대로 생각하는 대신 믿지 않을 것입니다. 페이스 북의 변호사들은 이것을 변덕스럽게 바꿀 수 있습니다.

진정한 오픈 소스를 고수하십시오.

@PericlesSouza 라이센스는 블로그 게시물의 설명에서 사람들이 상상하는 것과 정확히 일치합니다. 표준 MIT 라이센스, 그 이상은 아닙니다. React는 React Native에 의존하지 않습니다. 두 사람이 공유하는 조각은 React Native가 아닌 React 프로젝트에 있습니다. React와 FB 소유의 종속성은 우리 팀이 변경 사항을 커밋 할 시간이 생기는 즉시 MIT에서 사용할 수 있습니다. 우리는 재미있는 사업을 계획하고 있지 않습니다.

뿡 빵뀨

당신은 페이스 북에서 일합니다. 귀하가 Facebook을 대신하여 발언 할 권한이있는 변호사가 아니라면 귀하가 주장하는 내용은 중요하지 않습니다. 어떤 코드를 작성하든 상관 없습니다. 죄송합니다.

"Imagining"라이센스는 법정에서 인정되지 않습니다.

예를 들어 Facebook이 특허 보조금을 채택한 이유, 특허가 무엇인지 (또는 그렇지 않았는지) 또는 'IANAL'(I Am Not A Lawyer)이라고 말하지 않고 지금 변경한다고 말하는 이유를 명확하게 설명 할 수 있습니까?

두 사람이 공유하는 조각은 React Native가 아닌 React 프로젝트에 있습니다.

그러나 법적 보장을 통해 그렇게 말할 수 있습니까? 아니?

React 및 FB 소유 종속성은 우리 팀이 변경 사항을 커밋 할 시간이 생기는 즉시 MIT에서 사용할 수 있습니다.

React가 MIT에 게시되도록하기 위해 어떤 부분이 제거되고 있습니까? MIT를 준수하지 않았던 _ 비 FB 소유 종속성 _이 이미 사용 중 이었습니까? Facebook의 변호사는 모든 것이 실제로 MIT를 준수한다고 보장할까요? Apache Software Foundation이이를 인증하는 데 얼마나 걸립니까?
.

분명히 2 계층 라이선스가있는 두 프로젝트간에 코드가 공유된다는 점을 강조하는 것이 옳은 것 같습니다.

당신은 내 말을 왜곡하고 있습니다. React와 React Native간에 공유되는 코드는 MIT에 따라 라이센스가 부여됩니다. Fiber로 생각하는 모든 것은 MIT에 따라 라이센스가 부여됩니다. React는 BSD + Patents 또는 귀하가 멸시하는 기타 특허 허가에 따라 라이센스가 부여 된 코드를 포함하거나 의존하지 않습니다. React에서 부품을 제거하지 않습니다. 내가 아는 React의 유일한 non-FB 소유 종속성은 MIT에있는 객체 할당입니다.

나는 당신이 내 말을 법적 보증으로 받아들이라고 제안하는 것이 아닙니다. 우리는 여기에 내 의견이 React의 라이센스를 변경하지 않는다는 것을 알고 있습니다. 회의적 일 수 있고 지금 나를 믿을 필요는 없지만 하루나 이틀 안에 내가 여기서 말하는 것이 사실임을 알게 될 것입니다.

뿡 빵뀨

나는 당신의 말을 왜곡하지 않습니다. 그리고 당신이하는 일과 여기에 참여할 준비가되어있는 것을 존중합니다.

나는 단순히 페이스 북으로부터, 회사의 권한있는 임원이 외부 오픈 소스 기관에 의해 확인을받지 않는 한, 우리는 여전히 우리가 시작한 것과 같은 위치에 있습니다. 실제 법적 상황이 무엇인지 아무도 확신 할 수 없습니다. 다음과 같이 진술함으로써 동의하는 것입니다.

나는 당신이 내 말을 법적 보증으로 받아들이라고 제안하는 것이 아닙니다. 우리는 여기에 내 의견이 React의 라이센스를 변경하지 않는다는 것을 알고 있습니다.

과:

Fiber로 생각하는 모든 것은 MIT에 따라 라이센스가 부여됩니다.

내가 Fiber라고 생각하는 것은 중요하지 않습니다. Facebook 변호사와 출원 된 특허가 Fiber로 정의하는 것에 전적으로 의존합니다.

React Native가 현재 React와 코드를 공유 할 때 React와 다르게 라이선스를받을 예정인 이유는 무엇입니까? 그것이 MIT 라이센스를 무효화하지 않습니까 (말장난을 용서하십시오)?

또한 GraphQL을 언급하지 않았다는 점에 유의합니다. 내가 놓친 다른 것이 있습니까?

React 라이선스 문제의 요점은 법적 확실성이 부족하다는 것입니다.

뿡 빵뀨

내 요점에 대한 귀하의 수정 사항을 기록합니다.

React는 BSD + Patents 또는 귀하가 멸시하는 기타 특허 허가에 따라 라이센스가 부여 된 코드를 포함하거나 의존하지 않습니다. React에서 부품을 제거하지 않습니다. 내가 아는 React의 유일한 non-FB 소유 종속성은 MIT에있는 객체 할당입니다.

하지만 React에서 부품을 제거하고 "다음 며칠 안에"코드를 확인할 것이라고 말씀하셨습니다.

React 및 FB 소유 종속성은 우리 팀이 변경 사항을 커밋 할 시간이 생기는 즉시 MIT에서 사용할 수 있습니다.

그리고 당신은 IANAL을 잊었습니다 ... :-)

아, 실제로 긴 형식이라고 말씀하셨습니다.

나는 당신이 내 말을 법적 보증으로 받아들이라고 제안하는 것이 아닙니다. 우리는 여기에 내 의견이 React의 라이센스를 변경하지 않는다는 것을 알고 있습니다.

다시 한번:

React 라이선스 문제의 요점은 법적 확실성이 부족하다는 것입니다.

나는 아직 법적 확실성이 없다는 점에 동의합니다. 그러나 저는 개인적으로이 스레드가 그 과정을 실행했다고 믿습니다. 기여자로만 표시하고 실제 라이선스가 게시 될 때까지 기다리면 팀이 평가할 수 있습니다.

지금 구독을 취소합니다.

페이스 북은 자신의 desision했다 반작용 덤프하지 마십시오 https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni 뭔가에 대한 열정은 이해하지만, 당신처럼 댓글을

@sophiebits 이 스레드에와 주셔서 감사합니다. 감사합니다.

이것은 새로운 스레드에 대한 주제 일 수 있지만, 불행히도 MIT 라이센스 (표준 라이센스조차도)는 특허와 관련된 "불확실성"문제를 해결하지 못하여 WordPress 결정을 앞당겼습니다.

MIT 라이선스가 특허 IP를 사용할 수있는 권리를 부여합니까? 이에 대해 변호사가 말하는 내용을 읽어보십시오 : The MIT License, Line by Line

— Frans Bouma (@FransBouma) 2017 년 9 월 23 일

MIT는 분명히 특허 라이센스를 부여하지 않습니다. Facebook은 React에 특허를 보유하고 있으며 현재 라이선스에서 귀하에게 부여한다고 말합니다. 현재 라이선스를 사용하면 적어도 어떤 라이선스가 부여되었는지, 어떤 조건이이를 취소하는지 알고 있습니다. MIT를 사용하면 라이센스 부여도받지 못합니다.

특허 부여는 관련 특허가 있음을 의미합니다 (또는 무엇을 부여합니까?). 아무도 특허가 무엇인지조차 모른다는 것을 제외하고는. 페이스 북은 그것을 승인했을 때도 말하지 않았고, 보조금 제거를 발표했을 때도 말하지 않았습니다.

내가 개인적으로 또는 WordPress 팀이 이것이 의미한다고 생각하는 것과 상관없이 여전히 존재하는 것처럼 보이는 것은 React에있는 (아직 상장되지 않은) Facebook 특허의 법적 상황에 대한 혼란입니다. 또는-그렇지 않을 수도 있습니다]] 위반에 대해 걱정할 필요가 없습니다. 오늘 Facebook에 소송을 제기 할 때 또는 새 라이선스 후에 React를 사용하면됩니다.

다시 말하지만, 문제는 불확실성이며 제가 제안하는 것은 해결되지 않았습니다.

이 스레드에 대한 의견을 제시 한 대다수는 Vue 기반 솔루션을 원합니다.

Vue에 라이선스 혼란이 없다는 사실에 국한되지 않는 몇 가지 이유가 있습니다 (페이스 북의 2 단계 라이선스 정책에 여전히 남아 있음).

1. Vue는 처음부터 점진적으로 추가 될 수 있도록 설계되었으며, 기능의 섬으로 코드베이스를 점진적으로 향상시킬 수 있습니다.

2. 또한 선택적으로 공식적으로 지원되는 상태 관리 및 라우팅 솔루션을 제공합니다.

3. HTML을위한 다중 프로세서를 지원하여 개발자에게 HTML, JSX, Pug 등의 템플릿 언어 또는 렌더링 기능을 선택할 수 있습니다.

4. 단일 파일 구성 요소 및 범위가 지정된 CSS (Stylus, SASS, SCSS, PostCSS, CSS 구성 요소)-가능한 가장 쉬운 방법입니다. 말 그대로 범위 속성을 구성 요소 스타일 선언에 추가하면 완료됩니다.

5. 계산 된 속성 (메모 화 포함) 내장 (예 : MobX와 같은 종속성 없음) 지원.

   6+. React에 대한 우수한 성능, 훨씬 낮은 학습 곡선, PHP 커뮤니티에서 더 높은 채택률, 예를 들어 Laravel Mix 를 확인하십시오. Laravel 자체를 사용하지 않고도 사용할 수 있습니다. 또는 https://unpkg.com/vue 를 통해 Vue를 포함하고 코딩을 시작

Vue는 단순히 WordPress에 더 적합합니다.

반응 :

76,364 Github 별
571 미결 문제 (!)
4325 닫힌 문제
178 오픈 풀 리퀘스트 (!)
5,644 개의 닫힌 풀 요청

Vue :

68, 246 개의 Github 별 (궤적은 크리스마스까지 React를 추월하는 것입니다)
62 미해결 문제 (버그 수정에 훨씬 더 민감하고 요청 된 기능 추가)
5,629 종결 된 문제
17 개의 오픈 풀 리퀘스트
863 Closed Pull 요청

@Meligy

MIT는 분명히 특허 라이센스를 부여하지 않습니다. Facebook은 React에 특허를 보유하고 있으며 현재 라이선스에서 귀하에게 부여한다고 말합니다. 현재 라이선스를 사용하면 적어도 어떤 라이선스가 부여되었는지, 어떤 조건이이를 취소하는지 알고 있습니다. MIT를 사용하면 라이센스 부여도받지 못합니다.

특허 부여는 관련 특허가 있음을 의미합니다 (또는 무엇을 부여합니까?). 페이스 북은 그것을 승인했을 때도 말하지 않았고, 보조금 제거를 발표했을 때도 말하지 않았습니다.

여기에 대기업의 오픈 소스가 아닌 문제가 있습니다. 궁극적으로 그들의 변호사는 현재 또는 미래에 개발 팀의 좋은 의도가 무엇이든 무시할 것입니다.

Facebook은 + Patents 라이센스를 '무언가 또는 무엇이든'에 대한 공격적인 방어로 구성했으며 이제 우리는 매우 동일한 '무언가 또는 무엇이든'이 실제로 React에 대해 존재하지 않지만 React Native 및 GraphQL 등에 대해서는 _ 여전히 존재한다고 믿도록 요청 받았습니다.

Automattic은 Facebook이 React에 대한 라이센스와 의견을 다시 변경할 때 스스로 부담을지고 React를 수행하고 포크하고 자체적으로 개발할 것이라고 약속 할 수 있습니까?

저에게는 페이스 북이 워드 프레스의 함정을 설정하고있는 것 같습니다. 전 세계 모든 웹 사이트의 25 %가 큰 문제입니다.

이 스레드를 _ 기고자 전용 _ 최대한 빨리 표시하십시오. 완전히 구독을 취소 할 필요없이 FUD 및 추측 대신 기고자의 결과를 읽는 것이 좋습니다. 감사합니다.

@WebReflection Wordpress의 이해 관계자는 핵심 개발자 일뿐만 아니라 확장 된 커뮤니티이기도합니다.

@PericlesSouza 가 Github 별을 인용하는 것은 아무 의미가 없습니다. 그리고이 문제가 어리석은 주장을 던지는 사람들에 의해 서두르고 있다는 것이 사실을 무시해야한다는 것을 의미하지는 않습니다 : https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue는 레이더에 대한 단서에 지나지 않습니다. 엄청나게 많은 사람들은 React를 사용하며 당신의 글 머리 기호에 동의하지 않을 것입니다.

@PericlesSouza 가 Github 별을 인용하는 것은 아무 의미가 없습니다. 그리고이 문제가 어리석은 주장을 던지는 사람들에 의해 서두르고 있다는 것이 사실을 무시해야한다는 것을 의미하지는 않습니다 : https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue는 레이더에 대한 단서에 지나지 않습니다. 엄청나게 많은 사람들은 React를 사용하며 당신의 글 머리 기호에 동의하지 않을 것입니다.

NPM 통계? 그들이 인정하는 것과 동일한 통계가 최신 버전을 사용하고 있는지 여부를 확인하는 모든 단일 요청을 다운로드 요청으로 계산한다는 것을 의미합니까? (그들은 사람들이 "한 달에 수십억 개의 패키지"주장을 비웃었을 때 블로그에서이를 인정했습니다.)

그 길을 가고 싶다면 모두가 jQuery를 사용하고 있습니다.

종속성 왜곡 필드가없는 패키지에 대한 수치를 시도해보십시오.

https://npmcharts.com/compare/vue-cli , create-react-app

제시하기로 선택한 사진과는 완전히 다른 사진입니다.

또는 웹 사이트 사용 방법 :

https://w3techs.com/technologies/comparison/js-react , js-vuejs

BuiltWith 통계로 뒷받침됩니다.

아, 팀이 커뮤니티에 직접 질문했을 때이 사진을 여기에 남겨 두겠습니다. 당신은 그들을 경멸로 대하기보다는 그들의 말을 들어야합니다.

@PericlesSouza Next.js 및 GatsbyJS 와 같은 React 용으로 매우 인기있는 빌드 도구가 있기 때문에 vue-cli와 create-react-app을 비교하는 것은 의미가 없습니다.
많은 React 개발자는 CLI를 사용하지 않고 대신 Gutenberg 및 Calypso와 마찬가지로 자체 사용자 지정 Webpack 빌드 스크립트를 사용합니다.

현실은 React 생태계가 Vue보다 훨씬 크다는 것입니다. 예를 들어 가지고 Vue.js에 대한 자료 UI 동안 4339 별을 가지고 반작용에 대한 자료 UI가 29078 별이있다.

jQuery의 오버 헤드없이 Select2와 유사한 기능을 제공하는 기본 선택 상자 구성 요소 : Vue select 에는 1,348 개의 별이 있고 React select 에는 8,493 개의 별이 있습니다.

@PericlesSouza , @drcmda ,이 모든 데이터는 많은 방식으로 경쟁 할 수 있습니다. 심지어 cli의 npm 통계에서도 AngularCLI와 EmberCLI를 추가하면 전혀 다른 데이터를 볼 수 있습니다.

출처 : https://npmcharts.com/compare/vue-cli , create-react-app, @ angular / cli , ember-cli

출처 : https://w3techs.com/technologies/comparison/js-angularjs , js-react, js-vuejs

출처 : https://insights.stackoverflow.com/survey/2017#technology -frameworks-libraries-and-other-technologies

그러나이 대화는 어떤 프레임 워크가 가장 많이 사용되는지에 대한 것이 아니라 전체적으로 Wordpress 환경에 더 좋을 것입니다.

@PericlesSouza @willgm 규칙은 둘 다에 적용됩니다. 둘 다 똑같은 방식으로 계산되며 공정하지 않다고 주장하는 것은 매우 솔직합니다. 선택적인 CLI 나 "좋아요"와 "별"을 세는 추천 웹 사이트에 집착하는 것은 헛된 일입니다. stackoverflow조차도 매우 주관적이며 오늘까지 "builtwith ..."사이트에 대해 들어 보지 못했습니다. CLI 통계는 CLI를 사용하는 사람의 수를 반영합니다 (대부분은 그렇지 않습니다).

동일한 정확한 상황에서 실제 프로덕션 환경을 반영하는 가장 분명하고 중요한 소스의 데이터는 내가 좋아하지 않는 통계이며, 그 상태를 바꾸지 않습니다.

그러나이 대화는 어떤 프레임 워크가 가장 많이 사용되는지에 대한 것이 아니라 전체적으로 Wordpress 환경에 더 좋을 것입니다.

그리고 어느 것이 더 적합한 지 알고 있습니다. 하루에 400,000 명의 사람들이 npm에서 React를 꺼낸다 고 생각합니다. Vue는 자체적으로 경쟁 할 수 있으며 실제로 이슈 트래커로 돌진하는 군중이 필요하지 않습니다.

@PericlesSouza @willgm 규칙은 둘 다에 적용됩니다. 둘 다 똑같은 방식으로 계산되며 공정하지 않다고 주장하는 것은 매우 솔직합니다. 선택적인 CLI 나 "좋아요"와 "별"을 세는 추천 웹 사이트에 집착하는 것은 헛된 일입니다.

아니. React에는 수치를 왜곡하는 16,800 개의 종속 패키지가 있습니다. NPM은 URL을 호출 할 때 종속성 검사, 봇, 미러 등의 결과로 다운로드로 간주되는 모든 것이 200 개의 결과 코드임을 인정합니다. 덧붙여서 그들은 또한 Vue가 인기가 높은 중국에서 대부분의 다운로드가 미러에서 발생하며 계산되지 않는다고 말합니다.

'집착', '제안 웹 사이트', '무의미한'언어 사용으로 판단하면이 주제에 대한 실제 주장이없는 반면, 팀의 요청에 따라 Vue 사용의 장점을 게시했습니다. 위 ).

Counting Stars-다른 사람들은 React의 성공을 지적 할 때 그렇게하지만 Vue의 인기를 나타 내기 위해 사용되면 그 가치를 비난합니까? 또한 훨씬 더 많은 미해결 문제 ( 571 )에 대해 언급하지 않았고, 여전히 React에 대해 보류중인 미해결 풀 리퀘스트 ( 178 )의 상당한 수에 대해 언급하지 않았습니다. 이는 버그 수정 및 Vue 커뮤니티의 높은 응답 성과 비교할 때 기능 추가는 React 사용을 제안 할 때 우려할만한 유효한 원인입니다.

다음으로 이동합니다.

좋아요 세기-글쎄요, 이것이 팀이 시작하고 커뮤니티에 요청한이 스레드의 요점이었습니다 . 결과가 마음에 들지 않는 것 같습니다. 여기에 다시, 매우 결정적입니다.

아니. React에는 수치를 왜곡하는 16,800 개의 종속 패키지가 있습니다.

@PericlesSouza 어떻게 그 결론에 도달합니까. 의미하는 바를 의미합니다. 16.800 개의 패키지가 package.json에서 React를 종속성으로 선언했습니다. 중국이 아닌 봇이 아닌 패키지. Vue는 약 2580 개를 가지고 있으며 이는 훨씬 더 작은 에코 시스템과 사용자 기반을 가지고 있음을 의미합니다. 왜 우리는 이것을 주장 하는가? 사용 통계에 직접 반영됩니다. 업데이트, 실제 사람 또는 봇, 두 패키지 모두에 적용됩니다. 봇이 어떤 이유로 의도적으로 Vue를 건너 뛰고 있다고 가정하지 않는 한.

각 패키지를 동일하게 처리하는 추적기에서 하나의 패키지를 선별하는 것은 거의 의미가 없습니다. 반면에 좋아요를 세는 것은 XY가 투표 할 곳을 알고있는 커뮤니티에 지나지 않습니다.

뿡뿡

그가 의미하는 바는 React에 대한 종속성이있는 패키지를 설치할 때마다 버전과 종속성을 확인하기 위해 NPM에 도달 할 때마다 NPM은 그렇지 않더라도 패키지의 download 로 계산한다는 것입니다. 다운로드.

그것이 그가 의미하는 바라면 그는 매우 정확합니다. NPM에 의해 명시 적으로 명시되어 있습니다. 그들은 자신의 '방법론'을 '의도적으로 순진하다'고 설명합니다 (또한 봇과 미러는 요청이 무엇인지를 결정하는 메커니즘이 없기 때문에 수치를 왜곡 할 수 있다고 언급합니다. 그리고 React에는 더 많은 종속 패키지가 있으므로이 효과가 더 두드러집니다.

많은 종속 패키지에 관해서는-예 React는 오래된 프레임 워크이므로 더 많은 것을 가지고 있으며 일종의 필요합니다. 저는 React와 Vue로 개발하고 Vue를 사용하면 코어가 꽤 완벽하고 공식 Router와 Vuex도 낮은 종속성의 철학을 따르기 때문에 추가 패키지가 덜 필요한 경향이 있습니다. Vue 자체는 어떤 패키지에도 의존하지 않으며 React는 몇 가지 패키지에 의존합니다. 그들은 이와 관련하여 다른 접근 방식을 가지고 있습니다.

또 다른 예는 사람들이 Bootstrap과 React 사이에 통합 패키지를 사용하거나 스타일 구성 요소, 클래스 이름 등과 같은 라이브러리를 사용하는 경향이 있다는 것입니다. Vue에서는 이러한 프로젝트도 존재하지만 일반적으로 필요하지 않습니다. 추가 라이브러리 나 구성없이 구성 요소 범위의 CSS를 즉시 사용할 수 있고 전체 통합 라이브러리를 가져온 다음 트리를 시도하는 대신 필요에 따라 CSS 프레임 워크와의 간단한 통합을 작성할 수 있으므로 Vue로 작업하기가 훨씬 더 쉽습니다. -필요하지 않은 75 %를 털어냅니다.

@PericlesSouza는 'Pros of Vue'게시물에서 관련성이 높은 몇 가지 항목을 놓쳤습니다.

Reacts가 자식을 사용하는 것보다 더 유연한 표준 Forms, Inputs, Layouts 등과 같은 재사용 가능한 템플릿 구성 요소를 허용하는 Named Slots.

비활성 구성 요소를 파괴하지 않고 Keep-Alive 로컬 상태를 유지하는 선택적 기능이있는 조건부 구성 요소입니다.

HTML 요소는 문자열 템플릿에 대한 Vue 구성 요소 구문으로, 잘못된 HTML을 초래하는 렌더링 된 HTML 요소의 호이 스팅을 방지합니다.

props를 사용하는 단방향 데이터 흐름이지만 형제 또는 부모를 알리거나 업데이트하기 위해 훨씬 단순화 된 '방출'및 '이벤트 버스'흐름이 추가되었습니다. 이것은 다음 사이의 상호 통신에 유용 할 수 있습니다.

특정 지역을 제어하는 ​​한 페이지의 여러 Vue 인스턴스. 이 기술은 동적 대시 보드 또는 플러그 형 위젯 및 메모리 관리에 유용합니다.

전역 및 로컬 구성 요소 및 사용자 지정 지시문 등록.

계산 된 속성 외에 체인 가능한 필터.

위의 모든 내용은 핵심 Vue 라이브러리의 일부입니다.

React는 훌륭한 프레임 워크이고 사용하는 것을 좋아하지만 개인적으로 Vue가 제안 된 사용 사례에 더 적합하다고 생각합니다.

뿡뿡

예, 서두르고 Vue의 장점에 대한 전체 목록을 만들 시간이 없었습니다.

내가 fbjs에 의존한다는 것을 알기 때문에 React가 의존성을 가지고 있다고 언급 한 것은 흥미 모든 것이 걱정 스럽습니다.

https://www.npmjs.com/package/fbjs

https://www.npmjs.com/browse/depended/fbjs

목적

Facebook이 자체 JavaScript를 더 쉽게 공유하고 사용할 수 있도록합니다.

참고 : _ 여기에서 코드를 사용하고 있고 Facebook 프로젝트도 아닌 경우 나쁜 시간에 대비하십시오 _. _이 라이브러리는 우리의 사용 사례를 염두에두고 게시되고 있으며 반드시 더 많은 사람들이 사용하기위한 것은 아닙니다. 우리의 요구에 맞지 않는 한 기능 요청을 받아들이지 않을 것입니다.

571 미결 문제 (!)

지금은 338입니다. (나는 그들을 청소하는 데 며칠을 보냈다.)

지난 몇 달 동안 React 팀은 대체로 이전 버전과 호환되는 React 16 릴리스를 준비 하느라 바빴습니다. 역대 가장 큰 릴리스 였기 때문에 이슈 트래커에 대한 응답이 아니었기 때문에 죄송합니다. 결과적으로 React 16은 이러한 문제를 해결했습니다. :-)

남은 338 개 문제의 대부분은 기능 요청 및 토론이라는 점을 지적하고 싶습니다. 버그 라벨을 검색하면 약 60 개의 문제가 발생합니다. 그리고 현재 React 생태계가 Vue보다 크다는 점을 감안할 때 사람들이 더 많은 엣지 케이스와 불일치에 부딪 히고 더 많은 토론을 시작하는 것은 놀라운 일이 아닙니다. 그들은 또한 React가 더 많은 브라우저 불일치를 폴리 필하기를 기대하기 때문에 많은 버그가 그 범위를 놓치는 것과 관련이 있습니다. 또한 문서를 동일한 저장소에 보관하므로 이러한 문제는 문서에 관한 것입니다.

이것이 왜 우리가 Vue보다 더 많은 이슈 수를 갖는 경향이 있는지에 대한 통찰력을 제공하기를 바랍니다.

내가 fbjs에 의존한다는 것을 알기 때문에 React가 의존성을 가지고 있다고 언급 한 것은 흥미 롭습니다. 사람들이 React를 고려하고 있다면 알람 벨을 울려 야하는 부분에 약간의 강조점을 추가했습니다. Facebook의 2 계층 라이선스 전략은 서로 다른 라이선스 프로젝트간에 코드를 공유합니다. 특히 그것에 의존하지만 라이센스가 다른 프로젝트 목록을 볼 때 그것에 대한 모든 것이 걱정 스럽습니다.

불행히도 이것은 근거없는 FUD입니다. 나는 그것을 퍼뜨리는 동기가 무엇인지 잘 모르겠지만 React는 MIT로 재 라이센스되었으며 React가 의존하는 모든 코드 (예 : fbjs)를 포함합니다. 여기에는 교활한 계획이 없습니다.

댓글 5 일 전에 https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 에서 fbjs 라이선스가 MIT로 변경되었음을 직접 확인할 수 있습니다. 며칠 전에 나온 React 16 릴리스에는 MIT가 아닌 단일 바이트가 포함되어 있지 않습니다.

다른 프로젝트가 fbjs 에 의존하지만 다른 라이선스가 있다는 사실은 완전히 무관합니다. 마치 애플리케이션 코드가 MIT가 아니라 Vue에 의존하는 것과는 무관 한 것처럼 말입니다.

추신 : Vue는 훌륭하다고 생각하며 누구에게도 React를 강요하고 싶지 않습니다. 그러나 저는 우리가이 논의를 사실에 근거하고 있는지 확인하고 싶습니다. :-) 우리는 항상 비판에 개방적이며 Vue와 React 모두 서로에게서 배울 점이 있다고 확신합니다.

이 모든 것이 흥미로운 이야기입니다.

왜 프레임 워크 / 라이브러리가 필요합니까? 앞서 언급했듯이 웹 컴포넌트 표준은 ReactJS, Vue 및 기타가 제공하기 위해 구축 된 것을 제공하는 것 같습니다 (표준이 존재하지 않았기 때문에).

웹 구성 요소에서 Redux와 같은 상태 라이브러리를 잘 사용할 수 있습니다. 라우팅 라이브러리와 유사합니다. SSR은 웹 구성 요소로 개발되지는 않았지만 거기에서 일하는 사람들도 있습니다. 부분적으로 React의 가장 큰 가치는 주변의 다양한 지원 라이브러리입니다. 플랫폼을 사용한다고해서 반드시 손실되는 것은 아닙니다.

XXX 프레임 워크는 플랫폼 웹 구성 요소에 대해 무엇을 제공합니까?

참으로 흥미로운 이야기 ...

지금까지 React의 네 번째 라이선스입니다.

1. 원래 Apache 2.0. 괜찮 았어 야 했죠? 문제는 무엇 이었습니까?
2. 그런 다음 BSD + 특허. 특허가 존재하는지 여부를 공개하지 않고.
3. 그런 다음 Google을 기쁘게하기 위해 약간의 수정이 필요합니다. 이유에 대한 세부 정보가 없습니다.
4. 이제 MIT, React의 지정되지 않은 리팩토링을 사용하지만 React Native, GraphQL 등과 같은 직접 관련된 프로젝트에는 적용 되지 않습니다 . 공개 설명이있는 공유 종속성은 "Facebook이 우리 자신의 JavaScript를 더 쉽게 공유하고 사용할 수 있도록합니다. 주로 이렇게하면 코드가 어디에 있는지 너무 많이 걱정하지 않고 코드를 전달할 수 있습니다. "

분명히 그 모든 것은 전혀 걱정할 것이 없습니다.

[Tammie Lister에 의해 삭제 된 수정 : 이와 같은 개인 문구는 허용되지 않습니다.]

@PericlesSouza 이전에는 라이선스가 혼란 스러웠 기 때문에 우리를 신뢰할 수 없다고 주장 할 수 있습니다. 그것이 당신의 주장이라면 유효합니다. 그러나 라이센스는 지금 혼란스러워서는 안됩니다.

React는 MIT입니다.
의존성 fbjs는 MIT입니다.
React와 React Native가 공유하는 코드 (Repo 리포지토리에 계속 포함되어 있음)는 MIT입니다.
모든 의존성을 포함한 React는 MIT입니다.
React를 사용하려면 Create React App이 필요하지 않지만 MIT도 마찬가지입니다.
Relay와 graphql-js는 React를 사용하는 데 필요하지 않지만 MIT도 마찬가지입니다.

새 라이선스로 React 16.0을 출시했습니다. 이것을 확인하는 것은 쉽습니다.
또한 MIT 라이선스가 15.6.2 인 React 15.x의 새 버전도 출시했습니다.
우리는 MIT 라이선스에 따라 React의 모든 향후 버전을 출시 할 계획입니다.

게다가이 스레드의 다른 Facebook 직원은 React (MIT for 16? what for <16? 17+? 더 잘 살펴 보는 것이 package.json)와 React Native 공유 코드를 인정했습니다. 리팩토링이 필요했습니다 (그런 다음 댓글을 편집합니다. 내가 인용 한 후 그 진술을 제거하기 위해).

나는 그 엔지니어입니다. (그녀.)

당신은 논평 https://github.com/WordPress/gutenberg/issues/2733#issuecomment 나는 대답, -331737418 https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521합니다.

내 이메일 클라이언트에 기록 된 두 댓글의 원본 콘텐츠는 다음과 같습니다.

현재 콘텐츠는 다음과 같습니다.

댓글을 달고 나서 추가 질문을 포함하여 댓글을 훨씬 더 길게 수정하셨습니다.

React가 MIT에 게시되도록하기 위해 어떤 부분이 제거되고 있습니까?

원래 의견에 없었습니다. 따라서 귀하의 수정에 대한 응답으로 내 댓글을 수정하여 다음을 추가했습니다.

React에서 부품을 제거하지 않습니다. 내가 아는 React의 유일한 non-FB 소유 종속성은 MIT에있는 객체 할당입니다.

그런 다음 다음 의견에서 나를 부르는 것이 적절하다고 생각했습니다. 편집에 추가 한 질문을 해결하기 위해 어떻게 감히 내 댓글을 편집 할 수 있습니까? React 및 React Native 공유 코드에 대한 주장을 제거하거나 편집하지 않았습니다.

-

저를 gaslighting 중지하십시오. 피곤하다.

@youknowriad 이 스레드를 잠글 정도로 친절 하시겠어요? 여기서 더 생산적인 토론이 일어나고 있다고 상상할 수 없습니다.

여기에있는 다른 사람이 여전히 라이센스에 대해 합법적으로 우려하는 경우 언제든지 DM을 보내 주시면 확인을 위해 최선을 다하겠습니다.

그런 다음 다음 의견에서 나를 부르는 것이 적절하다고 생각했습니다. 편집에 추가 한 질문을 해결하기 위해 어떻게 감히 내 댓글을 편집 할 수 있습니까? React 및 React Native 공유 코드에 대한 주장을 제거하거나 편집하지 않았습니다.

분명히 내가 귀하의 편집에 응답했습니다. 그게 문제입니까?

가스 라이팅이 필요하지 않습니다. Facebook, React 개발 팀 및 라이선스의 개방성과 일관성, 그리고 Reacts의 4 가지 라이선스 모델이 상대적으로 짧은 수명 시간을 나타내 듯이 귀하의 (현재) 게시물은 불행히도 부족합니다.

간단히 라이선스를 제쳐두세요 : 다시 말하지만, React는 웹 구성 요소를 넘어서 얻은 것이 무엇입니까? 둘 다 (예 : Redux)에서 지원 라이브러리를 계속 사용할 것이라고 가정합니다.

Web Components를 통해 WordPress는 다양한 프런트 엔드 프레임 워크 / 라이브러리에서 사용할 수있는 것보다 많은 요소를 만들 수 있습니다. 이렇게하면 React, Vue, Angular 또는 WordPress 구성 요소를 "드롭 인"하는 데 사용하는 프런트 엔드를 사용하는 최종 사용자가 사용할 수 있습니다.

@sophiebits 지금 응답 할 게시물의 버전이 무엇인지 확실하지 않으므로 기다렸다가 마침내 어떻게 될지 확인하겠습니다. React와 매우 비슷한 상황입니다.

@ Brian-McBride

당신은 좋은 지적을했고, 나는 그것이 "왜 바닐라 자바 ​​스크립트를 사용하지 않는가?", 표준 기반, 완벽하게 호환되는 스레드에서 더 일찍 제기되었다고 믿습니다.

흠.

Remove references to PATENTS that crept in #11091
Merged  sophiebits  merged 1 commit into facebook:master from sophiebits:nopatentsagain a day ago

https://github.com/facebook/react/pull/11091

내가 사람들에게 말했듯이 React를 사용하는 경우 버전 제어에 대해 매우 조심하십시오.

예, 라이센스 변경 이전에 열린 풀 요청에서 실수로 헤더가 잘못된 3 개의 파일을 커밋했습니다. 릴리스 된 버전에는 없었습니다 (하나는 단위 테스트 였고 두 개는 웹 사이트의 일부였습니다).

실수가 발생합니다. 우리는 그것을 발견했을 때 수정했고, 더 이상 우발적 인 참조가 추가되지 않았는지 확인하기 위해 CI에 스크립트를 추가했습니다. 그 커밋에서 볼 수 있습니다.

자유 소프트웨어 프로젝트에서 고려해야 할 또 하나의 추가 사항은 Facebook이 React를 사용함으로써 얻는 이점입니다.

그러나 Facebook의 가치는 일반적으로 자유 소프트웨어 운동의 가치와 일치하지 않습니다. 사용자의 비 윤리적 조작 부터 Net Neutrality에 대한 공격 ( "무료 기본"), 데이터 삭제 불능, 데이터 수집 차단 불능, 검열, 벽으로 둘러싸인 정원에 이르기까지 모든 것 , 에코 챔버 등.

[페이스 북]은 제 동생이 저를 때리게해서“왜 스스로를 때리는 거죠?”라고 묻는 것과 같습니다. 그런 다음 그는 엄마에게 자신의 잘못이 아니라고 말했습니다.

수년에 걸쳐 Facebook을 보면서 저는 더 이상 그 회사를 어떤 식 으로든 지원하고 싶지 않다는 결론에 점점 더 가까워 졌으므로 개인적으로 대안이있을 때마다 FB 소프트웨어를 사용하지 않습니다.

저는 React에 관한 책을 읽었고 프로그래밍 관점에서보기에도 멋지지만 대안도 훌륭하고 Facebook을 지원하는 짐과 함께 오지 않습니다.

나는 자유 소프트웨어 프로젝트가 가능할 때마다 항상 독립적 인 자유 소프트웨어 라이브러리를 선호해야한다고 생각합니다. Vue, 웹 구성 요소, Ember 및 Mithril을 포함하여 WordPress에 대한 훌륭한 대안이 많이 있습니다. Vue는 PHP 커뮤니티에서 막대한 지원을 받고 있으며 윤리적 문제가 없기 때문에 잘 맞을 것 같습니다. 대시 보드 전용이라면 JavaScript보다 훨씬 더 흥미로운 것을 살펴볼 가치가 있습니다 : Elm .

현재 유행하거나 멋진 것에 관한 것이 아니라 다음 세대에게 직간접 적으로 가장 기술적 인 자유를 제공하는 것에 관한 것이어야합니다.

고려해야 할 또 다른 생각 ...

정중 한 대화를 나누면서 의견을 내주신 모든 분들께 감사드립니다. 또한 @sophiebits , @gaearon , @ blake-newman 및 질문에 친절하게 답변 해주신 프로젝트를 대표하는 모든 분들께 특별한 감사의 말씀을 전하고 싶습니다 . 귀하의 지식은 대단히 감사하며 언제나 환영합니다.

대화는 이후 # core-js Slack 채널의 자바 스크립트 회의로 이동했습니다. 여기에 좋은 요약이 있습니다 . 이러한 토론에 참여하는 데 관심이 있으시면 그곳에 참여해 주시기 바랍니다. 또는 기여, 테스트 및 피드백을 사용할 수있는 상호 운용성에 대한 두 가지 접근 방식 : # 2463 및 # 2791이 있습니다.

그리고이 스레드는 그 과정을 실행했습니다. 문제를 잠그고 있지만 위에서 언급 한 장소에서 대화를 계속하는 것이 좋습니다.

이 스레드는 좋은 토론을 가져 왔지만 일부는 허용되지 않는 동작을 보였고 편집되었습니다. https://wordpress.org/about/etiquette/ 는 모든 WordPress 프로젝트에 적용되며 위반이나이를 저지른 위반을 용인하지 않는다는 점을 기억하는 것이 중요합니다. 배려하고 정중하게 대화에 기여 해주신 모든 분들께 감사드립니다.