캔버스 편집기를 포기한 실험, 접근성과 긴 문서 성능 때문에 textarea로 이동

Sublime Text를 오래 썼는데, 큰 파일을 다루는 성능은 지금도 감탄스러움. 아직도 잘 돌아가는데 왜 과거형으로 말하는지 모르겠음.

팀에서 VS Code를 밀고 있지만 이미 완전히 스크립트 가능하고 프로그래밍할 수 있는 Emacs가 있음. 텍스트 편집은 해결된 문제고, VS Code 장점 대부분은 Vim이나 Emacs 설정으로 만들 수 있다고 봄.

Emacs를 매일 쓰고 Vim 키바인딩도 쓰지만, VS Code가 인기 있는 이유는 분명함. 시작이 쉽고 기본값이 멀쩡하며 기능도 많음. Emacs는 생산성에 이르기까지 드는 노력이 더 큼.

웹 개발이라면 VS Code가 익숙한 웹 기술 스택 위에 있다는 점이 큼. 문제는 개발자 도구로 보고, 성능 프로파일도 돌리고, 확장 버그도 PR로 고칠 수 있음. Zed는 설정 폭이 좁고 WebStorm은 XML 설정과 상태값이 뒤엉켜서 더 괴로웠음.

사람들이 Emacs로 충분하다고 인정하면 자기들이 만드는 새 도구 상당수가 쓸모없을지 모른다는 것도 인정해야 함. Chromium 기반 브라우저와 관측 플랫폼이 끝없이 늘어나는 이유 중 하나라고 봄.

대부분은 Emacs의 무한한 설정 가능성에 관심이 없음. VS Code 정도의 설정 폭과 더 쉬운 사용법이면 충분하고, Emacs는 사람마다 환경이 달라져 서로 맞지 않는 경우도 많음.

Vim이나 Emacs가 설정으로 다 된다는 말은 맞을 수 있는데, 그래서 어느 쪽 설정을 쓰라는 건지부터 답해야 함.

Emacs를 배우고 싶었지만 투자 대비 보상이 안 보여서 결국 nano를 계속 씀. 튜토리얼을 해도 이동하고 종료하는 정도인데 그건 nano에서도 되니까.

텍스트 편집이 해결됐다는 말은 동의 못 함. 편집기 상당수가 입력이나 수정 때 눈에 보이는 지연이 있음. Emacs, 특정 설정의 nvim, VS Code, Sublime도 그렇고, 편집은 체감상 즉시 끝나야 함.

새 편집기를 만들겠다고 시작한 사람은 매번 텍스트 편집이 어렵다는 걸 발견함. 그래도 접근성을 초기에 고려한 건 좋았음.

FPS 카운터가 있다는 건 계속 루프를 돌며 렌더링 중이라는 뜻인가. 편집기에 그럴 필요가 있는지 궁금함.

30년간 이 용도로 만든 <textarea>가 성능과 동작 일관성에서 낫다는 결론은 당연함. 다만 이 단계는 텍스트 편집기라기보다 화려한 입력 필드를 넣은 웹사이트에 가까움.

브라우저 기본 동작에만 기대면 플랫폼마다 같은 경험을 만들기 어려움. 브라우저 안에서 일관된 경험을 주는 건 이해하지만, 웹 전체가 그렇게 동작한 지는 오래됐음.