다른 프레임워크와 비교


이 페이지는 의심할 여지없이 작성하기 가장 어렵지만 매우 중요하다고 생각합니다. 어쩌면 몇 가지 문제가 발생하여 다른 프레임워크를 사용하여 해결했을 수도 있습니다. 여기서 귀하의 목적은 Vue에 더 나은 솔루션이 있는지 확인하는 것입니다. 이것이 우리가 여기서 대답하고 싶은 것입니다.

객관적으로 말하면 핵심 팀 구성원으로서 우리는 분명히 Vue를 선호하며 일부 문제를 해결하려면 Vue가 더 나을 것이라고 생각합니다. 이런 믿음이 없었다면 우리는 하루 종일 바쁘게 일하지 않았을 것입니다. 하지만 여기서는 가능한 한 공정하고 정확하게 모든 것을 설명하고 싶습니다. React의 방대한 생태계나 IE6을 포괄하는 Knockout의 브라우저 지원과 같은 다른 프레임워크에도 상당한 이점이 있습니다. 우리는 그것들을 모두 나열하려고 노력할 것입니다.

JavaScript의 세계는 매우 빠르게 발전하고 있으므로 문서를 최신 상태로 유지하기 위해 귀하의 도움을 받기를 바랍니다. 부정확하거나 정확하지 않은 내용을 발견한 경우 문제를 제출하고 알려주세요.


목차

React

React와 Vue는 다음과 같은 많은 유사점을 가지고 있습니다.

  • Virtual DOM

  • 을 사용하여 반응형(반응형) 및 구성 요소화된(컴포저블) 뷰 구성 요소를 제공합니다.

  • 핵심 라이브러리에 집중하고 라우팅, 전역 상태 관리 등의 다른 기능은 관련 라이브러리에 맡기세요.

유사점이 많기 때문에 이 지역을 비교하는 데 더 많은 시간을 할애하겠습니다. 여기서 우리는 기술적 내용의 정확성을 보장할 뿐만 아니라 균형 잡힌 고려 사항도 고려합니다. 우리는 더 풍부한 생태계처럼 React를 Vue보다 더 좋게 만드는 것들을 인정해야 합니다.

최근 React 16+ 릴리스로 인해 다음 장 중 일부가 약간 오래되었을 수 있습니다. 가까운 시일 내에 React 커뮤니티와 함께 ​​콘텐츠의 이 부분을 다시 작성할 계획입니다.


런타임 성능

React와 Vue 모두 매우 빠르기 때문에 둘 중 하나를 선택할 때 속도가 결정적인 요소는 아닙니다. 특정 데이터 성능의 경우 매우 간단한 구성 요소 트리를 렌더링/업데이트하는 실제 성능에 초점을 맞춘 이 타사 벤치마크로 이동할 수 있습니다.

Optimization

React 애플리케이션에서는 구성 요소의 상태가 변경되면 해당 구성 요소를 루트로 사용하여 전체 구성 요소 하위 트리를 다시 렌더링합니다.

하위 구성 요소를 불필요하게 다시 렌더링하지 않으려면 가능하면 PureComponent를 사용하거나 shouldComponentUpdate 메서드를 수동으로 구현해야 합니다. 동시에 구성 요소를 더 쉽게 최적화할 수 있도록 변경 불가능한 데이터 구조를 사용해야 할 수도 있습니다. PureComponent，或是手动实现 shouldComponentUpdate 方法。同时你可能会需要使用不可变的数据结构来使得你的组件更容易被优化。

然而，使用 PureComponent 和 shouldComponentUpdate 时，需要保证该组件的整个子树的渲染输出都是由该组件的 props 所决定的。如果不符合这个情况，那么此类优化就会导致难以察觉的渲染结果不一致。这使得 React 中的组件优化伴随着相当的心智负担。

在 Vue 应用中，组件的依赖是在渲染过程中自动追踪的，所以系统能精确知晓哪个组件确实需要被重渲染。你可以理解为每一个组件都已经自动获得了 shouldComponentUpdate

