3P by GN⁺ | ★ favorite | 댓글 2개
  • Nash는 별도 서비스 없이 웹브라우저에서 열고 편집하는 HTML 기반 독립 실행형 노트
  • 저장한 노트를 오프라인에서도 수정할 수 있어, Notion이나 Word 대신 문서 파일처럼 다루는 방식을 목표로 함
  • 정적 블로그, 단일 페이지 콘텐츠, 갤러리의 피자 사진 첨부처럼 HTML 문서형 콘텐츠 제작에 활용할 수 있음
  • 메신저로 전달하면 미리보기로 확인할 수 있어, 긴 콘텐츠를 파일처럼 공유하는 흐름도 가능함
  • Nash는 오픈소스로 공개되어 있으며, 빈 노트 페이지를 자유롭게 수정해 사용할 수 있음

브라우저만으로 쓰는 HTML 노트

  • Nash는 note as HTML을 지향하는 독립 실행형 노트임
  • 별도 소프트웨어나 서비스가 필요 없고, 일반적으로 설치되어 있는 웹브라우저만 있으면 사용할 수 있음
  • 저장한 노트는 오프라인 편집을 지원함
  • 빈 노트는 nash.html에서 열 수 있음

만들 수 있는 콘텐츠와 공유 방식

  • 정적 블로그나 단일 페이지 콘텐츠 제작에 사용할 수 있음
  • 갤러리에 있는 사진을 첨부하는 식의 콘텐츠 작성도 가능함
  • 메신저로 전달하면 미리보기로 볼 수 있어 긴 콘텐츠 공유에 활용할 수 있음
  • 단일 HTML로 간단한 아이디어를 POC하던 경험에서 출발했으며, 별도 서비스나 소프트웨어 없이 동작하는 문서 파일을 만들기 위한 첫 시도임
  • Nash는 오픈소스로 공개되어 있어 자유롭게 수정하고 사용할 수 있음

댓글과 토론

Nash, 단일 HTML 로 동작하는 노트

Show GN에 올리셨던 걸 해커뉴스에도 올리셨는데 투표를 많이 받으셨네요. 축하드립니다!

