Читатели в вебе получают HTML, но у нас есть довольно много опций, как организовать создание этого HTML, и не все из них хороши.
Можно использовать большие сервисы: твиттер, тумблер, фейсбук — я уже писал о том, чем это чревато. Если же брать сервисы поменьше, то они частенько умирают.
Зачастую можно успеть вытащить свои тексты и фотографии обратно, но если на посты кто-то давал ссылку — то она пропадёт.
Когда же у тебя есть контроль над ссылками, то можно поменять хостинг, движок, практически всё — и оставить ссылку рабочей.
Тема живучести ссылок появилась не вчера — ещё в 1998 году
Тим Бернерс-Ли, создатель веба, писал о том, что крутые URI не меняются
(там же, в частности, не рекомендуют использовать урлы с .html на конце).
Но сегодня я хочу обратить внимание на момент, который сильно упрощает миграцию между технологиями, — хранение постов в файлах, в маркдауне.
Написать блог, который достаёт посты из базы, несложно. В целом, это первое, что делают люди, когда начинают изучать фреймворк Ruby on Rails. Но привязывая свой контент к базе данных, мы заставляем себя поддерживать эту базу данных и на сервере — а поддерживать базу данных несколько сложнее, чем написать пару SQL-запросов.
На вики Индивеба это называют DBA tax, так сказать, налог на БД: то время и силы, которые ты тратишь на настройку, поддержку, бэкапы, обновления базы данных вместо того, чтобы писать посты и радоваться жизни. Не все считают это такой уж проблемой, и вполне можно делать свой сайт как захочется — но в варианте без БД меньше движущихся частей.
Но есть вариант не писать HTML-страницы целиком, и в то же время не возиться с базами данных: генераторы статических сайтов. Их существует огромное количество, но самый прекрасный, на мой взгляд, вариант — это Eleventy (11ty).
Он написан на джаваскрипте, поэтому его легко поставить через npm,
и с ним легко начать работу: если у вас есть просто набор файлов, то вы, по факту,
уже можете использовать 11ty, и конвертировать файлы по мере необходимости, вынося,
например, общие части разметки в шаблоны. Большая Миграция, где нужно переделывать
все файлы, не нужна.
На 11ty делают новую версию сайта Веб-стандартов. В качестве другого примера можно посмотреть на репозиторий подкаста LP.
Но практически любой генератор статических сайтов поддерживает формат Markdown, который придумал Джон Грубер в нулевых (markdown это игра слов про markup, разметку): он упрощает написание текстов, которые превратятся в HTML.
Почему Маркдаун, а не reStructured Text, или вовсе просто HTML? Дело в том, что HTML на телефоне набирать попросту неудобно, а у Маркдауна хорошая поддержка на iOS: существует много программ, от Drafts до Ulysses.
(Во многом, я полагаю, из-за авторитета Грубера в сообществе разработчиков под платформы Apple. Если знаете хорошие приложения для маркдауна под Андроид — дайте знать.)
Таким образом можно писать черновик поста в одном из таких приложений на ходу, а потом уже опубликовать на своём сайте. Маркдаун поддерживается на многих сайтах для гиков, навроде Гитхаба и Стэковерфлоу, но когда публикуешь у себя, то внутрь маркдауна можно добавить любой HTML.
Простые текстовые файлы с маркдауном легко хранить — у меня не осталось бэкапов от многих вариаций «да щас я блог напишу на кложуре», но полным-полно текстовых файлов, которые я постепенно буду добавлять обратно на этот сайт (часть из них осталась вживых благодаря Дропбоксу).
С простыми файлами просто жить.
Но как же тогда поддержать Micropub на своём статическом сайте? Нужно, чтобы где-то был микропаб-сервер, который будет принимать новые посты, и перезапускать генератор статики.
Как я уже писал, я разрабатываю и пробую на себе Friendware.
В нём это решается двумя программами: одна из них, micropubd,
принимает посты и кладёт их в текстовые файлы,
а вторая, onchanged, следит за изменениями в папке с файлами
и запускает скрипт build.sh, в котором я вызываю 11ty. Веб-сервер
раздаёт сайт из папки _site, куда 11ty складывает результат по умолчанию.
Так нельзя сделать на хостинге, где можно только размещать статические файлы (например, Github Pages), зато можно реализовать при помощи гита и Github Actions (это на случай, если хотелось с ними поиграть, но всё как-то повода не было).
Если хранить контент в системо-независимом формате, то сохранить его надолго становится гораздо проще.