knockout.js가 소규모 프로젝트에는 더 좋고, 대규모 프로젝트에는 backbone.js라는 평판이있는 이유는 무엇입니까?

knockout.js가 소규모 프로젝트에는 더 좋고, 대규모 프로젝트에는 backbone.js라는 평판이있는 이유는 무엇입니까?

---

몇 달 동안 knockout.js를 사용해 왔는데 매일 사용하는 것이 즐겁습니다. DOM에서 상태를 관리하지 않거나 사용자 지정 바인딩을 적용 할 필요가 없다는 이점은 놀랍고, 즉시 사용 가능한 모델 기능이 없어도 괜찮습니다. 그러나 다른 프레임 워크와 비교하여 knockout.js에 대한 개요를 읽을 때마다 합의는 그것이 훌륭하고 전체적으로 코드와 복잡성이 줄어들지 만 소규모 프로젝트에 더 적합하다는 것입니다. 이 진술은 많은 설명없이 항상 사실의 문제로 주어 졌기 때문에 합의가 무엇인지 혼란 스럽습니다. (공정하게 나는 아직 Backbone을 사용하지 않았으므로 그들이 어떻게 비교되는지 진정으로 알지 못합니다)

나는 각각 약 12 ​​개의 모델과 12 개의 뷰 모델이있는 두 개의 꽤 큰 프로젝트에서 그것을 사용했고, 문제를 보지 못했습니다. 대규모 프로젝트에서 백본과 비교하여 볼 수있는 유일한 단점은 녹아웃을 적용하고 모든 바인딩을 관리하는 데 무시할 수없는 성능 저하를 얻게된다는 것입니다. 그러나 그것이 주요 관심사입니까 아니면 내가 놓친 다른 것이 있습니까?

---

내 (짧은) 녹아웃과 백본 비교에서 :

Knockout은 HTML과 모델간에 매끄럽고 사용하기 쉬운 모델 바인딩을 제공하는 것을 목표로합니다. 구현 및 사용 패턴과 같이 매우 XAML / Silverlight / WPF입니다 (이는 출처를 고려할 때 의미가 있음). Knockout은 모델을 넘어서는 지침이나 구성을 제공하지 않습니다. 모델 및 모델 바인딩을 넘어 잘 구조화 된 JavaScript 애플리케이션을 빌드하는 것은 개발자의 몫입니다. 이로 인해 좋은 JavaScript 경험이없는 개발자는 Knockout을 사용할 때 좋은 애플리케이션 구조를 고려해야한다는 사실을 깨닫지 못하기 때문에 종종 나쁜 길로 이동합니다. 물론이 문제는 Knockout의 잘못이 아닙니다. 대부분의 경우 도구가 제공하는 내용이나 대규모 JavaScript 앱을 구성하는 방법에 대한 이해 부족에 불과합니다.

개인적으로 나는 녹아웃을 좋아하지 않습니다. 저는 MVVM 패턴의 팬이 아닙니다. 저는 Backbone의 접근 방식을 선호하며 대부분의 시간을 작업에 보냅니다. 그러나 Knockout이 대규모 애플리케이션에 적합하지 않다는 "사실상"의견은 잘못된 것 같습니다. Knockout을 사용하면 매우 크고 복잡하며 잘 구조화 된 애플리케이션을 빌드 할 수 있습니다. 그러나 데이터 바인딩 및 모델을 넘어서는 모든 구조 를 제공 해야 합니다.

---

패션 트렌드와 같은 웹 애플리케이션 트렌드가 의견이 많은 토론을 불러 일으킨다는 것을 알게 될 것입니다. 대부분의 경우 정답이나 오답이 없습니다. 그러나 모든 사람은 자신 만의 스타일을 가지고 있으며 자신 만의 스타일을 찾아야합니다.

개인적으로 저는 Knockout과 Backbone을 모두 좋아하며 실제로 둘 중 하나를 선택할 필요가 없다는 것을 알게되어 기뻤습니다. 당신은 그들을 잘 연결하는 "Knockback"이라는 플러그인을 사용할 수 있습니다.

나는 Knockout의 선언적 바인딩과 함께 Backbone의 MVP 구조를 즐깁니다. 자세한 내용을 보려면 몇 가지 예와 함께 이에 대한 블로그 항목을 작성했습니다 .

크고 복잡한 DOM에서 Knockout의 성능 저하와 관련하여 전역 적으로 적용하는 대신 특정 DOM 요소에 대한 바인딩을 제한하여 해결할 수 있습니다.

ko.applyBindings(myViewModel, $('#myElement')[0]);

Knockout은 두 번째 매개 변수로 jQuery 객체가 아닌 DOM 요소를 예상하기 때문에 끝에 [0]이 필요합니다.

---

대규모 자바 스크립트 애플리케이션의 코드 구성은 까다로운 문제이며 프레임 워크가 많은 독자적인 구조를 제공하지 않는 한 사용하는 프레임 워크와는 무관합니다.

Backbone.js와 Knockout.js 모두 권장 디렉토리 구조 나 권장 수명주기 관리 방법론이 없으며 다른 기능과 관련하여 누락 된 기능이 커뮤니티 지원 플러그인 또는 독립 실행 형 마이크로 프레임 워크로 채워질 수 있다는 점을 고려할 때 심각하게 의미가 없습니다. 응용 프로그램의 크기 / 복잡성 측면에서 하나를 다른 것보다 우월하다고 간주합니다.

참고로 현재 대규모 자바 스크립트 애플리케이션으로 시작하는 경우 선언적 접근 방식, DOM 속성 기반 데이터 바인딩 및 MVVM 패턴을 선호하는 경우 Angular.js를 사용하는 것이 Knockout.js보다 더 적합 할 수 있으며 Ember.js는 MVC 및 문자열 기반 (핸들 바) 템플릿을 선호하는 경우 Backbone.js보다 더 적합합니다. 둘 다 활발하게 개발 중이며 기능과 관련하여 어깨를 나란히 비교하며 사람들이 이전에 발생한 Backbone 및 Knockout과 같은 작은 프레임 워크를 사용하여 대규모 응용 프로그램으로 작업하는 문제를 완화하도록 특별히 설계되었습니다.

참고 URL : https://stackoverflow.com/questions/10320074/why-does-knockout-js-have-a-reputation-for-being-better-for-small-projects-back