Comments 17
Спасибо за материал! Легкий и занятный гайд
Ваш сайт наверное упал :)
Не понимаю, зачем нужны какие-то специальные утилиты для генерации статической же страницы. Открываешь в Vim и пишешь html.
Наверное, если клепаешь сайты по нескольку штук в день
Полагаю, человек умеющий в vim, не особо нуждается в помощи :) Впрочем, это всё равно не избавляет от возможности сэкономить время, воспользовавшись готовым инструментом, или уже готовыми результатами в виде собранных пакетов.
Поясню свою мысль. Что такое сайт -- это, в конечном счёте, описание того, что я хочу получить на каком-то языке. И у меня есть варианты:
учить какой-то новый непонятный язык (файл конфига, не важно) одной программы нужной чтобы решить ровно одну задачу (генерацию страницы для ошибок);
использовать общепринятый и известный мне язык, который в силу разных нужд так или иначе знать будешь (html).
И самое главное, если в пункте 1 нужно что-то не предусмотренное автором -- финиш. Всё равно идёшь в пункт 2.
Резюмируя: если есть возможность использовать общепринятые, стандартные языки, протоколы, форматы данных -- нужно именно это и делать, а не изобретать какие-то самоделки, которые сразу превращаются в китайскую грамоту. Причин почему так -- масса. И человеческие, и компьютерные (автор перестанет через 5 лет поддерживать свою программу, а какой-то простой текстовый редактор с html -- останутся и в новых совершенно других операционных системах).
И даже если стоит задача генерации статических страниц из шаблона, для этого опять же не нужна специальная программа. Достаточно любого общеупотребительного макропроцессора. Хоть C-препроцессор, хоть m4, хоть микрософтовский T4, хоть макропроцессор рализованный средствами скриптового ЯВУ (подстановка переменных и функций в HERE-документы в bash, python, в Tcl шикарный макропроцессор). Хотя последнее уже не очень, так как опять же требует обучения (нет чётких правил, нет документации).
Хотя на мой взгляд для HTML лучшим вариантом генерации является вообще XSLT. Т.е. шаблоны делаются на XML (XHTML), входные данные подготавливаются как xml или текстовые файлы и трансформируются каким-нибудь xsltproc в простейшем случае, или saxon в сложном (XSLT 2.0), в результирующий HTML. XSLT вообще это технология которую часто незаслуженно забывают.
PS: Авторский node.js, а проще говоря Javascript тоже на самом-то деле не самая плохая идея. Работа с html-шаблонами через DOM-представление вполне себе широко известный и стандартный подход. Это значительно лучше, например, чем скрипт на питоне который будет через printf формировать результат. Однако сам node.js -- несколько сомнительная технология. Т.к. часто не работает без подключения к интернету (нужно скачать 100500 внешних зависимостей из сомнительных источников).
PPS: Но вообще если вспоминать JS, то непонятно зачем там генерировать статические страницы. Достаточно одной на все случаи жизни. В которой будет и шаблон и скрипт же, который на ходу из шаблона сделает что нужно. Да, в браузере может не быть Javascript (но что сейчас в таком браузере можно увидеть???) Да в конце концов шаблон можно сделать на CSS и без JS. И параметризовать его через SSI (Server Side Includes) в одном единственном месте. А если у кого-то lynx, то проще вообще ничего не делать и пользоваться стандартными кодами без красивых шаблонов.
Кастомизация страниц ошибок - это не что-то обязательное, без чего сайт не будет работать. Данная утилита предоставляет возможность улучшить юзабилити сайта, но не заставляет это делать. В то же время, даже при наличии желания, она вовсе не требует её использования, т.к. можно использовать уже готовую сборку, и не думать обо всех сложностях с Нодой, пакетами и т.п.
Что касается XSLT, то от себя лично могу сказать что опыт взаимодействия с этой технологией был скорее отрицательным: одна лишь отладка шаблонов чего стоила. Ну и это как ни крути, но дополнительная прослойка над HTML. А вообще современная веб-разработка - это вполне устоявшийся стек, где JS, HTML и CSS во главе. Да, мир JS-разработки, в каком-то смысле, усложнен NPM (и прочими пакетными менеджерами), но это текущая реальность с которой сталкивается любой веб-разработчик.
Касательно SSI соглашусь отчасти. Сам, порою, с теплотой вспоминаю эту технологию, однако, сравнивая статичный HTML и HTML+SSI(+JS), то выбор кажется очевидным. Ну и опять же: данный инструмент - это лишь возможность, а не обязательство. Тот, кому это не требуется, найдет другое решение, или будет довольствоваться тем, что даётся веб-серверами из коробки.
В любом случае спасибо за развернутый комментарий и ностальгические воспоминания о технологиях прошлого :)
Сейчас я побегу скачивать готовую сборку на боевой сервер! А завтра там раз -- и Cлaвa Укpaiнe поперёк экрана. И не потому, что автор верный последователь идей Бaндepы, а потому, что у него неосмотрительно npm подтянул какое-то непотребство через зависимость зависимостей одной из зависимостей.
XSLT это не прслойка, а ДЕКЛАРАТИВНЫЙ язык программирования. Много лучший для своих задач, чем типичные императивные ЯВУ. Потому, что на императивном ЯВУ сколько-нибудь сложный аналог этих шаблонов превращается в изобилующее багами макаронное месиво. Это примерно как сравнивать языки со строгой типизацией и скриптовые языки где всё есть строка. На последних можно быстро начать, но так же быстро погрязнуть.
Не называл бы SSI и вообще серверную генерацию страниц технологией прошлого. Скорей, увы, наоборот. Это и есть настоящий WEB. А загрузка в браузер фактически программ для виртуальной машины, как сейчас принято -- это не WEB. Это чёрти что, которое невозможно сохранить, невозможно индексировать и т.д. и т.п. Это не WEB, это не то, что изобретал Тим Бернерс Ли. Это скорей прошлое. Это та же система MINITEL но на современной базе. WEB -- это общедоступная, публичная база знаний. Всемирная библиотека. А современный интернет превратился в набор серверов принадлежащий поставщикам услуг, и набор аппликаций загружаемых с этих серверов в браузер пользователю. Две большие разницы. Начиная с того, что разные пользователи видят разное содержимое, часто дать ссылку невозможно, везде нужна авторизация и всё направлено не на публикацию знаний, а на доставку развлекательного контента и "монетизацию". :-(
Всё-таки не стоит обесценивать качество сборок, придумывая какие-то кейсы: в каждом пакете лишь несколько статичных текстовых файлов, для проверки которых нужно не более чем 5 минут. Что касается внезапности появление чего-либо, то, очевидно, нет никакой нужды подключаться к пайплайну сборки для получения свежих версий страниц.
ну и зачем пользователю число 404 на пол экрана?
Демо
Вот только в итоге 404 страница отдается со статусом 200. Не делайте так, это заметание проблемы "под ковёр". В мониторинге должен быть виден правильный статус.
Как кастомизировать стандартные страницы ошибок