대부분은 “왜?”를 알고 싶어 할 것 같음. 이 문서가 ProseMirror와의 차이를 다루고 있어서 그 질문에 가장 가까운 답이었음: https://wordgard.net/docs/prosemirror/
한 가지 주목할 점은 업그레이드 경로가 없다는 것임. ProseMirror와 공유하는 개념은 많지만, 전환하려면 꽤 많은 작업이 필요해 보임. Obsidian은 CodeMirror 기반이라 바꾸지 않을 것 같지만, tiptap.dev 같은 곳은 영향이 있을 수 있음
@merijn, Wordgard가 전환 비용을 감수할 만큼 가치 있는 이유를 설명해 줄 수 있을지 궁금함
수정: Marijn의 개인 블로그에서 많은 쟁점이 다뤄진 걸 봤고, 더 나은 맥락을 위해 https://marijnhaverbeke.nl/blog/wordgard-0.1.html을 HN에 제출했음

“Wordgard가 전환 비용을 감수할 만큼 가치 있는가?”에 대해서는 아닐 수도 있음. ProseMirror에 만족한다면 계속 ProseMirror를 쓰면 되고, 내가 계속 지원할 것임
다만 블로그 글에서 설명했듯 ProseMirror에서 부딪힌 몇 가지 문제를 피할 수 있는 새 설계 통찰이 꽤 쌓였고, 그래서 새 반복판을 만들고 싶어졌음
웹사이트 문서 섹션에 블로그 글 링크를 추가하겠음
그리고 이름은 merijn이 아니라 marijn임

블로그에 “이제 ProseMirror 말장난도 별로 마음에 들지 않는다. CodeMirror인데 산문용이라는 뜻, 알겠죠?”라고 되어 있으니, 이제 누군가 Codegard를 만들 차례인 듯함

“전환 비용을 감수할 가치가 왜 있나?”가 진짜 궁금한 질문임. 더 중요하게는 왜 그냥 ProseMirror v2로 만들지 않았는지도 궁금함
랜딩 페이지에는 “무엇”보다 “왜”에 대한 정보가 더 필요해 보임

같은 생각임. 정말 아름답고, 기존 웹사이트에 이런 일러스트를 넣으려면 비용이 어느 정도일지 궁금함

그래픽이 놀라울 정도로 좋고 Ghibli 느낌도 남. 리치 텍스트 에디터 맥락에서 이런 말을 하게 되는 게 신기함

약 25년 전 학교 신문에 PHP-Nuke 사이트를 띄우기 위해 위지윅 에디터를 돌리는 게 큰 난관이었고, 결국 넘어섰던 기억이 있음
이런 기능에 대해 15년 전에 이미 통과된 웹 표준 구현이 없다는 게 말이 안 됨

contenteditable이 있고, Wordgard나 ProseMirror 같은 것들도 근본적으로는 그 위에 만들어짐. 나머지는 사용자 인터페이스와, 임의의 HTML 입력을 원하지 않는 시스템과의 상호운용성에 가까움

오랫동안 브라우저 벤더들은 단순한 텍스트 선택 동작의 세부사항조차 합의하지 못했음

이건 놀라울 정도로 훌륭해 보임
최근 비슷한 걸 찾다가 결국 직접 만들었는데, 블록 기반 운영 변환(OT) 으로 로컬 서버에 동기화하고 원격 서버에는 차이 기반 동기화를 붙였음
시스템 가이드를 읽으면서 계속 고개를 끄덕이고 있음. 비슷한 점과 대비되는 점을 보니 꽤 검증받는 느낌임

ProseMirror는, 아마 Wordgard도 마찬가지로, 맞게 처리한 부분이 정말 많음

모든 에디터가 실패했던 아주 기본적인 영역이 하나 있음. iPhone으로 에디터 안에서 완전한 문장을 입력할 수 있느냐는 것임
Wordgard는 이 테스트를 통과하지 못했음. 자동 수정이나 키보드 추천에서 들어오는 입력이 삼켜지고, 부분적으로 입력했거나 철자가 틀린 단어가 삭제됨

ProseMirror는, 형제 댓글에서 말한 Lexical도 그렇고, 이 부분을 잘 처리할 수 있어야 함
모바일 Safari와 Android Chrome은 데스크톱 형제 브라우저와 달리 이상한 동작을 정말 많이 하고, 표준도 꽤 느슨하게 다룸. 그래서 제대로 동작하게 만들려면 긴 꼬리의 우회 코드가 필요해지는 경우가 많음
Wordgard도 결국 도달하겠지만, 첫 릴리스 전까지의 초점은 아키텍처였음

