FP Web Frameworks

топ 100 блогов lionet05.01.2010 Получают славу и пиар какие-то странные сущности, под названием «веб-фреймворки для [строгих] функциональных языков».

Вот, например, один: http://dmzlj.livejournal.com/90669.html (ocsigen / eliom). Подобные есть и для Хаскеля.

В чём с ними проблема? В том, что они подменяют цели.

Подобные фреймфорки ставят во главу угла валидность получающегося HTML результата. Да как же — на статическом языке достаточно просто сделать фреймфорк, который не допускает невалидный HTML по построению. Так как мы получаем эту самую валидность-по-построению в Haskell или OCaml почти задаром, а в других языках это сложновато, то эта фича тут же объявляется благой и используется в качестве галочки при сравнении с фреймворками для динамических языков.

Ориентирование на валидность HTML результата, надо сказать, не приносит никаких измеряемых бенефитов. Мы не можем даже говорить о том, что порождение гарантированного валидного контента устраняет какое-то количество ошибок времени выполнения! Все браузеры закрывают глаза на мелкие невалидности и продолжают функционировать как ни в чём не бывало даже при достаточно кривом HTML'е. XHTML, для которого валидность была жизненно важна, уже умер. Невалидность не является таким уж сильным источником проблем на практике, чтобы нужно было использовать тяжёлую артиллерию статически типизируемых языков! Мы явно отвлекаемся не на ту проблему.

Иногда подобные фреймворки заменяют привычность человеческого интерфейса на привычность механизма для программиста. Например, фреймворк и новый язык для веб-программирования Links (http://groups.inf.ed.ac.uk/links/), написанный соавтором Хаскеля, убивает понятие ЧПУ и передаёт состояние скрипта в продолжении, закодированном птичьим языком прямо в URL следующей страницы. Это даже комментировать не хочется — настолько нежизнеспособная конструкция получается для реальных применений. Хотелось бы думать, что пользователи игнорируют то, что у них в браузере в поле Location написано, а ссылками обмениваются через что-то типа digg или twitter. Но читаемость ссылок до сих пор важна, и с течением времени важность хорошо читаемой ссылки имеет тенденцию к повышению.

Что должен иметь развитый web framework в современных условиях?

1. Компоненты фреймворка должны быть ориентированы на то, чтобы быть модифицируемыми непрограммистом. Я не говорю о том, что непрограммист должен писать веб-сайты (это по факту невозможно даже в PHP — мало-мальски сложный веб сайт не имеет шаблонов для страниц, а максимум виджеты). Но либо мы генерируем чистый XML для сырого вывода и процессим его XSLT потом, который с некоторой натяжкой может считаться языком для непрограммистов. Либо мы должны «подхватывать» откуда-то виджеты, написанные на более-менее готовом HTML с вкраплениями простого (не тьюринг-полного) макроязыка, которые могут редактироваться «от балды» неспециалистом. Вариант, который предусматривает создание валидного HTML прямо «в хаскеле» вызывает неприятные рефлексы даже у хаскелистов. Hint: в ECMASCript внедрили first class XML: так лучше собирать сырой XML по кускам. Это почувствовали даже в eliom, реализовав на camlp4 костыль.

2. Сайт должен конфигурироваться и реконфигурироваться без остановки. Lisp рулит. ocaml/haskell сосут. PHP рулит. Erlang рулит. Perl сосёт.

3. Сайт должен собираться модульно, со слабыми связями между модулями. Центральный цикл (конфигурация) с перечислением используемых модулей — зло. Лежащие на диске отдельные файлы, представляющие собой куски функциональности — благо. Смотри пункт 2.

4. Сайт должен продолжать работать при наличии ошибок в модулях, подхватываемых динамически. Ну не подхватился какой-то модуль — вывели ошибку в лог, но продолжать шуршать обязаны.

5. Валидный по построению HTML — это решение несуществующей проблемы. Достаточно иметь более лёгкую гарантию: автоматическое html-кодирование сырых сущностей в момент, когда они становятся частью выходного XML. Это покрывает 95% действительно опасной невалидности.

6. ЧПУ должны быть легко достигаемы в рамках получающейся системы.

7. Система должна в принципе позволять масштабирование на несколько независимых компьютеров. Особенно страдают от проблемы с этим пунктом хаскелевские фреймворки — норовят состояние держать в памяти единственного процесса. Но состояние по сессиям должно быть либо на клиенте (в куках), либо в базе (на худой конец, в memcached). Это предусматривает какой-то слой работы с внешним хранилищем состояния.

Похоже, сейчас этим требованиям в существенной степени удовлетворяет только PHP.

Оставить комментарий

Архив записей в блогах:
Люблю иногда порыться в сети и вытащить на свет божий что-то этакое. Сегодня хочу показать один рекламный ролик. Посмотрите, как креативят наши рекламщики. ( Read more ... ...
Бузова заявилась на очередную нерелевантную премьеру, украсив башку бантом. Украсив -- это, конечно, громко сказано. Фото: Соцсети Не знаю, кем мнила себя гОленька -- возможно, молодой Ириной Понаровской -- когда напяливала на свою неумную голову эту громоздкую конструкцию. В ...
... Мне подают шашлык из бараньей печени — как и положено, в сетке из жира: блюдо популярно в Средней Азии, заказывают его часто... Готовят в Узбекистане обычно божественно, поскольку еда здесь попросту культ. Но шашлык не удался — он откровенно пережарен, пересушен, в нём ноль ...
По оценкам журнала «The Economist» около 3% от суммарного мирового загрязнения  атмосферы дают морские перевозки.  Три процента – это много или мало? Для сравнения: доля промышленности Германии в суммарной мировой эмиссии двуокиси углерода составляет 2,3%. Япония находится на ...
...