Hacker News 의견들
  • 무거운 작업의 상당 부분이 간단하지만 강력한 HTML 속성 하나로 처리되는데, 의외로 이걸 아는 개발자가 많지 않은 듯함
    꽤 오래전부터 있던 기능임

    • 이 한 줄이 Writely의 초기 구현에서 거의 90%를 차지했음
      Writely는 나중에 Google Docs가 된 스타트업이고, 창업자 중 한 명으로서 말하는 것임
      나머지 90%는 브라우저마다 이상한 contenteditable 구현 버그가 달라서, 편집 내용을 제대로 동기화하려고 작성해야 했던 백엔드 코드였음 :-)
    • 정말 대단함. 2016년쯤에도 중소기업용 맞춤 사이트를 많이 만들고 있었는데, 대부분은 WP 같은 걸로 가능하다는 걸 깨달았음
      다만 (1) WP 스타일링이 너무 귀찮고 유지보수하고 싶지 않았고, (2) 플러그인 기능과 WP 업그레이드에 의존하고 싶지 않았고, (3) 접근 권한이 다른 사람들이 같은 페이지의 서로 다른 부분을 편집할 수 있게 하고 싶었는데, 대부분의 CMS에서는 사실상 불가능했음
      그래서 contenteditable과 TinyMCE만 기반으로 CMS를 거의 처음부터 만들었고, 편집 가능한 영역에 해당 태그를 붙였음. 물론 저장 전에는 백엔드에서 누가 무엇을 편집할 수 있는지 검사함
      클라이언트나 직원이 로그인하면 자기 권한이 있는 페이지 영역만 바로 편집할 수 있고, CMS는 편집 가능한 부분에 점선 테두리를 보여줌. 폰트와 색상은 TinyMCE 설정에 저장해 둬서 HTML을 뒤지거나 건드릴 필요가 없음. 원하면 직접 건드릴 수도 있음
      클라이언트 입장에서는 꽤 마법처럼 느껴짐. 변경 후 모습을 보려고 별도 편집 페이지로 갈 필요 없이, 페이지에서 제자리 편집하고 저장하면 바로 배포되기 때문임
      이 사이트들 대부분은 5~10년이 지난 지금도 운영 중이고, 내 쪽 유지보수는 거의 필요하지 않음
    • 몇 주 전에 이 개념의 라이브 데모를 만들었음. HTML의 숨겨진 기능치고는 정말 단순하면서 강력함
      https://news.ycombinator.com/item?id=43179649
    • 이거 좋음. 예전에 문서를 HTML로 변환한 뒤 최상위 div에 contenteditable="true"를 넣어서 PDF 편집기를 만든 적 있음
    • “오, 여기 엄청난 게 있는데 이름이 바퀴고 꽤 오래전부터 있었어”처럼 읽힘
      20년 전에도 이걸로 작업했던 것 같음
      ContentEditable은 2000년에 IE 5.5에서 처음 도입됐고, 2007년에는 주요 브라우저 전부에서 쓸 수 있었음
  • 아주 마음에 들고, 소스를 보니 순수 JavaScript로 작성 중이라 더 좋음
    요즘은 라이브러리나 프레임워크 없이도 꽤 상호작용 많은 웹 앱을 만들 수 있다는 점이 과소평가되어 있음
    단순한 로컬 웹 앱을 단일 HTML 페이지로 만드는 아이디어도 정말 좋음. 예전에 아이와 과학 박물관에 갔다가 간단한 스톱모션 애니메이터를 써봤고, 비슷한 웹 앱을 만들어 단일 HTML 파일로 아이 노트북에 복사해 줬더니 인터넷 없이도 쓸 수 있었음
    다만 나는 순수 JavaScript를 직접 쓰기 귀찮아서 React와 번들러로 만들었고, 결과물은 단일 HTML 파일로 묶임. 언젠가 Show HN에 올릴지도 모름

    • 예전에 “그거 하려고 jQuery 필요 없음”이 있었듯이, 이제는 “그거 하려고 React나 Vue, Svelte 같은 게 필요 없음”이 필요함
      평범한 순수 JavaScript와 괜찮은 실력이면 거의 모든 걸 더 깔끔하고 유지보수하기 쉽게 만들 수 있음
      수십 년간 남이 만든 걸 유지보수해 보니, 똑똑한 사람이 만든 멍청할 정도로 단순한 설계가 다른 조합들을 이김
    • Quarto의 이런 점이 좋음. 독립 실행형 HTML 파일을 만들어 사람들과 공유할 수 있음
  • 잘 만들었음
    로컬 디스크에서 브라우저로 페이지를 열면 자동으로 편집 모드가 되고, 누군가의 웹사이트에 게시되어 공개 웹에서 접근할 때는 일반적인 읽기 전용 보기가 되도록 동작을 바꾸는 것도 고려해볼 만함. 주소가 http/https인지 확인하면 됨
    물론 편집 모드로도 볼 수 있도록 쿼리 문자열 매개변수나 매직 URL 프래그먼트 같은 우회 방법이 있어야 함
    또 특정 도메인이나 URL 접두어에는 예외를 둘 수 있어야 함. 기본값은 keepworking.github.io 또는 <https://keepworking.github.io/nash/>로 해서 그 사이트에서도 편집 모드가 켜지게 하면, 데모를 위해 따로 할 일이 없어짐
    이 예외가 사용자가 수정 가능하면 더 좋음. 예를 들어 다른 사람도 1번의 트릭 없이 같은 동작을 얻을 수 있음

    • 콘텐츠를 편집하고 로컬에 저장할 수 있는 웹사이트라는 아이디어가 정말 좋음
      개인적으로는 훌륭하니 지금 방식 그대로 남겼으면 함
  • https://rpdillon.net/redbean-tiddlywiki-saver.html를 쓰면 “진짜” 저장이 되는 자급자족형 휴대용 앱으로 만들 수 있음

    • 예전에 비슷한 걸 만들었고, https://original.littr.me에서 볼 수 있음
    • 파일 저장을 제안하도록 만들어주면 좋겠음
      그러면 원할 때 개인 북마크를 가질 수 있는 기능에 훨씬 가까워짐
  • 좋음. 이 아이디어와 TiddlyWiki를 언급한 이전 논의가 있었음
    https://news.ycombinator.com/item?id=43179649

  • 브라우저가 로컬 웹 앱을 더 잘 지원했으면 좋겠음
    로컬 파일이 영구 저장소에 쉽게 접근할 수 있다면 빠르고 쉬운 GUI 앱에 많은 기회가 열릴 수 있음. 사실상 Electron의 반대 방향임

    • 파일이 어떻게 무언가에 접근할 수 있나? 파일은 그냥 데이터라서 아무것도 할 수 없음
  • 멋짐. 웹사이트의 JavaScript 부분을 실제 HTML 밖에 작성하는 데 너무 익숙해져서인지, 처음 봤을 때 “와, 이걸 HTML만으로 할 수 있다니 신기하다”라고 생각했음
    그런데 소스를 보니 평범한 script 태그 안에 JavaScript가 들어 있어서, 그렇게 할 수도 있다는 사실을 다시 떠올림

    • HTML은 과소평가되어 있음
      우리가 매일 보는 화면 대부분, 심지어 코드 편집기도 HTML 페이지
    • 분리 가능성이나 버전 관리를 원한다면 꼭 해야 할 방식은 아님. 하지만 분명 할 수 있는 방식임
      더 놀라운 건 사람들이 프레임워크를 쓰면서 HTML 안에 JavaScript도 아닌 것들을 넣고, 외부 JavaScript가 나중에 붙거나 하이드레이션해야 하는 구조를 쓴다는 점임. 양쪽의 나쁜 점만 합친 느낌임
      나는 반대쪽에 가까워서 JavaScript가 중심이고, index.html을 제외하면 .html 확장자 파일이 없음. JavaScript 안에도 HTML을 넣지 않음. 부분 템플릿은 전부 .htm이고, DOM에 추가되기 전에 하이드레이션
  • 편집한 뒤 저장하지 않고 페이지를 닫으려 할 때 경고가 나오면 좋겠음
    onbeforeunload 처리기 추가를 고려해볼 만함

    • 지금 이 웹페이지에도 닫을 때 경고가 있긴 하지만, 일반적으로 좋은 제안임
  • 이런 단순한 도구가 좋음. 얼마 전에 간단한 맞춤 “홈페이지”/대시보드를 만들었음: https://github.com/rcarmo/onepage-by-spec

    • 방금 “저장”도 되도록 업데이트했음
  • 정말 좋음. 쉽게 로컬에서 수행할 수 있고 이미 그래왔던 기능들을 구독 뒤에 숨기고 인위적인 제한을 거는 소프트웨어가 너무 많이 늘어나서 답답함
    브라우저 안에서만 동작하고, 새로운 File System Access API를 통해 로컬 파일을 편집할 수 있는 무료 Markdown 편집기를 만들고 있음. 이 API는 Chromium 계열 브라우저에서만 가능함
    https://zareith.github.io/chillmd/