몇 년 전에 웹 기반 리치 텍스트 에디터를 검토했었음. 데스크톱에서는 다 괜찮아 보였지만, 모바일에서는 시도한 것마다 엉망이었음
선택이 안 되고, 자동 수정이 깨지고, 텍스트를 눌러도 커서가 이동하지 않고, 입력이 멈추고, 요소가 포커스를 잃어도 키보드가 사라지지 않는 식이었음
지난 수십 년 동안 웹에 제대로 된 리치 텍스트 요소를 추가하려는 시도는 여러 번 있었지만 왜 다 실패했는지는 모르겠음. 크고 복잡하고 보상 없는 작업이라 그런 듯함
제대로 된 네이티브 리치 텍스트 지원은 웹의 큰 사각지대 중 하나임. 네이티브 플랫폼들은 수십 년 전에 해결한 문제임

약 6년 전 @ 스타일의 원격 리소스 자동완성, 즉 다른 사용자나 문서를 참조하는 기능을 조사하고 구현하느라 매우 고생했음. 이 에디터의 확장 방식은 ProseMirror의 진화형처럼 보임
이게 공룡 예제를 바탕으로 직접 만들어야 하는 게 아니라 기본 내장 기능이면 정말 좋겠음. 이런 텍스트 에디터 라이브러리를 쓸 때마다 1순위 사용 사례가 이것이고, 그다음이 위지윅임

@ 멘션 스타일이 기본 제공되고 API만 제공되면 훌륭할 것임 일급 모바일 지원도 마찬가지로 필요함

ProseMirror를 TipTap으로 쓰면서 힘들었던 점은, 문서의 JSON 표현을 프로그램적으로 다뤄서 데이터를 추출해야 하는 경우가 아주 많다는 것임. 그러려면 정적 타입이 붙은 표현이 필요하거나, 적어도 강하게 선호하게 됨
ProseMirror에는 이를 위한 장치가 딱히 없어서 결국 둘 중 하나를 하게 됐음

스키마를 두 번 정의함. 한 번은 ProseMirror로, 한 번은 Zod 같은 것으로 정의하고, 두 스키마가 일치하는지 확인하는 동등성 테스트를 잔뜩 둠

ProseMirror 스키마를 출력할 수 있는 메타 스키마 정의 계층을 만들되, 표준 스키마 명세 https://standardschema.dev/를 따르게 함. 이 접근은 Tiptap 같은 것을 쓰지 않을 때 더 실용적임
Wordgard는 아직 써보지 않아서 이 문제를 다루는지 모르겠지만, 해결되면 좋을 고통 지점이라 짚어둠

웹사이트의 아트워크가 아름다움. 관심을 끄는 이런 방식이 새삼 잊혀졌던 것처럼 느껴짐

“AI 0% 포함”이기도 함. 이 아티스트는 정말 멋짐

여기저기 AI 쓰레기가 넘치는 상황에서 손으로 그린 아름다운 일러스트를 보니 정말 상쾌함

웹에서 위지윅을 좋아하지 않음. 포럼 글을 길고 지루하게 서식 잡아놓고 탭을 닫으면 전부 사라짐
로컬 텍스트 에디터를 쓰고 웹 폼에 Ctrl+V로 붙여넣는 쪽을 선호함. Markdown이면 그렇게 할 수 있음

어떤 플랫폼들은 localStorage로 이 문제를 해결하는 걸 봤음. 입력하는 동안 “초안”을 자동 저장하고, 페이지를 다시 열면 자연스럽게 복원함
실수로 탭을 닫은 뒤 처음 이걸 겪었을 때 정말 기분 좋은 놀라움이었음

Linear를 확인해 보길. 관계자는 아니지만, 바로 어제 실수로 대화상자를 닫았고 다시 이슈 생성을 눌렀더니 내가 쓴 긴 글이 그대로 있었음
요점은 이게 기술 문제가 아니라 제품 문제라는 것임

경우에 따라 다름. 내 블로그에는 웹 기반 에디터가 있지만, 그냥 Markdown을 쓰고 미리보기를 붙인 형태라서 설명한 작업 흐름과 비슷함
노트 앱에는 위지윅을 쓰기로 했는데, 분할 보기를 둘 공간이 없고 Markdown 원문만 보고 싶지도 않았기 때문임
위지윅에 대한 가장 큰 불만은 방해가 될 수 있다는 점임. 예를 들어 verbatim 블록을 만들었는데 그 블록에서 빠져나올 수 없을 때가 있음. Teams를 보고 하는 말임. 그래서 LaTeX를 그렇게 좋아했던 것 같기도 함

ProseMirror와 다른 에디터용으로 좋은 백엔드들이 이미 있음. 설정하기 어렵지 않음

동의하지만 많은 사람은 위지윅을 선호함. 단순하게는 여러 HTML 에디터나 Markdown 에디터처럼 나란히 보기를 두면 됨