네, 최근에는 다른 플러그인 테스트를 위해 이걸 사용하고 있어요. 급하시면 제가 만든 영상을 보시거나, 로컬에 설치해서 코드를 직접 만져보셔도 됩니다. 제가 작업하기 시작한 tiptap 버전은 오픈소스로 공개하지 않았어요. 또한 초안 시스템 수정 작업도 했는데요, 사용자가 몇 개의 초안을 가질 수 있는지, 어디에 저장되는지에 대한 규칙들이 그냥 제멋대로인 것 같아서요. 그래서 이제 사용자는 원하는 만큼의 새 토픽 초안을 만들 수 있게 했습니다.
하지만 말했듯이, 정말로 정말로 심심하지 않는 한 이걸 끝내지는 못할 것 같아요 하하
경제적 유인이 없으면 제가 충분히 신경을 쓰지 않을 테니까요.
이것도 생각해 봤어요. git 리포지토리의 얼리 액세스를 판매할 수 있도록 discourse-monero 연동을 작업하고 있었거든요 (discourse와 gitea나 gitlab 같은 서비스의 연동도 알아봤어요). 하지만 "크라우드펀딩"에서 "크라우드(군중)"에 해당하는 사람들이 정말로 있는지 확신이 서지 않아요. discourse에 비용을 지불하는 사람들이 discourse를 만든 회사와 비즈니스 관계를 맺고 있는 것 같거든요.
Tiptap은 사실 비교 대상이 되기 어렵습니다. 왜냐하면 (제가 아는 한) 마크다운 단축키를 사용하여 HTML로 변환하는 데만 사용되고 있기 때문입니다. 마크다운 문법은 화면에 표시되지 않으므로, 이미 존재하는 서식을 마크다운으로 편집할 수 없습니다. 따라서 한 방향으로는 가능하지만 반대 방향으로는 불가능합니다. 제게는 출력 결과가 마크다운으로 렌더링되지 않는 Discourse용 어떤 WYSIWYG 에디터 솔루션도 시작부터 불가능합니다. 이는 핵심 호환성을 근본적으로 깨뜨리고, 선택한 특정 에디터 플러그인에 종속되게 만듭니다. Tiptap이 마크다운으로 출력을 할 수 있다면 그 방식은 괜찮을 것 같습니다.
Typora를 예로 든 이유는 그들이 WYSIWYG와 마크다운을 상당히 우아하게 조화시켰기 때문입니다. @Jagster와 같은 일부 사람들에게는 기존 동작을 유지하고 미리보기와 문법 사이를 "점프"하지 않는 기능이 바람직할 수 있습니다. 하지만 저는 Typora의 접근 방식이 많은 다른 사람들에게 더 선호되고 직관적이라고 생각합니다.
이 문제에 대해 제 입장을 이전에 설명한 적이 있습니다. 마크다운은 보조 수단(crutch)에 불과하며, 우리는 이를 제거해야 합니다.
그렇지 않습니다. 누군가가 정말로 HTML을 마크다운으로 되돌리고 싶다면 그렇게 하고 이전할 수 있습니다. 마이그레이션 스크립트를 보고 직접 작성해 보세요. 큰 문제가 아닙니다.
공감합니다.
주된 문제는 다음과 같습니다: 리액트로 작성되지 않은 모든 것은 이 시점에서 이미 손실 비용(sunk cost)일 뿐입니다. 프론트엔드 개발 경력에 진지한 사람이거나, 혹은 단순히 영향력을 미칠 수 있는 무언가를 하고 싶은 사람은 리액트가 아닌 것을 피할 것입니다.
따라서 이를 상쇄할 재정적 인센티브가 필요합니다. 개발자 경험(DX)도 매우 좋지 않습니다. 이 코드베이스로 작업하는 것은 정말 재미있지 않습니다. 그래서 제가 정말 지루할 때 이 작업을 계속하는 이유는 이미 너무 많은 시간을 투자해서 익숙해졌기 때문입니다.
이것을 '프론트엔드에서 가장 많은 취업 기회를 원하는 사람은 리액트를 배워야 한다’라고 표현하는 것이 더 좋을까요?
저는 10년 넘게 리액트가 아닌 프레임워크를 프로덕션 환경에서 사용해 왔습니다. 작은 프로젝트부터 큰 프로젝트까지, 그린필드(신규) 프로젝트부터 레거시(기존) 프로젝트까지 모두 다뤄봤습니다. 리액트는 작동 방식을 확인해 보기 위해 몇 가지 프로토타입과 장난감 프로젝트에서만 사용해 봤습니다. 제가 현재 소속된 회사는 특정 프레임워크에 대한 전문성 여부와 관계없이 유능한 자바스크립트 개발자를 채용합니다.
즉각적으로 드러나는 시장 가치와 관계없이, 기회가 주어지면 다양한 언어와 프레임워크를 배우는 것이 좋습니다. 왜냐하면 항상 배울 수 있는 보편적으로 적용 가능한 접근법이 있기 때문입니다. 또한 이는 간접적으로 다른 것을 배우는 통로가 될 수도 있습니다. 저는 최근 완전히 다른 플랫폼에서 프로젝트를 수행하기 위해 Go를 배우게 되었고, 그 과정에서 단순함과 속도의 장점을 다시 한번 깨달았습니다. 또한 좋은 API를 구축하는 방법에 대해서도 훨씬 더 많이 배울 수 있었습니다. Golang을 배우기 위해 노력을 기울이지 않았다면 그 경험을 할 수 없었을 것입니다.
Ember는 엄격하지만 Apparently 잘 설계되어 있는 것 같습니다? Discourse에서 작업하는 도전 과제는 방대한 맞춤형 플랫폼을 다루어야 한다는 점입니다. 이 플랫폼을 탐색하는 방법을 익혀야 합니다. 이를 위해 개발하게 되는 자립적 역공학(상세한 문서가 없을 때) 접근법은 완전히 다른 영역에서도 여러분에게 이점이 될 것입니다.
특정 프레임워크를 배우는 것보다 주요 플랫폼 하나나 두 가지를 배우는 것이 더 중요하다고 주장합니다. 예를 들어, PHP를 배우는 데 집중하는 것보다 Wordpress를 배우는 것이 더 중요할까요?
따라서 다양한 플랫폼과 그들의 개별 기술 스택을 배우는 것이 어떤 식으로든 문제가 되어서는 안 된다고 생각합니다. 그다음에는 이를 통해 자연스럽게 형성되는 전문적인 네트워킹이 따릅니다. 이러한 모든 경험의 조합은 여러분의 커리어에 큰 도움이 될 것입니다.
제가 여기서 보는 주요 문제는 오픈소스와 자금 조달 사이의 충돌입니다. CDCK 자체가 오픈소스를 기반으로 지속 가능한 비즈니스를 구축하는 것이 가능하다는 것을 증명했습니다. 이를 수익화하고 가치를 제공하기 위해서는 꽤 정교한 전략이 필요합니다.
생태계를 이끌어가는 사람들을 지원하는 것은 전체 커뮤니티의 책임입니다. 커뮤니티가 자신의 플랫폼을 수익화하여 기여할 수 있는 여력을 갖추는 것부터 시작해야 한다고 제안합니다. 실제로 많은 분들이 그렇게 하고 있습니다: 저는 이곳을 자주 찾는 가장 야심차고 열심히 일하는 기업가들의 자금 지원을 받아 업무를 수행할 수 있게 되어 매우 감사하고 있습니다.
사실은 이렇습니다: 지금 막 시작하는 사람이나 경력이 아직 초보 단계인 사람은 React를 배우고 그쪽에 집중하게 됩니다. 특정 기술에 집중하는 것은 일종의 베팅과 같은데, 현재 프론트엔드에서 React가 아닌 것에 커리어를 건다는 것은 현명한 선택이 아닙니다. 유일한 합리적인 대안은 Vue일 수 있지만, Ember는 분명히 아닙니다.
Ember에 집중된 커리어를 가진 사람의 수는 이미 오래전에 정점에 도달했을 가능성이 높다고 생각합니다.
Ember와 Discourse 코드베이스를 배우고 싶어 하는 사람들의 대거 유입을 보고 계신가요?
저는 그렇지 않습니다. 이것은 소프트웨어가 레거시임을 보여주는 신호입니다. 잠재력의 정점에 도달한 것이죠. 이를 사용하거나 개발하고 싶어 하는 사람들의 대거 유입이 없습니다. 재택근무 증가와 원격 협업 소프트웨어 사용이 늘어난 이후에도 마찬가지입니다. 사람들은 Zoom이나 Discord를 더 선호합니다.
제가 말하는 개발자 경험(developer experience)이 바로 그런 것입니다.
좋은 지적입니다. Discourse는 대부분 하나의 제품입니다: 약간은 매니아적인(nerdy) 청중을 위한 셀프 호스팅 커뮤니티/지원 포럼입니다. 자금 조달의 원천이 바로 그곳이기 때문에, 그 이상으로 성장할 수는 없을 것입니다. 따라서 대부분의 결정은 이 청중을 만족시키기 위해 내려질 것입니다.
다시 주제로 돌아가자면, 마크다운 편집기를 교체하는 것은 이 소프트웨어를 덜 매니아적으로 만드는 것을 의미합니다. 즉, 그것이 지향하는 청중으로부터의 이탈을 의미하는 것이죠.
이 국소 최소(local minimum)에서 벗어나기는 쉽지 않습니다.
따라서 소프트웨어가 자신의 청중을 찾게 되면, 이 청중을 만족시키기 위한 더 많은 기능이 추가되고 다른 그룹에 대한 사용성은 점점 더 소외되는 반사적 피드백 루프가 시작됩니다.
독일에는 대마초 흡연자가 350만 명 있습니다. 독일인 중 84%가 합법화에 찬성합니다. 따라서 포럼의 성장 여지가 매우 크다고 생각합니다. 현재 사용자 기반과 잠재적 사용자 기반은 규모 차이가 수 배에 달합니다. 이 목표를 달성하기 위해 작은 개선이나 수정만으로는 충분하지 않습니다.
현재 사용자 기반을 달래기 위한 변경 사항은 오히려 성장을 저해할 수 있습니다.
변화는 항상 트레이드오프를 수반합니다. 파워 유저에게는 편리함을 줄 수 있는 것이 신규 사용자에게는 진입 장벽이 될 수 있습니다. 장벽이 너무 높아지면 신규 가입이 마를 수 있으며, 포럼은 서서히 쇠퇴하게 됩니다.
네, 이건 제가 이전에 메타(Meta) 자체와 CDCK의 기존 유료 고객들의 에코 챔버에 대해 강조하려 했던 몇 가지 지점을 잘 대변합니다. 당연히 기존 고객들을 만족시켜야 하지만, "커뮤니티/토론 플랫폼"이라는 훨씬 더 큰 전체 시장이 다른 여러 플레이어들에 의해 서비스되고 있다는 것도 분명합니다. 그중 일부는 확실히 디스코urs 대신 판매를 성사시키는 데 도움이 되는 일을 하고 있습니다. 그중 하나는 WYSIWYG일 수도 있지만, 제 생각에는 이는 더 넓은 문제의 일부일 뿐입니다. 전반적인 디자인과 테마도 그중 하나인데, 위에서 이미 언급했지만 이 별도의 맥락에서 다시 강조할 가치가 있습니다: 테마가 상대적으로 부족 - 제가 뭘 놓치고 있는 건가요?
매우 좋은 지적입니다. 이건 빙산의 일각일 뿐입니다. 개선할 수 있는 부분이 많습니다. 예를 들어, 초안을 몇 개까지 가질 수 있는지에 대한 특이한 규칙이 있습니다. 처음에는 단순한 버그인 줄 알았는데, 실제로는 의도적으로 그렇게 설계되어 있었습니다.
저도 그 문제를 해결하려고 노력하고 있습니다.
아직 포기하지 마세요! 여기 있는 다른 많은 사용자들을 대신해 말씀드리자면, 이 Customization > Plugin 은 Discourse에 있어 진정한 돌파구가 될 것이며, 특히 특정 사용 사례에서는 모든 것을 바꿔놓을 것입니다. 계속 진행해서 마지막 1마일을 완주하시도록 강력히 권합니다.
좀 더 자세히 설명해 주실 수 있을까요? 저에게도 필요한 부분이 있을 수 있어서 말씀하시는 내용에 매우 관심이 많습니다. 지금 제 전적인 주의를 기울이고 있습니다…
이 문제에 대해 더 깊이 생각해 보았습니다. 컴포저를 교체하는 것은 좋은 아이디어가 아니라고 생각합니다. 왜냐하면 이는 Discourse의 최신 변경 사항을 계속 따라가야 하는 지속적인 노력을 의미하기 때문이며, 저는 이를 유지보수하는 데 그렇게 많은 시간을 쓰고 싶지 않습니다.
저는 이 과정에서 얻은 지식을 활용하여, Discourse UI를 교체하는 대신 그것과 함께 작동하는 것을 구축할 것입니다.
네, 사실 이미 자세히 살펴봤고 사용할 예정입니다. 이 도구는 에디터에 excalidraw를 통합해 주더라고요. 정말 놀랍습니다. 저는 얼마 전 이미지 업로드와 관련된 문제를 논의하기 위해 그들의 디스코드 채널에 가입했습니다. 현재 excalidraw의 예제에서는 이미지를 SVG로 임베드하는데, 이는 보안상의 우려가 있어 변경이 필요합니다. 따라서 처리해야 할 몇 가지 세부 사항이 있습니다.
하지만 ckeditor나 tiptap과 비교하면 훨씬 사용하기 쉬울 것입니다. 이 주제에 대한 일반적인 진행 상황도 간단히 업데이트해 드리겠습니다:
앞서 언급했듯이, 이와 같이 대규모인 경우 Discourse 프론트엔드를 수정하는 것은 좋은 아이디어가 아닙니다. 그래서 기존 인터페이스를 대체하려 하기보다, 이 기능을 전통적인 인터페이스의 추가 요소로 구현하는 것이 훨씬 나은 방법입니다. 지금까지 이 작업에서 얻은 지식은 다음 프로젝트에 활용될 것입니다:
이 프로젝트는 웹3 사용 사례에 초점을 맞추고 일부 웹3 기능을 포함할 예정이지만, 해당 기능을 사용할 의무는 없습니다.
따라서 이 플러그인을 사용하여 렉시컬(lexical) 에디터가 있는 카테고리를 만들 수 있게 됩니다. 이는 실험이 사이트의 일부로만 제한되므로 이 기능을 시도할 위험이 훨씬 낮다는 것을 의미합니다.
현재 저는 Discourse의 암호화폐 구독 기능 개발에 집중하고 있습니다. 이 작업이 완료되면 다시 이 프로젝트를 추진하는 데 집중할 예정입니다.