그러나 PureComponent 및 shouldComponentUpdate를 사용할 때는 구성 요소의 전체 하위 트리의 렌더링 출력이 구성 요소의 props에 의해 결정되는지 확인해야 합니다. 그렇지 않은 경우 이러한 최적화로 인해 눈에 띄지 않는 렌더링 불일치가 발생할 수 있습니다. 이로 인해 React의 구성 요소 최적화에는 상당한 정신적 부담이 따릅니다.

Vue 애플리케이션에서는 구성 요소 종속성이 렌더링 프로세스 중에 자동으로 추적되므로 시스템은 실제로 다시 렌더링해야 하는 구성 요소가 무엇인지 정확하게 알 수 있습니다. 각 컴포넌트가 자동으로 shouldComponentUpdate를 획득했다는 점을 이해하실 수 있으며, 위에서 언급한 하위 트리 문제에는 제한이 없습니다.


Vue의 이 기능을 사용하면 개발자는 더 이상 이러한 최적화를 고려할 필요가 없으며 애플리케이션 자체에 더 집중할 수 있습니다.

HTML & CSS

React에서는 모든 것이 JavaScript입니다. JSX를 사용하여 HTML을 표현할 수 있을 뿐만 아니라 처리를 위해 CSS를 JavaScript에 통합하는 추세가 점점 더 늘어나고 있습니다. 이러한 유형의 접근 방식에는 장점이 있지만 모든 개발자가 만족하지 못하는 장단점도 있습니다. 🎜🎜Vue의 전체 아이디어는 고전적인 웹 기술을 수용하고 확장하는 것입니다. 아래에서 자세히 분석해 보겠습니다. 🎜

JSX 대 템플릿

React에서 모든 구성요소는 렌더링 기능을 위해 JSX에 의존합니다. JSX는 XML 구문을 사용하여 JavaScript를 작성하기 위한 구문 설탕입니다.

JSX의 렌더링 기능을 사용하면 다음과 같은 이점이 있습니다.

  • 전체 프로그래밍 언어 JavaScript 기능을 사용하여 보기 페이지를 구축할 수 있습니다. 예를 들어 임시 변수, JS와 함께 제공되는 흐름 제어를 사용하고 현재 JS 범위의 값을 직접 참조할 수 있습니다.

  • JSX에 대한 개발 도구의 지원은 현재 사용 가능한 다른 Vue 템플릿(예: Linting, 유형 검사, 편집기 자동 완성)에 비해 상대적으로 발전했습니다.

사실 Vue는 렌더링 기능도 제공하고 JSX도 지원합니다. 그러나 기본 권장 사항은 템플릿입니다. 사양을 준수하는 모든 HTML은 합법적인 Vue 템플릿이며, 이는 몇 가지 고유한 이점도 제공합니다.

  • HTML에 익숙한 많은 개발자에게 템플릿은 JSX보다 읽고 쓰는 것이 더 자연스럽습니다. 물론 여기에는 주관적인 선호의 요소가 있지만, 이 차이가 개발 효율성의 향상으로 이어진다면 객관적인 가치가 있는 것입니다.

  • HTML 기반 템플릿을 사용하면 기존 애플리케이션을 Vue로 점진적으로 마이그레이션하는 것이 더 쉬워집니다.

  • 이를 통해 디자이너와 신규 개발자도 프로젝트를 더 쉽게 이해하고 참여할 수 있습니다.

  • Pug와 같은 다른 템플릿 전처리기를 사용하여 Vue 템플릿을 작성할 수도 있습니다.

일부 개발자는 템플릿을 개발하려면 추가 DSL(Domain-Specific Language)을 배워야 한다고 생각합니다. 우리는 이러한 구별이 피상적이라고 생각합니다. 우선, JSX는 무료로 배울 수 없습니다. JS 위에 추가되는 구문 세트입니다. 동시에, JS에 익숙한 사람이 JSX를 배우기 쉬운 것처럼, HTML에 익숙한 사람이 Vue의 템플릿 구문을 배우는 것도 쉽습니다. 마지막으로, DSL의 존재로 인해 개발자는 v-on의 다양한 수정자와 같이 더 적은 코드로 더 많은 작업을 수행할 수 있습니다. 해당 기능을 JSX에서 구현하려면 훨씬 더 많은 코드가 필요합니다.

