но не намного лучше Django Template Engine

У DTL девиз — создай по кастомному тегу на каждый пук! Он конечно с каждым релизом приближаются к mako/jinja, но еще ползти лет 10. Джанго админка такая дубовая в первую очередь из за негибкости шаблонного движка.

Ну так в куках хранят только пары: key=value. Set-cookie это просто действие установки такой пары. Про пробросить запрос ничего не понял - куда его пробрасывать? От одного бэкэнд модуля к другому на этом же бэкенде? Берёшь, делаешь токен, сохраняешь в кукис, и по токену вытаскивай из бд то, что ты хочешь делать с клиентом или его данными. К тому же, это всё реализовано в абстракции «сесии», к чему такой изврат?)

Я обычно пишу две админки. Одну на джанге для управлением основными users, group, etc. И вторую для клиентов сервиса, где они могут менять/создавать свои профили и т.п. херню по типу своей страницы в контакте. Вторая админка у меня гораздо более навороченная, и вылизывается чуть ли не 1/3 времени написания всего приложения/сайта. Ну, а первую (джанга админ панель) я не кастомизирую, смысла в этом не вижу...

Вот!

Отсюда простой вывод.

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

Если делаешь свой проект, то лучше без фрейвока.

А по мне так, если пишешь один - то ресурсы ограничены - начинать надо с прототипа, и его лучше писать на фреймверке; благо, сейчас куча микрофреймворков, даже на том же php есть годные микрофреймворки, просто такие решения (и многие php'ники даже не в курсе) мало-популярны, т.к. клепают сайтики на джумла и т.п.

Микрофреймворки, кстати, может и поадекватней полновесных. Но я их не щупал до сих пор, только слышал.

даже на том же php есть годные микрофреймворки, просто такие решения (и многие php'ники даже не в курсе)

Но я их не щупал до сих пор, только слышал.

а этот тип - тот самый парень. Не слышал не видел не хотел.

Ещё лет 5 и Django дорастёт до уровня Rails 3.x, главное только ждать и помнить, что «питон быстрый, аминь»! :)

пользовал обе, в чем ей расти и зачем? asset pipeline нету изкаробки, что еще?

И что предлагается взамен?

нинужно

Ты кто такой и почему нам должно быть интересно что тебе не нужно?
Никто не интересовался у тебя, нужно тебе это или нет.

Но ведь Rails есть

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

Вот ты фантазёр!

по невменяемости и неудобности? сомневаюсь, что это вообще реально :)

Рельсовики все больше похожи на бсдишников, гальванизируют все активнее и активнее.

Нечего, просто констатирую факт, ерланг конечно очень оригинальная штука, надеюсь к нему таки допилят jit.

Но ведь Rails есть

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

А вот питону, кстати, вряд ли это грозит, потому что питон штука универсальная и используется не только в web. Поэтому даже если и случится так что популярность Django упадёт, то только потому что будет более интересный фреймворк на Питоне. Тем более их и сейчас несколько (Фласк и пр.).

О да это видно по быстроте с какой люди мигрировали с питона 2 на 3

О да это видно по быстроте с какой люди мигрировали с питона 2 на 3

А причём тут Питон 3 и миграция на него?

Всё порываюсь осилить джанго, да руки не доходят.

Посмотри и попробуй (я сам php бросил давно), но мне понравился вот этот:
flightphp.com/
https://github.com/mikecao/flight

Тогда он тебе точно не нужен :-) лучше flask или web2py для новичков.

Ну, если только по количеству дыр, всё остальное есть как отдельные приложения/модули в pip или github.

Да народ фапает на Rails тупо по двум штукам:
1. Типа крутой скаффолдинг. Когда командой в консольке генеришь кучу кода, тестинг и прочее. Скаффолдингом же создаёшь модель и прочее. Короче, скафолдинг помогает новичкам нереально.
2. ActiveRecord из Rails. Типа там всё удобно, не нужен SQL и вообще, забудь о базах навсегда, базы пугают многих, особенно народ кайфует после перехода с php, кстати тот же scafolding не хило заточен под activerecord, т.е. новичек пищит от радости, что кода почти не нужно писать.
Короче, это всё даёт возможность писать гостевухи, магазинчики, различные голосовалки, сайты-каталоги-топ (типа топ майнкрафт серверов), за пару тройку часов, что неимоверно доставляет, поэтому любовь к Rails у хипстерят на лицо.

Не знаю, не знаю... Ну тоже ведь - сборище тривиального функционала. Например:

Flight::route('/', function(){ echo 'hello world!'; });

Нафига так делать, чем это лучше? Это же не быстрее: в начале каждого запроса делаются лишние действия - заново устанавливаются все функции ответа. Это не проще и не понятней: 1 функция с if'ами и регэкспами займёт столько же кода. Это не гибче: урлы только парсятся, но не генерятся, и их точно так же нужно хардкодить в шаблонах (в отличие от этого я себе например запилил некий «диспетчер», который разбирает и составляет урлы в обе стороны по одному и тому же описанию, причём делает это быстро, т.к. описание компилится в пхп код).

Типа крутой скаффолдинг

небольшой плюс в этом есть, но далеко не киллерфича

ActiveRecord из Rails

ничем не лучше django orm

Короче, это всё даёт возможность писать гостевухи, магазинчики, различные голосовалки, сайты-каталоги-топ

на джанге тоже пишется, за то же время

The WSGI protocol can not support websockets

в каком месте ты это вычитал, дурилка картонная?

Тебя забанили в Google, о наисветлейший?

народ фапает совсем не по этому. а по количеству и качеству гемов доступных для рельс. Это гораздо удобней чем прикручивать их к sinatra.

Тебя забанили в Google, о наисветлейший?

я так понимаю, это относится к вопросу о несовместимости WSGI и WebSockets. хорошо, поставим вопрос так. в каком месте WSGI конфликтует с WebSockets?

я лично не занимался вопросами реализации WebSockets поверх WSGI, но коллеги вполне успешно используют комбинацию «обычного» WSGI-приложения с WebSockets именно благодаря гибкости WSGI.

Тебя забанили в Google, о наисветлейший?

да, если у вас возникнут сомнения по поводу моей компетенции в отношении WSGI, я - автор https://pypi.python.org/pypi/gevent-fastcgi.

Держите наркомана!

Отлично, тогда вам точно стоит почитать автора django-websocket:

https://pypi.python.org/pypi/django-websocket

Disclaimer (what you should know when using django-websocket)

BIG FAT DISCLAIMER - right at the moment its technically NOT possible in any way to use a websocket with WSGI. This is a known issue but cannot be worked around in a clean way due to some design decision that were made while the WSGI stadard was written. At this time things like Websockets etc. didn't exist and were not predictable.

However there are thoughts to extend the WSGI standard to make Websockets possible. Read here for a discussion on the Paste Users mailing list.

But not only WSGI is the limiting factor. Django itself was designed around a simple request to response scenario without Websockets in mind. This also means that providing a standard conform websocket implemention is not possible right now for django. However it works somehow in a not-so pretty way. So be aware that tcp sockets might get tortured while using django-websocket.

https://github.com/jrief/django-websocket-redis/blob/master/docs/introduction...

Due to this workflow, it is almost impossible to add support for long term connections, such as websockets, on top of the WSGI protocol specification. Therefore most websocket implementations go for another approach. The websocket connection is controlled by a service running side by side with the default application server. Here, a webserver with support for long term connections, dispatches the requests from the clients.

Отлично, тогда вам точно стоит почитать автора django-websocket

не надо родовые травмы django переводить на wsgi.

https://pypi.python.org/pypi/gevent-websocket/