Чистая статика в вебе

И чем тебя не устраивает кэширование?

Ну есть же статические блоги. СМИ по идее могли бы использовать тот же Jekyll или аналогичный статик-генератор на NodeJS. Или я что-то не понимаю?

см. Nikola (сам юзаю, нравится), poet, Jekyll, тысячи их

О, что-то похожее. Хотя и ближе к каким-то CMS чем просто фреймворк

Он сам сервит контент? Просто nginx справлялся бы этим даже лучше наверное, он мог бы просто складывать в нужное место

Кеширование пусть останется, но в качестве минорной оптимизации и пусть будет полностью concern части nginx, а не критической частью, на которой держится вся производительность.

Бекенд при этом мог бы быть сколько угодно медленным, ненадежным и даже в одном экземпляре. Так как если он упадет, то damage минимален - нельзя запостить новую статью. Его переподымут и опять все ок. База - тоже.

Например на амазоне это вполне бы работало на одном микро-инстансе и большом S3. А то и на гитхабе хостить можно. Комбинация Openshift + Github Pages - совсем бесплатная получается.

С другой стороны при постинге новой статьи контент атомарно перегенерировался на серверах и это был бы concern фреймворка и ничего не нужно было явно инвалидировать в кешах.

кеш на диске — вот и все статика.

Чистая статика в вебе (комментарий)

nanoblogger ну или http://alexott.net/ru/writings/EmacsMuseMyPage.html

правда это не веб-фреймворки

потому-что кеширование решает эту проблему на 100% - можешь кешировать по самое неболуй и вот тебе будет та же статика, зачем собаке пятая нога

Вы изобрели джекил, октопресс и дискус. Поздравляю :)

Даже wordpress это умеет.

Почему в веб-фреймворках не разработана инфраструктура построения исключительно сгенерированых в статику сайтов?

Потому что невостребовано. Вебдваноль принёс динамический контент, а статика умерла за ненадобностью и неудобством использования.

да вообще весь веб исторически через жопу работает, в каждом аспекте :)

Нормальный Web 2.0 - как раз статика с клиенской шаблонизацией на JS + REST

Помимо все прочего, есть еще архитектурный подход CQRS + Event Sourcing, где твои проекции (в другой терминологии: вьюшки) могут вместо складывания в базы данных генерировать заранее подготовленную статику сразу на просмотр. Довольно высокий порог вхождения, но штука интересная.

REST уже как-то не вписывается в понятие «статика»

А зачем? Я не понимаю что тебе мешает просто билдить html?

Спрос рождает предложение. 99 % пользователям фреймворков они нужны для создания именно динамических сайтов.

И кстати, сёрвить закэшированный контент нгинксом из мемкэша/редиса или варнишем, скорее всего, выйдет быстрее, чем тупо статику с файловой системы.

Почему в веб-фреймворках не разработана инфраструктура построения исключительно сгенерированых в статику сайтов?

потому, что есть такие фреймворки, как полностью стат. с перегенерацией типа hakyll, jekyll так и поддержка в других, напр. в yesod.

http://werc.cat-v.org/

CQRS + Event Sourcing

Я тут главный нытик на эту тему.

Лучшая СУБД для CQRS+Event Sourcing.

Современное распределенное приложение.

:D

как раз статика с клиенской шаблонизацией на JS + REST

Ну и как это реализовать по твоей схеме?

Как все реализуют. А может вопрос как-то поконкретнее?

Ну так там html редко меняется и для него cms не используется. Т.е. твоя схема не нужна просто.

Почему в веб-фреймворках не разработана инфраструктура построения исключительно сгенерированых в статику сайтов?

а нафига плодить лишние сущности? это легко делается с помощью wget -r

например, http://mars.51t.ru http://complex.51t.ru http://enjoy.51t.ru это сайты на bottle.py, которые с помощью wget -r превратились в набор html-сайтов.

это сайты на bottle.py, которые с помощью wget -r превратились в набор html-сайтов.

А если бы они были на php то не превратились бы в набор html файлов чтоли?

в php роуты определяются веб-сервером. т.е., нужен ещё и вебсервер и его настройка. а так - запустил, нагерерировал, с помощью scp залил - у меня это shell-скрипт может выполнять.

Да ты балбес оказывается.

Почему в веб-фреймворках не разработана инфраструктура построения исключительно сгенерированых в статику сайтов?

Мой первый вариант «генерилки сайтов» (тогда термина «фреймворк» не знали, тем более — CMS и т.п.) в ~1998-м так и работал. Были HTML-шаблоны, были plain-text файлы с контентом (на своей самопальной разметке). Запускалась программка, в выхлопе — готовое html-дерево для аплоада на FTP. Сперва программка была на QBasic, потом на Forth, потом на Perl в офлайне, потом на Perl в онлайне, потом на PHP. Так до нынешнего фреймворка и доехало. И, да, при желании на нём спокойно можно генерировать чистый HTML :) Но проку мало, голые статические сайты сегодня мало интересны. Обычно нужна динамика, персонализация страниц и т.п. Так что я как и большинство подобных решений, использую либо чистую динамику, либо статическое кеширование + динамическую персонализацию через JS.

сёрвить закэшированный контент нгинксом из мемкэша/редиса или варнишем, скорее всего, выйдет быстрее, чем тупо статику с файловой системы

Статика с файловой системы сразу осядет в кеше и снова будет быстрее, чем дёргание результата из мемкеша/редиса из-за оверхеда на вызовы последних :)

это ты балбес, оказывается. оба комментария вообще не в тему.

нет ты

На Hackers News пробегало: http://staticsitegenerators.net/