더 추상적으로 보면 구성 요소를 두 가지 범주로 나눌 수 있습니다. 하나는 표현형이고 다른 하나는 논리적입니다. 전자에는 템플릿을 사용하고 후자에는 JSX 또는 렌더링 기능을 사용하는 것이 좋습니다. 이 두 가지 유형의 구성 요소의 비율은 애플리케이션 유형에 따라 다르지만 전체적으로는 논리적 구성 요소보다 표시 구성 요소가 훨씬 더 많다는 것을 알 수 있습니다.

컴포넌트 범위의 CSS

구성 요소를 여러 파일(예: CSS 모듈)에 배포하지 않는 한, React의 CSS 범위 지정은 CSS-in-JS 솔루션(예: styled-comComponents, glamorous 및 emotion )을 통해 구현됩니다. 이는 일반적인 CSS 작성 프로세스와는 다른 새로운 구성 요소 지향 스타일 패러다임을 도입합니다. 또한 빌드 시 CSS를 별도의 스타일시트로 추출하는 것이 지원되지만 일반적으로 번들에는 이러한 스타일을 적용하려면 런타임 프로그램이 필요합니다. JavaScript를 사용하여 스타일을 유연하게 처리할 수 있지만 번들 크기와 런타임 오버헤드도 고려해야 합니다.

CSS-in-JS 팬이라면 많은 주류 CSS-in-JS 라이브러리도 Vue(예: styled-comComponents-vue 및 vue-emotion)를 지원합니다. 여기서 React와 Vue의 주요 차이점은 Vue의 기본 스타일 설정 방법이 Single File Component의 style과 유사한 태그라는 것입니다. style 的标签。

单文件组件让你可以在同一个文件里完全控制 CSS，将其作为组件代码的一部分。

<style scoped>
  @media (min-width: 250px) {
    .list-container:hover {
      background: orange;
    }
  }
</style>

这个可选 scoped 属性会自动添加一个唯一的属性 (比如 data-v-21e5b78) 为组件内 CSS 指定作用域，编译的时候 .list-container:hover 会被编译成类似 .list-container[data-v-21e5b78]:hover。

最后，Vue 的单文件组件里的样式设置是非常灵活的。通过 vue-loader，你可以使用任意预处理器、后处理器，甚至深度集成 CSS Modules——全部都在 <style>

단일 파일 구성 요소
를 사용하면 구성 요소 코드의 일부로 동일한 파일에서 CSS를 완벽하게 제어할 수 있습니다.

rrreee

이 선택적인 scoped 속성은 data-v-21e5b78와 같은 고유한 속성을 자동으로 추가하여 <를 컴파일할 때 구성 요소 내의 CSS 범위를 지정합니다. 코드 >.list-container:hover는 .list-container[data-v-21e5b78]:hover와 같은 것으로 컴파일됩니다. 마지막으로 Vue 단일 파일 구성 요소의 스타일 설정은 매우 유연합니다. vue-loader를 통해 모든 전처리기, 후처리기를 사용할 수 있으며 CSS 모듈 - 모두 <style> 태그 내에 있습니다.

Scale

🎜Scale up🎜🎜🎜 Vue와 React는 모두 대규모 애플리케이션을 처리할 수 있는 강력한 라우팅을 제공합니다. React 커뮤니티는 상태 관리(예: Flux, Redux)에서 매우 혁신적이며 이러한 상태 관리 패턴은 물론 🎜Redux 자체🎜까지 Vue 애플리케이션에 쉽게 통합할 수 있습니다. 실제로 Vue는 이 모델을 더욱 발전시켰고(🎜Vuex🎜) Vue의 상태 관리 솔루션인 Vuex를 더욱 깊이 통합하여 더 나은 개발 경험을 제공할 수 있다고 믿습니다. 🎜

