FP Web Frameworks

lionet — 05.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.

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

Популярные посты:

• Архив