Restful 백엔드 용 Ember.js 또는 Backbone.js
ember.js가 backbone.js와 달리 더 무거운 접근 방식이라는 것을 이미 알고 있습니다. 나는 둘 다에 대한 많은 기사를 읽었습니다.
레일스 레스트 백엔드의 프런트 엔드로 어떤 프레임 워크가 더 쉽게 작동하는지 스스로에게 묻고 있습니다. backbone.js의 경우 나머지 백엔드를 호출하는 다른 접근 방식을 보았습니다. 엠버의 경우 '데이터'또는 '리소스'와 같은 라이브러리를 더 포함해야하는 것 같습니다. 이를 위해 두 개의 라이브러리가있는 이유는 무엇입니까?
그래서 더 나은 선택은 무엇입니까? 프론트 엔드와 백엔드를 연결하는 예는 많지 않습니다. 이것에 대한 백엔드 나머지 호출에 대한 좋은 작동 예는 무엇입니까?
URI : ../restapi/topics GET 인증 자격 증명 : admin / secrect 형식 : json
대중적인 의견과는 달리 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를 사용하십시오.
간단하고 간단한 답변을 제공하려면 RESTful 백엔드의 경우 현재 Backbone을 사용해야합니다.
좀 더 복잡한 대답을하기 위해 : 그것은 당신이하는 일에 달려 있습니다. 다른 사람들이 말했듯이 Ember는 다양한 용도로 설계되었으며 다양한 사람들에게 어필 할 것입니다. 내 짧은 대답은 RESTful 요구 사항 포함을 기반으로합니다.
현재 Ember-Data (Ember 내의 기본 지속성 메커니즘 인 것처럼 보임)는 생산 준비가되어 있지 않습니다. 이것이 의미하는 바는 꽤 많은 버그가 있고, 결정적으로 중첩 된 URI (예 : / posts / 2 / comments / 4556)를 지원하지 않는다는 것입니다. REST가 요구 사항 인 경우 Ember를 선택하면 당분간이 문제를 해결해야합니다 (즉, 해킹하고 기다린 다음 Ember-Data와 같은 것을 처음부터 직접 구현하거나 사용하지 않아야합니다. -매우 RESTful URI). Ember-Data는 엄격히 Ember의 일부가 아니므로 전적으로 가능합니다.
크기를 제외하고 둘 사이의 주요 차이점은 기본적으로 다음과 같습니다.
Ember는 최대한 많은 코드를 작성할 필요가 없도록 최대한 많은 작업을 수행하려고합니다. 매우 계층 적이며 앱이 매우 계층 적이라면 잘 맞을 것입니다. 그것은 당신을 위해 너무 많은 일을하기 때문에 버그가 어디에서 오는지 파악하고 예상치 못한 동작이 발생하는 이유를 추론하는 것이 어려울 수 있습니다 (많은 "마법"이 있습니다). Ember가 빌드 할 것으로 예상하는 앱 유형에 자연스럽게 맞는 앱이 있다면 문제가되지 않을 것입니다.
Backbone은 (사용중인 프레임 워크의 아키텍처에 맞는 앱을 빌드하는 대신) 진행 상황을 추론하고 앱에 맞는 아키텍처를 빌드 할 수 있도록 가능한 한 적은 작업을 수행합니다. 시작하기가 훨씬 쉽지만 조심하지 않으면 매우 빨리 엉망이 될 수 있습니다. 계산 된 속성, 자동 바인딩 해제 이벤트 등과 같은 작업을 수행하지 않고 사용자에게 맡기므로 많은 항목을 직접 구현해야합니다 (또는 적어도이를 수행하는 라이브러리를 선택해야합니다). 오히려 전체 요점.
업데이트 : 최근 Ember는 이제 중첩 된 URI를 지원하는 것으로 보입니다. 그래서 질문은 당신이 얼마나 마법을 좋아하는지, 그리고 Ember가 당신의 앱에 구조적으로 잘 맞는지에 달려 있다고 생각합니다.
귀하의 질문이 곧 차단 될 것이라고 생각합니다. :) 두 프레임 워크간에 몇 가지 경합이 있습니다.
기본적으로 Backbone은 많은 일을하지 않습니다. 그것이 제가 좋아하는 이유입니다. 많은 코딩을해야하지만 올바른 위치에서 코딩 할 것입니다. Ember는 많은 일을하므로 그것이 무엇을하는지 지켜 보는 것이 좋습니다.
서버 토론은 Backbone이 수행하는 몇 안되는 작업 중 하나이며 그와 함께 훌륭한 작업을 수행합니다. 그래서 저는 Backbone으로 시작한 다음 완전히 만족스럽지 않으면 Ember를 시도해 보겠습니다.
Backbone의 제작자 인 Jeremy Ashkenas와 Ember의 회원 인 Yehuda Katz가 좋은 토론 을하는 이 팟 캐스트를 들을 수도 있습니다.
참고 URL : https://stackoverflow.com/questions/12996823/ember-js-or-backbone-js-for-restful-backend
'code' 카테고리의 다른 글
| windows.h가 포함되어 있는데 std :: min이 실패하는 이유는 무엇입니까? (0) | 2020.08.21 |
|---|---|
| Python 반복기에서 마지막 항목을 가져 오는 가장 깨끗한 방법 (0) | 2020.08.21 |
| PHP에서 "if / else"의 약어로 삼항 연산자 (? :)를 어떻게 사용합니까? (0) | 2020.08.21 |
| 임의의 부울 값을 반환하는 가장 좋은 방법 (0) | 2020.08.21 |
| Rails에서 파일 업로드를 어떻게 테스트합니까? (0) | 2020.08.20 |