둘 사이의 또 다른 중요한 차이점은 Vue의 라우팅 라이브러리와 상태 관리 라이브러리가 공식적으로 유지 관리되고 지원되며 핵심 라이브러리와 동시에 업데이트된다는 것입니다. React는 이러한 문제를 커뮤니티에 맡기기로 선택하여 보다 분산된 생태계를 만듭니다. 하지만 상대적으로 React의 생태계는 Vue보다 더 번영합니다.

마지막으로 Vue는 대화형 스캐폴딩 안내를 통해 매우 쉽게 프로젝트를 빌드할 수 있는 CLI 스캐폴딩을 제공합니다. 이를 사용하여 신속하게 구성요소 프로토타입을 제작할 수도 있습니다. React는 이와 관련하여 create-react-app도 제공하지만 여전히 몇 가지 제한 사항이 있습니다.

  • 프로젝트가 생성될 때 어떤 구성도 허용하지 않으며 Vue CLI는 업그레이드 가능한 런타임 종속성에서 실행됩니다. 런타임은 플러그인을 통해 확장되었습니다.

  • 단일 페이지 애플리케이션 구축을 위한 기본 옵션만 제공하는 반면 Vue는 다양한 목적을 위한 템플릿을 제공합니다.

  • 사용자가 구축한 사전 설정 구성으로는 프로젝트를 빌드할 수 없습니다. 이는 특히 기업 환경에서 사전 설정된 규칙에 유용합니다.

이러한 제한 사항은 의도적으로 설계된 것이지만 장점도 있습니다. 예를 들어 프로젝트 요구 사항이 매우 간단한 경우 빌드 프로세스를 사용자 지정할 필요가 없습니다. 종속성으로 업데이트할 수 있습니다. 다양한 디자인 아이디어에 대해 자세히 알아보세요.

Scale down

React는 학습 곡선이 가파르다. 많은 예제에서 이러한 구문을 사용하므로 React를 배우기 전에 JSX 및 ES2015를 알아야 합니다. 빌드 시스템을 배워야 하며 기술적으로 Babel을 사용하여 즉시 코드를 컴파일할 수 있지만 프로덕션 용도로는 권장되지 않습니다.

Vue가 React처럼 확장되는 것처럼 Vue는 jQuery처럼 축소됩니다. 실행하려면 페이지에 다음 태그만 넣으면 됩니다.

<script src="https://cdn.jsdelivr.net/npm/vue"></script>

그런 다음 Vue 코드를 작성하고 이를 프로덕션에 적용할 수 있습니다. Vue 파일의 최소 버전으로 바꾸기만 하면 됩니다. 다른 성능 문제에 대해 걱정해야 합니다.

초기 단계에서 JSX, ES2015를 배우고 시스템을 구축할 필요가 없기 때문에 개발자는 Guide를 읽으면 하루 안에 간단한 애플리케이션을 구축할 수 있습니다.


네이티브 렌더링

React Native를 사용하면 동일한 구성 요소 모델을 사용하여 기본 렌더링 기능을 갖춘 앱(iOS 및 Android)을 작성할 수 있습니다. 동시에 여러 플랫폼에서 개발할 수 있다는 것은 개발자에게 좋습니다. 따라서 Vue와 Weex는 Alibaba가 시작한 크로스 플랫폼 사용자 인터페이스 개발 프레임워크입니다. 또한 Weex에서는 Vue 구문 개발을 사용하여 브라우저 끝이며 iOS 및 Android에서 기본 애플리케이션용 구성 요소를 개발하는 데에도 사용할 수 있습니다.

현재 Weex는 여전히 활발하게 개발 중이며 그 성숙도는 React Native와 경쟁할 수 없습니다. 그러나 Weex의 개발은 세계 최대 전자상거래 기업의 요구에 의해 주도되며 Vue 팀도 Weex 팀과 적극적으로 협력하여 개발자에게 좋은 개발 경험을 보장할 것입니다.

또 다른 옵션은 Vue.js로 완전한 네이티브 앱을 구축하기 위한 NativeScript 플러그인인 NativeScript-Vue입니다.


MobX

Mobx는 React 커뮤니티에서 매우 인기가 있으며 실제로 Vue에서도 거의 동일한 반응 시스템을 사용합니다. 제한된 범위에서 React + Mobx는 Vue의 더 번거로운 버전으로 간주될 수도 있으므로 이들을 조합하여 사용하는 데 익숙하다면 Vue를 선택하는 것이 더 합리적입니다.


