최근 독자를 위해 2013 년 1 월 현재 다음을 평가했습니다.
"평가됨"으로 나는 문서를 읽는 것 이상의 일을했습니다. 프로토 타입 앱을 만들었습니다.
가장 큰 커뮤니티가있는 것 같았고 이것이 제 솔루션이 될 것이라고 생각했기 때문에 Fabric으로 시작했습니다. 그러나 다음과 같은 이유로 Fabric을 포기했습니다.
- 불필요하게 많은 시간을 소모 한 이상하고 문서화되지 않은 API 불일치.
- 불일치 포인터 이벤트 지원. 특히 Fabric은 "경로"를 선택 및 관찰 가능한 실제 모양 개체로 간주하지 않습니다. 대화 형 경로가 내 앱의 주요 요구 사항이기 때문에 이것은 내 요구를 충족하지 못했습니다.
- 개체를 배치하기 위해 캔버스에 번역을 추가했습니다. 저에게 Fabric은 개발자에게 무엇을하는지 명확하지 않고 이와 관련하여 너무 영리하려고합니다.
- 이동, 크기 조정 및 회전 상호 작용 방식에 대한 지나치게 강한 의견. 여러면에서이 기능을 프레임 워크에 내장하는 것은 좋지만, 필자의 경우 구현 방식에 동의하지 않았는데 이는 본질적으로 어쨌든 직접 다시 구현해야 함을 의미했습니다.
- 희소 문서-메소드의 문서가 "setX (Y)-set 's the X to Y"형식 인 경우가 많습니다. :-)
나는 Paper를보고 너무 멀리 가지 않았다. 그것은 나에게 지나치게 둔한 것처럼 보였고 또한 너무 변덕스러운 IMO 사이에 속합니다. 캔버스의 단순한 개체 모델이 되기에는 시각화 라이브러리가 너무 많지만 D3와 경쟁하기에는 시각화 라이브러리가 충분하지 않습니다. 또한 문서는 특별히 접근 할 수 없었습니다.
Flash / ActionScript에 대한 배경 지식이있는 경우 Easel이 많은 의미가 있다고 생각하지만 저는 그렇지 않습니다. 또한 내 요구 사항에 대해 지나치게 게임에 초점을 맞춘 것처럼 보였습니다. 관의 못은 다시 문서화되었습니다. 충분하지 않으며 비표준 형식으로 제공되었습니다.
그래서 저는 다음과 같은 이유로 Kinetic을 사용하게되었습니다.
- 정말 풍부하고 명확한 튜토리얼과 예제
- API 함수는 호출 된 작업을 수행하며 대부분 추측 가능합니다. 생산성 향상, 학습 곡선 감소
- 그것이 무엇을하고 무엇을하지 않는지에 대해 합리적으로 분명합니다. 그것은 다른 것들만큼 부유하지는 않지만 그것은 이점입니다. 더 적은 일을하지만 더 잘합니다
- 경로는 내 요구 사항에 필수적인 다른 Shape와 마찬가지로 일류 시민 Shape입니다.
키네틱은 어떤 방식으로도 완벽하지 않으며 실제로 내부에서 무슨 일이 일어나고 있는지 파악하기 위해 소스 코드를 깊이 파고 들어야하는 경우가 몇 번있었습니다. 또한 Fabric의 SVG 구문 분석 및 출력이 누락되었습니다.