본인은 이전에 PM을 2년 미만 사용하면서 스마트 테이블과 같은 대형 모듈을 개발한 경험이 있습니다. Slate는 현재까지 사용 중이며, 0.47에서 0.5+로의 대규모 버전 업그레이드를 경험했기 때문에 어느 정도 발언권이 있다고 생각합니다. 커뮤니티 내에서 두 가지의 차이점에 대해 자주 질문을 받아서 간단히 블로그로 정리해보려고 합니다.
Slate의 장점:
-
빠른 습득이 가능하며, 바로 사용할 수 있고 개념이 이해하기 쉬우며 코드도 직관적입니다. 특히 React에 익숙한 개발자라면 뷰 레이어가 완전히 React 기반이기 때문에 대략 일주일 정도면 충분히 이해할 수 있습니다.
-
높은 커스터마이징 가능성. 자체 비즈니스 시나리오에 맞춰 slate, slate-react 같은 코어 모듈을 수정하여 다양한 플러그인과 아키텍처를 확장할 수 있습니다. PM에 비해 저수준 수정이 비교적 간단합니다.
-
sharedb와 같은 협업 시나리오에 잘 적응할 수 있습니다. JSON 기반이라 Slate에 거의 딱 맞게 설계되었습니다.
Slate의 단점:
-
버그 수정 속도가 매우 느립니다. 저자가 풀타임으로 개발하지 않고 커뮤니티에 의존하기 때문에 일부 API는 명백히 불합리합니다(예: .include로 인해 문제를 겪은 적 있음). 어떤 API는 예외를 던지지만, 어떤 API는 null을 반환하는 등 설계가 미흡한 부분이 있습니다. 저자는 직접 수정하기보다 PR을 요청합니다.
-
API가 불안정합니다. 아직 정식 버전이 출시되지 않았으며 0.x 버전입니다. 향후 아키텍처 변경이 클 수 있습니다.
-
공식 버전은 기본적으로 사용하기 어렵습니다. 특히 CJK 언어 사용자의 입력법 이벤트 등을 처리하려면 다운로드 후 직접 수정해야 합니다.
-
성능 최적화가 어렵습니다. 뷰 레이어가 완전히 React 기반이기 때문에 이 부분의 코드 최적화는 React 최적화에서만 가능합니다. React는 범용 프레임워크이기 때문에 속도 면에서 이점이 없습니다.
-
코드가 잘 작성되지 않으면 에디터가 충돌하여 사용 불가 상태가 될 수 있습니다. 프레임워크 코드를 수정하는 것 외에는 효과적인 오류 처리 메커니즘이 없습니다.
-
데이터 흐름이 명확하지 않아 버그가 발생하기 쉽습니다. 예를 들어 editor.children에 직접 값을 할당하여 기존 에디터 내용을 덮어쓸 수 있으며, 이에 대한 오류 메시지도 없습니다.
-
커서 문제와 Mark 문제를 해킹하기 어렵습니다. 코드가 초보자 수준이라고 생각합니다(개인적인 의견).
-
문서가 부실합니다. 일부 문서는 실제 API 동작과 일치하지 않습니다.
-
React와 강하게 결합되어 있습니다.
-
모바일 지원이 현재는 그리 좋지 않아 수정이 필요합니다.
ProseMirror의 장점:
-
저자가 풀타임으로 유지보수하며 매우 적극적으로 커뮤니티 질문에 답변합니다.
-
정식 버전이 출시된 지 3년 이상 되었으며 API가 매우 안정적입니다.
-
대기업의 신뢰를 받고 있습니다. Google도 저자의 다른 프로젝트인 CodeMirror를 사용합니다(Chrome Devtools의 Element Tab에서 사용). 신뢰도가 높습니다.
-
데이터 흐름이 명확합니다(이해하기 어렵지만).
-
Slate처럼 쉽게 충돌하지 않으며 오류가 발생해도 전체 에디터 프레임워크가 사용 불가 상태가 되지 않아 안정성이 높습니다.
-
저자는 프리랜서로 기부금으로 생활하며, 버그 수정을 유료로 제공합니다. 시간당 200유로입니다(이메일로 문의한 내용이며, 기억에 의존합니다).
-
문서 트리 모델이 매우 유용합니다. Schema 제한이 엄격하며 텍스트/Token 오프셋 기반의 위치 시스템이 핵심입니다. 하지만 협업에는 어려움이 있습니다.
-
특정 뷰 프레임워크에 의존하지 않습니다. React, View, Angular 등으로 뷰 프레임워크를 개발할 수 있습니다. 일반적으로 paragraph, heading, list 등은 커스텀 뷰 레이어가 필요 없으며, API로 DOM 구조를 설명하면 됩니다.
-
모바일 지원이 우수합니다.
ProseMirror의 단점:
-
일부 개념과 코드가 이해하기 어렵습니다(저자의 기술력이 매우 뛰어나다고 느껴집니다).
-
모듈이 분산되어 있어 바로 사용할 수 없으며, 초기 설정에 시간이 필요합니다.
-
PM 기반의 협업 솔루션은 Slate에 비해 구현하기 어렵습니다. 저자가 2017년에 협업 데모를 작성하겠다는 이슈를 열었지만 아직 작성되지 않았습니다.
-
학습 곡선이 가파릅니다. 기본 기능 개발을 시작하는 데 보통 2주에서 한 달이 소요됩니다.
-
자체 구현한 뷰 레이어이기 때문에(개발자도 React 컴포넌트 같은 커스텀 컴포넌트 렌더링을 위해 API를 사용할 수 있음), 프레임워크 자체의 뷰 레이어에 문제가 발생하면 진단과 수정이 어렵습니다.
-
소스 코드를 수정하기 거의 불가능하며 비용이 매우 큽니다. 저자에게 수정을 의존해야 합니다.
이 답변을 참고해보세요. 대체로 정확한 내용입니다:
Meituan의 Xuecheng은 PM을 사용합니다:
결론
Slate는 대기업에 적합합니다. 빠르게 익힐 수 있기 때문이죠(대기업은 투자 대비 효율을 중요시하기 때문에, 2개월 동안 Demo만 만들고 있다면 어떻게 상사에게 설명하겠어요?). 따라서 빠르게 결과물을 낼 수 있지만, 완벽하게 다듬으려면 하위 레이어를 대폭 수정하는 데 많은 인력이 필요합니다. 그래서 대기업에 적합한 것이죠. 초반에는 빠르게 시작하고 후반에는 인력을 추가해 대폭 수정할 수 있습니다. 또한 확장성이 매우 뛰어나서, 수정 후에는 거의 모든 요구사항을 충족할 수 있습니다(예를 들어 우리는 밑줄 코멘트, 계층적 제목 접기, 서드파티 모듈 임베딩 등 다양한 모듈과 기능을 구현했습니다).
Prosemirror는 중소기업에 적합합니다. 각 플랫폼 지원이 꽤 잘 되어 있고, 버그가 발생해도 작성자가 수정해 줄 것을 믿을 수 있습니다. 정말 고쳐지지 않으면 유료로 작성자에게 수정을 의뢰할 수도 있죠. 학습 곡선이 가파르긴 하지만, 중소기업의 주력 개발자가 2주 정도 탐구하면 Demo 정도는 만들 수 있을 겁니다.
블로거의 말:
저는 인생의 중요한 선택의 기로에 섰을 때, 누군가 최선의 방법을 알려주어 소중한 시간을 헛되이 보내지 않기를 바라곤 합니다. 그런 마음으로 저는 자주 블로그를 쓰며, 광활한 인터넷의 이 작은 구석에 제게는 단 한 번뿐인 인생 경험을 기록하여 도움이 필요한 분들에게 도움이 되기를 바랍니다.