Preact 및 기타 React와 유사한 라이브러리

React와 유사한 라이브러리는 가능한 한 React와 API 및 생태를 공유하는 경향이 있습니다. 따라서 위의 비교는 그들에게도 동일하게 적용됩니다. 그들과 React의 차이점은 종종 더 작은 생태계에 있습니다. 이러한 라이브러리는 React 생태계의 모든 것과 100% 호환되지 않기 때문에 일부 도구 및 보조 라이브러리를 사용하지 못할 수 있습니다. 또는 작동하는 것처럼 보이더라도 사용하는 React와 유사한 라이브러리가 공식적으로 React와 엄격하게 일치하지 않는 한 언제든지 비호환성이 발생할 수 있습니다.


AngularJS (Angular 1)

Vue의 구문 중 일부는 AngularJS의 구문과 매우 유사합니다(예: v-if vs ng-if). AngularJS가 Vue의 초기 개발에 영감을 주었기 때문입니다. 하지만 AngularJS에 존재하는 많은 문제가 Vue에서는 해결되었습니다.


Complexity

Vue.js는 API와 디자인 모두에서 AngularJS보다 훨씬 간단하므로 모든 기능을 빠르게 익히고 개발에 착수할 수 있습니다.


유연성 및 모듈성

Vue.js는 더욱 유연하고 개방적인 솔루션입니다. 이를 통해 항상 AngularJS가 설정한 규칙을 따르지 않고 원하는 방식으로 애플리케이션을 구성할 수 있으므로 Vue는 다양한 프로젝트에 적합합니다. 우리는 결정을 귀하에게 맡기는 것이 중요하다는 것을 알고 있습니다.

이것이 우리가 Vue.js를 기반으로 신속한 개발을 위한 완벽한 시스템을 제공하는 이유입니다. Vue CLI는 Vue 생태계의 표준 기반 도구가 되는 것을 목표로 합니다. 이를 통해 다양한 빌드 도구가 잘 설정된 기본 구성과 원활하게 함께 작동할 수 있습니다. 이렇게 하면 구성에 너무 많은 시간을 소비하지 않고 애플리케이션 자체에 집중할 수 있습니다. 동시에 실제 필요에 따라 각 도구 구성을 조정할 수 있는 유연성도 제공합니다.


데이터 바인딩

AngularJS는 양방향 바인딩을 사용하는 반면 Vue는 서로 다른 구성 요소 간에 단방향 데이터 흐름을 강제합니다. 이렇게 하면 애플리케이션의 데이터 흐름이 더 명확하고 이해하기 쉬워집니다.


지시문 및 구성 요소

Vue에서는 지침과 구성 요소가 더욱 명확하게 구분됩니다. 지시문은 DOM 작업만 캡슐화하는 반면 구성 요소는 자체 뷰와 데이터 논리를 갖춘 독립적인 단위를 나타냅니다. AngularJS에서는 모든 것이 지시문에 의해 수행되며 구성 요소는 특별한 종류의 지시문일 뿐입니다.


런타임 성능

Vue는 더 나은 성능을 제공하며 더티 검사를 사용하지 않기 때문에 최적화하기가 매우 쉽습니다.

AngularJS에서는 관찰자가 많아지면 속도가 점점 느려집니다. 범위가 변경될 때마다 모든 관찰자를 다시 계산해야 하기 때문입니다. 또한 일부 감시자가 다른 업데이트를 트리거하는 경우 다이제스트 주기가 여러 번 실행되어야 할 수도 있습니다. AngularJS 사용자는 더티 검사 루프 문제를 해결하기 위해 난해한 기술을 사용하는 경우가 많습니다. 감시자가 많은 경우 스코프를 최적화하는 쉬운 방법이 없는 경우가 있습니다.

Vue는 종속성 추적 및 비동기 대기열 업데이트를 기반으로 하는 관찰 시스템을 사용하기 때문에 이러한 문제가 전혀 없습니다. 모든 데이터 변경 사항은 둘 사이에 명확한 종속성이 없는 한 독립적으로 트리거됩니다.

