대중적인 의견과는 달리 Ember.js는 Backbone.js에 대한 '더 무거운 접근 방식'이 아닙니다. 완전히 다른 최종 제품을 대상으로하는 다양한 종류의 도구입니다. Ember의 스윗 스팟은 사용자가 아마도 하루 종일 오랜 시간 동안 애플리케이션을 열어두고 애플리케이션의 뷰 또는 기본 데이터와의 상호 작용이 뷰 계층 구조의 깊은 변경을 트리거하는 애플리케이션입니다. 엠버는 백본보다 큰,하지만 덕분에 Expires, Cache-Control이것은 단지 첫 번째로드에 중요. 매일 사용하는 이틀이 지나면 콘텐츠에 이미지가 포함 된 경우 더 빨리 데이터 전송으로 인해 추가로 30k가 가려집니다.
백본은보기 계층 구조가 비교적 평평하게 유지되고 사용자가 앱에 드물게 또는 짧은 시간 동안 액세스하는 경향이있는 상태가 적은 애플리케이션에 이상적입니다. Backbone의 코드는 DOM을 지원하는 데이터가 버려지고 두 항목 모두 메모리가 수집 될 것이라는 가정을하기 때문에 짧고 멋지게 유지됩니다 : https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Backbone의 더 작은 크기는 또한 짧은 상호 작용에 더 적합합니다.
사람들이 두 프레임 워크에서 작성하는 앱은 다음 용도를 반영합니다. Ember.js 앱에는 Square의 웹 대시 보드 , Zendesk (적어도 에이전트 / 티켓팅 인터페이스), Groupon의 스케줄러 가 포함됩니다.
백본 앱은 에어 비앤비 , 칸 아카데미 , Foursquare의지도 및 목록과 같은 더 큰 정적 페이지의 작은 섹션 인 짧거나 캐주얼 한 상호 작용에 더 중점을 둡니다 .
Backbone을 사용하여 Ember가 대상으로하는 응용 프로그램의 종류 (예 : Rdio ) 를 만들 수 있습니다. a) 메모리 누수 또는 좀비 이벤트와 같은 문제를 방지하기 위해 담당하는 응용 프로그램 코드의 양을 늘 립니다 (개인적으로이 접근 방식을 권장하지 않습니다) 또는 b) backbone.marionette 또는 Coccyx 와 같은 타사 라이브러리를 추가하여 – 유사한 중복 기능을 모두 제공하려는 이러한 라이브러리가 많이 있으며 아마도 사용자 정의 프레임 워크가 더 크고 더 많은 글루 코드를 필요로 할 것입니다. 방금 Ember를 사용했다면.
궁극적으로 "어떤 것을 사용할 것인가"라는 질문에는 두 가지 답이 있습니다.
첫째, "내 경력에서 일반적으로 어떤 것을 사용해야합니까?": 둘 다, 마치 미래에하고 싶은 작업에 특정한 도구를 배우는 것과 같습니다. "Backbone 또는 D3?"라고 묻지 않을 것입니다. "백본 또는 엠버"는 똑같이 어리석은 질문입니다.
둘째, "다음 프로젝트에서 특히 어떤 것을 사용해야합니까?": 프로젝트에 따라 다릅니다. 둘 다 Rails 서버와 쉽게 통신 할 수 있습니다. 다음 프로젝트가 서버에서 생성 된 페이지와 JavaScript가 제공하는 소위 "풍부한 섬"의 혼합을 포함하는 경우 Backbone을 사용하십시오. 다음 프로젝트에서 모든 상호 작용을 브라우저 환경으로 푸시하면 Ember를 사용하십시오.