Хотеть фреймворк на tcl с преферансом и поэтессами

Объясните почему tcl для этого не подходит.

потому что к tcl никто близко не подхродит, боятся =)
[moderator]GoTo Talks[/moderator]

http://www.aolserver.com/ уже смотрел?

Пусть боятся. То что им никто не будет пользоваться меня не очень волнует. Я же даже тэг «ненужно» поставил.

Конечно. Плюс есть еще сервак целиком на tcl. Но хочется универсального.

Неприспособленность к крупным проектам - модули, пакеты (зависимости), мутные объектных модели с еще более мутной сборкой мусора для них.

А что ты имеешь ввиду под словом «фреймворк»? Если, например, твой бэк-енд будет выплевывать в memcache JSON представление нужных тебе объектов, это как, веб-фреймворк или еще нет?

Какие такие зависимости? Объектная модель не главное. Я вообще не уверен что ООП такая уж хорошая идея для вэб фреймворка, хотя не объектных-то и не видел...

Хороший вопрос. Тут вобщем-то он упрощается до «чего мы хотим от идеального фреймворка?»

Ну наверное модульности в идеале такой, что модули вообще друг от друга не зависят. Простоты. Да такой, чтобы для начала работы не нужно было вообще ничего читать. Чтобы не надо было вникать в ORM, xsl и прочую ... нутыпонел.

Это по свойствам, а по функционалу:
Модуль роутинга (ЧПУ там всякое и такие дела)
Модуль для работы с http
Шаблонизатор (предельно простой - в идеале я беру и верстаю страничку на html и это и есть шаблон)
Некоторая модель данных + API для работы с ней
Управление сессиями
Пользователи и списки доступа
Модуль отправки, в идеале такой, который сможет отправлять данные по мере готовности без ущерба для всяких кэлбэков разумеется

Модуль роутинга

Нахера? Тебе рутинга на клиенте не хватит?

Модуль для работы с http

Это еще зачем? Все-равно твою унылую реализацию придется прикрывать реверс-прокси, так не лучше ли запилить более тесные и продуктивные отношения с любым серьезным веб-сервером?

Шаблонизатор

Б-г-г-г! А на клиенте значит уже не кошерно?

Некоторая модель данных + API для работы с ней

Любая хрень с REST-интерфейсом. Причем спектр решений предельно широк.

Управление сессиями

Если веб-фреймворк сугубо экстранетовский, то аутентификация по клиентским сертификатам.

Пользователи и списки доступа

То же самое.

Модуль отправки

Websocket API.

На каком клиенте? Речь о многоцелевом веб фреймворке для запиливания домашних страничек каких нибудь федеральных торговых сетей или какого-нибудь очредного государственного аппендикса.

На каком клиенте?

Ну, для веб-фреймворка клиентом является как бы веб-браузер.

Зачем держать унылый HTML шаблонизатор на стороне сервера, когда на стороне клиента намного удобнее и быстрее манипулировать DOM? Зачем заниматься передачей кривого HTML с набором костылей под каждый браузер, когда можно передавать JSON? Зачем нагружать сервер и каналы унылыми HTML-простынями, когда DOM легко собирается по частям с помощью разумного использования статики, кеширования (в т.ч. и на стороне клиента), и динамически сгенерированных данных?

Мы опять возвращаемся к вопросу «что считать веб-фреймворком, а что — нет».

Для федеральных торговых сетей нужны высокоинтегрированные CMSки. Для данной предметной области намного важнее инфраструктурная составляющая, чем конкретный веб-фреймворк.

Для государственных аппендиксов стоит посмотреть в сторону статической генерации.

http://www.openacs.org/

под «веб-фреймворк» все сейчас подразумевают «эквивалент рельс на %lang_name%»

на каком в задницу клиенте? Написать всё на JS что ли предлагаешь? Шаблоны на EJS? Батенька, у вас JS головного мозга, не следует это запускать, иначе следующим шагом будет node.js на сервере и принудительная госпитализация.

Зачем

потому что все браузеры работают чуточку по-разному. С меня хватает недельной отладки скрипта для поддержки разных версий IE, чтобы уже взвыть на луну) А на сервере ты что хочешь, то и поставил. Ладно, на шаред-хостинге не «что хочешь» а какое-нибудь говно мамонта которое некоторые называют «стабильность», но хотя бы одно и то же для всех людей.

Выковырял tclsh из убунты. Кинул в ~/bin на шареде. Работает однако.

ты хотел сказать джанги, вероятно

С меня хватает недельной отладки скрипта для поддержки разных версий IE

Так и запишем: был жестоко искусан IE. Но тут уж вы, батенька, сами... Сами... Нужно было у заказчика такие вещи уточнять, чтобы потом не было мучительно больно.

Кроме того, апреле следующего года настает официальный IE6/7/8-капец (вместе с локальным вендокапцом). Так что не в тему, тем более гугл уже не поддерживает.

Батенька, у вас JS головного мозга

Ха! JS головного мозга! Насморк — не болезнь. Вот haskell головного мозга — это болезнь.

Кроме того, JS — идеологически верен. Ему бы только синтаксис другой, со скобочками. Кстати, смотрел тут намедни один веб-фреймворк и увидел прекрасное:

blah(blah).then(function(ctx){
//blah-blah
}).then(function(ctx){
//blah-blah
}).then(...

Так, глядишь, и додумаются наконец.

Кроме того, либо учи JS, либо не лезь в веб...