흥미롭게도 Angular와 Vue는 유사한 디자인을 사용하여 AngularJS에 존재하는 일부 문제를 해결합니다.


Angular(Original Angular 2)

새로운 Angular는 AngularJS와 완전히 다른 프레임워크이기 때문에 별도로 논의하겠습니다. 예를 들어, 뛰어난 구성 요소 시스템을 갖추고 있으며 많은 구현이 완전히 다시 작성되었으며 API가 완전히 변경되었습니다.


TypeScript

Angular는 실제로 TypeScript로 개발해야 합니다. 왜냐하면 거의 모든 문서와 학습 리소스가 TS 지향이기 때문입니다. TS에는 많은 이점이 있습니다. 정적 유형 검사는 대규모 애플리케이션에서 매우 유용하며 Java 및 C# 배경을 가진 개발자의 개발 효율성을 크게 향상시킵니다.

그러나 모든 사람이 TS를 사용하고 싶어하는 것은 아닙니다. 중소 규모 프로젝트에서는 TS를 도입해도 뚜렷한 이점이 많지 않을 수 있습니다. 이러한 경우 TS 없이 Angular를 사용하는 것은 어려울 수 있으므로 Vue를 사용하는 것이 더 나은 선택이 될 것입니다.

마지막으로 Vue와 TS의 통합이 Angular만큼 깊지는 않지만 공식적인 Type 선언 및 Component 데코레이터도 제공하며 프로덕션에서 Vue + TS 조합을 사용하는 사용자가 많다는 것을 알고 있습니다. 환경. 또한 Vue + TS 사용자에게 더 나은 유형 검사 및 IDE 개발 환경을 제공한다는 목표로 Microsoft의 TS/VSCode 팀과 적극적으로 협력하고 있습니다.


런타임 성능

두 프레임워크 모두 빠르며 벤치마크 데이터가 매우 유사합니다. 특정 데이터를 탐색하여 더욱 세밀하게 비교할 수 있지만 속도가 결정적인 요인이 되어서는 안 됩니다.


크기

크기 측면에서 최근 Angular 버전은 AOT 및 tree-shaking 기술을 사용하여 최종 코드 크기를 많이 줄입니다. 그러나 그럼에도 불구하고 Vuex + Vue Router(gzip 이후 30kB)가 포함된 Vue 프로젝트는 이러한 최적화를 사용하여 생성된 기본 프로젝트 크기(~65KB)보다 여전히 훨씬 작습니다angular-cli.


Flexibility

Vue는 Angular보다 더 유연합니다. Vue는 공식적으로 프로젝트 구축에 도움이 되는 빌드 도구를 제공하지만 애플리케이션 코드 구성 방법을 제한하지는 않습니다. 엄격한 코드 구성 표준을 선호하는 사람도 있지만, 보다 유연하고 자유로운 접근 방식을 선호하는 개발자도 있습니다.


Learning Curve

Vue를 배우려면 HTML과 JavaScript에 대한 좋은 기초만 있으면 됩니다. 이러한 기본 기술을 갖춘 가이드라인을 읽으면 매우 빠르게 개발에 뛰어들 수 있습니다.

Angular의 학습 곡선은 매우 가파릅니다. 프레임워크로서 API 영역은 Vue보다 훨씬 크므로 효율적으로 작업을 시작하려면 더 많은 개념을 이해해야 합니다. 물론 Angular 자체의 복잡성은 크고 복잡한 애플리케이션만을 대상으로 하는 설계 목표 때문이지만, 이로 인해 경험이 부족한 개발자에게도 상당히 불리하다는 점은 부인할 수 없습니다.


Ember

Ember는 다목적 프레임워크입니다. 이는 많은 수의 규칙을 제공하며 일단 익숙해지면 개발이 매우 효율적이 될 것입니다. 그러나 이는 학습 곡선이 높고 유연하지 않다는 의미이기도 합니다. 이는 프레임워크와 라이브러리(느슨하게 결합된 도구 세트 포함) 간의 절충안을 의미합니다. 후자는 더 자유롭지만 더 많은 아키텍처 결정을 내려야 합니다.

