Etherpad-lite: RFC : 재 작성에 대한 생각 (알아)

@Pita 는 다시 작성된 Etherpad가 현재보다 훨씬 낫지 만 완료하는 데 많은 시간이 걸릴 것이라고 생각합니다. 위에서 언급 한 아이디어로 개선 할 사항 :

• 콘텐츠를 편집 할 수없는 React 편집기를 사용하면 우리가 가지고있는 iframe 폭포수를 제거 할 수 있습니다. 때로는 처리하기가 악몽입니다. 다른 한편으로는 Etherpad-core와 그 플러그인 내부의 많은 것들을 망가뜨릴 수 있지만, 그것은 우리가 더 깨끗하고 단순한 코드베이스로 끝나야하는 비용입니다.
• 더 많은 TDD 접근 방식을 사용하면 현재 보유한 테스트 범위를 늘릴 수 있습니다. 현재 코드의 일부는 Etherpad-lite가 다시 작성 될 때 원래 Etherpad 코드에 대해 아주 좋은 지식을 가지고 있지 않았기 때문에 이해할 수 있습니다. 그러나 좋은 테스트 커버리지를 확보함으로써 우리는 무언가를 깨는 것을 두려워하지 않고 편집자의 핵심 부분을 변경할 수 있습니다. 예를 들어 ace2_inner.js 에서 변경해야 할 때 무언가를 깨는 것이 개인적으로 항상 두려워합니다.
• 다른 도구와 프레임 워크를 사용하여 Etherpad가 처리 할 필요가없는 작업을 수행하면 코드베이스가 훨씬 간단하고 오류 발생 가능성이 적습니다. 그리고 저는 그 사람들이 우리보다 훨씬 더 다른 것들을 다루는 방법을 알고 있다고 확신합니다. :-)

예, 이것이 좋은 아이디어라는 데 동의하며 그 후에는 Etherpad가

Rust에서 재 작성 (또는 그 일부)은 어떻습니까? 과장된 것처럼 보이며 안전하고 빨라야하는 시스템에 많은 이점이 있습니다.

Rust에서 재 작성 (또는 그 일부)은 어떻습니까? 과장된 것처럼 보이며 안전하고 빨라야하는 시스템에 많은 이점이 있습니다.

저는 Rust의 팬이지만 순수한 Rust 서버 나 wasm 프론트 엔드를하기에는 너무 이르다고 생각합니다.

내가 생각하는 한 가지 접근 방식은 C / C ++ 대신 Rust로 네이티브 모듈을 작성하는 것입니다 ... 예를 들어 Neon Rust / Node 바인딩은 오늘날 꽤 잘 작동합니다 : https://github.com/neon-bindings/neon

프론트 엔드를 위해 React를 진지하게 고려하거나 React가 적절하지 않다면 적어도 구성 요소를 고려하고 데이터 흐름 등에 대해 생각할 가치가 있다는 데 동의합니다. React는 도구 및 개발자 인식을 가지고 있지만 기여자를 유치하는 데 도움이 될 것입니다.

@lpagliari에 동의하면 기존 Etherpad 플러그인을 다시 생각하고 깨뜨릴 수 있지만 플러그인을 갖는 목표는 대부분의 플러그인이 사용하는 현재 접근 방식보다 React 스타일 구성 요소로 더 잘 제공 될 수 있습니다.

Etherpad에 대해 어떤 문제가 있는지 물어볼 때 사람들로부터들은 한 가지는 모바일 지원입니다. 단일 반응 형 프런트 엔드를 갖는 것이 아마도 가장 합리적 일 것입니다. 이것은 좋은 기회가 될 것입니다.

프로그레시브 웹 앱 지침의 전체 세트도 살펴볼 가치가 있습니다.

이에 대한 의견을 보내 주셔서 감사합니다. 대부분의 사람들이 React의 프론트 엔드 재 작성에 동의하는 것 같습니다. 그 방법에 대해 생각하기 시작하고 나중에 백엔드로 이동할 수 있습니다.

@fralix 저는 Rust를 직접 플레이했고 그 뒤에 숨은 아이디어가 마음에

@rhelmer 모바일의 현재 문제는 무엇입니까? 프론트 엔드 재 작성을 위해 이것을 우선 순위로두면 정당화하기가 더 쉬울 것 같습니다

안녕하세요 여러분,
리포지토리를 쳐다 보는 동안이 스레드를 우연히 발견했습니다 (이더 라이트 설치를 실행 중이며 좋아합니다). 이 멋진 도구를 만들어 주셔서 감사합니다.

현대적인 웹 프레임 워크를 사용한 재 작성을 고려한다면, 특히 반응하는 대신 preact (훨씬 더 빠른 vdom diffing / rendering)를 살펴보고 전체 반응 생태계와 절대적으로 호환되는 것을 권장합니다. 일부 숫자는 https://github.com/Rich-Harris/js-framework-benchmark 를 참조

또한 react-material-ui, react-bootstrap 등과 같은 일반적인 구성 요소 라이브러리를 살펴보십시오. 그러면 무료로 응답 할 수 있으며 SASS와 많이 만나고 어울릴 필요가 없습니다.

번들링을 위해 반드시 웹팩을 사용하십시오 (현재 소스 맵 및 바벨 지원을 통한 핫 리로딩 및 디버깅을 통한 최고의 개발 경험).

또한 REDUX 또는 유사한 도구를 사용하기 전에 상태 관리를 위해 mobx를 확인하십시오. ES7 데코레이터 (매우 일반적으로 사용되는 바벨 플러그인)를 사용하면 많은 상태 관리 상용구를 제거 할 수 있습니다. 모델 코딩으로 돌아가서 관찰 가능 항목을 정의하면 모든 UI가 mobx에 의한 상태 변경에 대해 반응 적으로 업데이트됩니다.

@Pita 이것에 대한 업데이트가 있습니까?