Show HN: Nash - 単一のHTMLファイルで作られたスタンドアロンノート
(keepworking.github.io)- Nashは別サービスなしでウェブブラウザ上で開いて編集できる HTMLベースのスタンドアロンノート
- 保存したノートはオフラインでも修正でき、NotionやWordの代わりに 文書ファイルのように扱う方式 を目指している
- 静的ブログ、単一ページのコンテンツ、ギャラリー内のピザ写真を添付するような HTML文書型コンテンツ の制作に活用できる
- メッセンジャーで送ればプレビューで確認できるため、長いコンテンツをファイルのように共有する流れも可能
- Nashは オープンソース として公開されており、空のノートページを自由に修正して使える
ブラウザだけで使うHTMLノート
- Nashは note as HTML を志向するスタンドアロンノート
- 別途ソフトウェアやサービスは不要で、通常インストールされている ウェブブラウザ さえあれば使える
- 保存したノートは オフライン編集 に対応
- 空のノートは nash.html で開ける
作れるコンテンツと共有方法
- 静的ブログや 単一ページのコンテンツ の制作に使える
- ギャラリーにある写真を添付する形のコンテンツ作成も可能
- メッセンジャーで送ると プレビュー で見られるため、長いコンテンツの共有に活用できる
- 単一HTMLで簡単なアイデアをPOCしていた経験から始まっており、別サービスやソフトウェアなしで動作する文書ファイルを作るための最初の試み
- Nashは オープンソース として公開されているため、自由に修正して利用できる
2件のコメント
Nash、単一のHTMLで動作するノート
Show GNに投稿されていたものをHacker Newsにも投稿されたのですが、たくさん投票を集めましたね。おめでとうございます！
Hacker News の意見
重い処理のかなりの部分が、シンプルだが強力な HTML 属性ひとつで片付くのに、意外とこれを知っている開発者は多くないようだ
かなり昔からある機能
Writely はのちに Google Docs になったスタートアップで、創業者の一人として言っている
残りの90%は、ブラウザごとにおかしな contenteditable 実装バグが違っていて、編集内容を正しく同期するために書かなければならなかったバックエンドコードだった :-)
ただし、(1) WP のスタイリングがあまりに面倒で保守したくなかった、(2) プラグイン機能や WP のアップグレードに依存したくなかった、(3) アクセス権限の異なる人たちが同じページの別々の部分を編集できるようにしたかったが、たいていの CMS では実質的に不可能だった
そこで contenteditable と TinyMCE だけを基に CMS をほぼ一から作り、編集可能な領域に該当するタグを付けた。もちろん保存前には、誰が何を編集できるかをバックエンドで検査する
クライアントやスタッフがログインすると、自分に権限のあるページ領域だけをその場で編集でき、CMS は編集可能な部分に点線の枠を表示する。フォントと色は TinyMCE の設定に保存してあるので、HTML を探し回ったり触ったりする必要はない。望めば直接触ることもできる
クライアント側から見ると、かなり魔法のように感じられる。変更後の見た目を確認するために別の編集ページへ行く必要がなく、ページ上でインプレース編集して保存すればすぐ公開されるからだ
これらのサイトの大半は5〜10年たった今も稼働しており、こちら側の保守はほとんど必要ない
https://news.ycombinator.com/item?id=43179649
contenteditable="true"を入れて、PDF エディタを作ったことがある20年前にもこれで作業していた気がする
ContentEditable は2000年に IE 5.5 で初めて導入され、2007年には主要ブラウザすべてで使えるようになっていた
とても気に入ったし、ソースを見るとピュア JavaScriptで書かれているところがさらにいい
最近は、ライブラリやフレームワークなしでもかなりインタラクティブな Web アプリを作れるという点が過小評価されている
シンプルなローカル Web アプリを単一の HTML ページにするというアイデアも本当にいい。以前、子どもと科学館に行ったときに簡単なストップモーションアニメーターを使ったことがあり、似たような Web アプリを作って単一の HTML ファイルとして子どものノートPCにコピーしてあげたら、インターネットなしでも使えた
ただ、自分はピュア JavaScript を直接書くのが面倒だったので React とバンドラーで作り、成果物は単一の HTML ファイルにまとめた。いつか Show HN に投稿するかもしれない
普通のピュア JavaScript とまともな腕があれば、ほとんどすべてをよりすっきり、保守しやすく作れる
何十年も他人が作ったものを保守してきて思うが、賢い人が作ったばかみたいに単純な設計は、他の組み合わせに勝る
よくできている
ローカルディスクからブラウザでページを開いたときは自動的に編集モードになり、誰かの Web サイトに公開されてパブリック Web からアクセスされたときは通常の読み取り専用ビューになるよう、動作を変えることも検討に値する。アドレスが http/https かどうかを確認すればよい
もちろん、編集モードでも見られるように、クエリ文字列パラメータやマジック URL フラグメントのような回避手段は必要だ
また、特定のドメインや URL プレフィックスには例外を設けられるべきだ。デフォルトを keepworking.github.io または <https://keepworking.github.io/nash/> にして、そのサイトでも編集モードが有効になるようにすれば、デモのために別途作業する必要がなくなる
この例外をユーザーが変更できるとなおよい。たとえば、他の人も1つ目のトリックなしで同じ動作を得られる
個人的には素晴らしいので、今の方式のまま残してほしい
https://rpdillon.net/redbean-tiddlywiki-saver.html を使えば、「本物の」保存ができる自己完結型のポータブルアプリにできる
そうすれば、必要なときに個人用ブックマークを持てる機能にずっと近づく
いいね。このアイデアと TiddlyWiki に触れた以前の議論があった
https://news.ycombinator.com/item?id=43179649
ブラウザがローカル Web アプリをもっとしっかりサポートしてくれたらいいのに
ローカルファイルが永続ストレージに簡単にアクセスできれば、すばやく簡単な GUI アプリに多くの機会が開ける。実質的には Electron の逆方向だ
すばらしい。WebサイトのJavaScript部分を実際のHTMLの外に書くことに慣れすぎていたせいか、初めて見たときは「わあ、これをHTMLだけでできるなんて不思議だ」と思った
でもソースを見ると、普通の
scriptタグの中にJavaScriptが入っていて、そういうこともできるという事実を思い出した私たちが毎日見ている画面の大半、コードエディタでさえ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/