즉, 가장 좋은 비교는 Vue 코어와 Ember의 templates 및 data modellayer 간의 비교입니다.

  • Vue는 일반 JavaScript 객체에 응답을 구축하여 자동화된 계산 속성을 제공합니다. Ember에서는 모든 것을 Ember 객체 안에 넣고 계산된 속성에 대한 종속성을 수동으로 선언해야 합니다.

  • Vue의 템플릿 구문은 모든 기능을 갖춘 JavaScript 표현식을 사용할 수 있는 반면, Handlebars의 구문은 도우미 기능에 비해 매우 제한적입니다.

  • 성능 측면에서 Vue는 Ember 3.x의 최신 Glimmer 엔진을 사용하더라도 Ember보다 훨씬 낫습니다. Vue는 배치를 자동으로 업데이트할 수 있지만 Ember는 성능에 민감한 시나리오에서 수동 관리가 필요합니다.


Knockout

Knockout은 MVVM 및 종속성 추적 분야의 선구자입니다. 반응형 시스템도 Vue와 매우 유사합니다. 브라우저 지원 및 기타 측면에서의 성능도 인상적입니다. 최소한 IE6을 지원할 수 있는 반면 Vue는 최소한 IE9만 지원할 수 있습니다.

Knockout은 시간이 지남에 따라 약간 느려지고 약간 낡아 보이기 시작합니다. 예를 들어, 구성 요소 시스템에는 완전한 수명 주기 이벤트 메서드가 부족하지만 요즘에는 이러한 메서드가 매우 일반적입니다. 그리고 Vue에 비해 하위 컴포넌트의 인터페이스를 호출하는 방법이 조금 번거롭습니다.

연구에 관심이 있다면 둘이 인터페이스 디자인에 대해 서로 다른 개념을 가지고 있다는 것도 알게 될 것입니다. 이는 각자가 만든 간단한 Todo List에 반영될 수 있습니다. 다소 주관적일 수 있지만 많은 사람들은 Vue의 API 인터페이스가 구조적으로 더 간단하고 우아하다고 생각합니다.


Polymer

Polymer는 Google이 후원하는 또 다른 프로젝트이며 실제로 Vue에 영감을 주었습니다. Vue의 구성요소는 Polymer의 사용자 정의 요소와 대략적으로 비교할 수 있으며 두 요소의 개발 스타일은 비슷합니다. 가장 큰 차이점은 Polymer가 최신 버전의 Web Components 표준을 기반으로 하며 작업을 돕기 위해(성능 저하와 함께) 무거운 폴리필이 필요하며 브라우저 자체에서는 이러한 기능을 지원하지 않는다는 것입니다. 이에 비해 Vue는 IE9를 지원할 때 작동하기 위해 폴리필에 의존할 필요가 없습니다.

Polymer 버전에서는 성능을 보완하기 위해 팀에서는 데이터 바인딩 시스템을 매우 제한적으로 사용합니다. 예를 들어 Polymer에서 지원되는 유일한 표현식은 부울 부정과 단일 메서드 호출뿐이며 계산된 메서드의 구현은 그다지 유연하지 않습니다.


Riot

Riot 3.0은 작고 아름다운 API를 제공하는 유사한 구성 요소 기반 개발 모델(Riot의 태그라고 함)을 제공합니다. Riot과 Vue는 디자인 철학에서 많은 유사점을 가질 수 있습니다. Vue는 Riot보다 약간 무겁지만 Vue에는 여전히 많은 중요한 장점이 있습니다.

  • 더 나은 성능. Riot은 가상 DOM 대신 Traverse the DOM tree를 사용하지만 실제로는 더러운 검사 메커니즘을 사용하므로 AngularJS와 동일한 성능 문제를 안고 있습니다.

  • 더 성숙한 도구를 지원합니다. Vue는 webpack 및 Browserify에 대한 공식 지원을 제공하는 반면 Riot는 커뮤니티에 의존하여 통합 시스템을 구축합니다.