Недавно Макс Ищенко попросил меня добавить публичности циклу статей Сергея Щетинина на DOU, посвященному веб-разработке на Питоне "без" фреймворков: часть 1, часть 2, часть 3.
Но конечно, просто так ссылок я давать не хочу: надо либо хвалить, либо ругать. Здесь получилось последнее, причем, простите, ругаться я буду громко и совсем не нежно. Гр-р-р... 8-[==]
Начну с того, что это первая статья, где я встретил упоминание Zope и Django в одном ряду. Я слабо понимаю, что между ними общего, но зато я, кажется, понимаю, откуда у статьи растут ноги...
Знаете, я, вроде, не старый еще, но этот паттерн видел уже много раз, и он успел мне приесться. "Посмотрите на этот жуткий огромный ворох кода! Он такой большой, сложный, медленный, монструозный, непроходимый... Всего этого не нужно, ведь можно все сделать гораздо проще". После этого идет пример кода сложности "Hello World!" из пары строк. Дальше пример начинает развиваться, обрастает мясом, которое, по задумке автора, должно показывать, как вот так просто можно написать все что угодно. На самом деле оно показывает, что автор собирается самостоятельно пройти по тем же самым проблемам, с которыми столкнулись авторы "больших и сложных" фреймворков при развитии их с уровня "Hello World!" до чего-то, чем можно даже пользоваться.
Но, впрочем, я забегаю вперед... Если начинать по порядку, то мое тотальное несогласие с циклом статей Сергея сводится к двум большим частям: архитектурной и практической.
Архитектурно
Многие питонисты уже какое-то время активно пытаются строить "чистые" фреймворки, используя в качестве клея компонентов... WSGI! Нет, серьезно — WSGI!!! Простой протокол присоединения питоньего кода к веб-серверу пытаются повернуть так, чтобы он задавал, ни много ни мало, архитектуру приложения. Ребята, так не получится. В WSGI элементарно нет средств для связи компонентов фреймворка. И если вы придумываете над WSGI какие-то свои протоколы и расширения (Paste тот же), то это уже не тот самый WSGI, а это реально ваш собственный yet another фреймворк, от создания которого вы хотели уйти.
И если вы сейчас думаете про слово "middleware", то почитайте, пожалуйста (пожалуйста, целиком) разъяснения Филиппа Эби — автора WSGI — для чего middleware подходит, а для чего нет.
Практически
Вторая и третья часть цикла — про WebOb, некую библиотеку, которая является крайне показательным случаем всего того, о чем я говорю.
В ней, например, присутствует некий полезный код, который облегчает разбор HTTP-запросов и ответов. Им, если верить Сергею, удобно пользоваться (это совершенно без иронии). Но чего в ней нет — это присущего большим фреймворкам архитектурного каркаса (разбора URL'ов, разделения логики на уровни по MVC-модели, шаблонной системы).
Простота? Ни фига... Если вы хотите уйти с уровня "Hello World!", вам все равно придется все это создать руками. Например, Сергей описывает во второй части простой пример с функцией forum_app, в которой в десятке строк императивной логики разбираются два вида URL'ов для некого форума. У меня в Cicero — не самом фичастом форуме — таких видов URL'ов под 30 штук. Разбор их "в лоб" цепочкой if'ов будет выглядеть убойно нечитаемо. Поэтому, да, придется или в муках выдумывать собственную систему, которая будет ничем не лучше вылизанных практикой существующих, либо — сюрприз — взять существующую.
Слышали хлопок? Это магическим образом мы заменили изучение одного большого и сложного фреймворка на изучение многих маленьких библиотек! Правда в этом нет ничего хорошего, потому что изучать концептуально целостную структуру всегда проще, чем множество ничем непохожих.
Насчет вылизанности существующих решений. Например в Джанге есть система организации редиректов с устаревших URL'ов на новые при изменении их вида. Вы серьезно хотите заниматься такими нудными вещами в вашем проекте вручную? Или серьезно хотите привязать себя к одному веб-серверу с его rewrite'ами только из-за схемы URL'ов?
Дальше больше. Даже та функциональность, которая в маленьком молодом фреймворке есть, оказывается далеко не такой отлаженной, как такая же в большом и старом.
Например, в третьей статье Сергей сетует на то, что браузеры не передают в HTTP-запросах кодировку данных этого самого запроса, и, ничтоже сумяшеся, хардкодит ее в utf-8. Что произойдет, если клиент пришлет невалидную utf-8 строку? Система упадет. А в Джанге на этот случай есть некая эвристика, по которой кодировка пытается подобраться несколькими способами в порядке уменьшения логичности вплоть до какого-то, уже не помню, дефолта, но процесс в любом случае не падает, и ваши данные вы получите. Скажите мне, в чем ценность придумывать все это еще раз в своем проекте?
В итоге, вывод мой из всего этого такой. Многие умные люди пользуются веб-фреймворками не потому, что "гоняются за иллюзорным «лучшим»". Это чисто прагматическое признание того факта, что предметная область довольно сложна, и в ней лучше работать коллективно и последовательно. Другие подходы тут не работают.
Комментарии: 25 (особо ценных: 2)
Покойся с миром, Turbogears...
это я про вот это :-)
+\1
ИМХО, вдумчивое чтение кода существующих фрэймворков хорошо лечит от иллюзий "да это все так просто, я за один вечер сделаю". Достаточно увидеть, как много тонкостей и особых случаев нужно учесть и обработать, и сразу понимаешь, насколько велик объем работы требуемой для воспроизведения всего этого даже в урезанном формате.
Я всегда считал, что люди агитирующие против фреймворков в пользу анти-фреймворков или вообще raw-code, хотят тем самым заработать себе дешевую популярность, идя против общего ветра.
Как правильно ты заметил, даже умные люди используют фреймворки, а значит польза и удобство в них есть.
Иван, в самой первой статье про Django вы уже писали
По-моему, лучше и не скажешь! Я понимаю, когда люди пишут всё это, мучаются, осознают рано или поздно, что зря потратили время, создав ещё один велосипед, но куда худшего качества... так бывает со многими разработчиками. И со мной бывало. Но писать статьи, и учить остальных делать то же самое - неправильно. Спасибо за вашу критику! К ней, я уверен, прислушиваются :)
Особо ценный комментарий
Ох, что-то соскучился я по дешёвой популярности... пора, пора сходить против ветра! :) Иван пишет всё правильно. Спорить здесь не с чем. Но можно дополнить.
Все существующие фреймворки когда-то были написаны вот такими ребятами. Если бы все рассуждали так, как написано в статье - у нас был бы один фреймворк, тот, который бы написали первым.
Что касается "Посмотрите на … можно все сделать гораздо проще". Люди вообще, и программисты в частности, к сожалению, обожают всё переусложнять. Поэтому в большинстве случаев действительно можно сделать проще. И нужно! Но, к сожалению, в большинстве случаев проще сделать не получается... а получается полная фигня, описанная в статье. Зато в остальных случаях получаются конфетки вроде OS Inferno. Так что в самом подходе ничего плохого или неправильного нет. Просто за эту работу зачастую хватаются те, кто не в состоянии её сделать - отсюда и сложившееся отрицательное отношение к таким попыткам.
Без глубинного понимания системы хорошим программистом стать невозможно. А это понимание проще всего получить в процессе написания своей системы/фреймворка либо вычитывания чужого кода, при условии что этого кода вменяемое количество и он простой. А поскольку найти такой чужой код допольно непросто, чаще встречаются как раз переусложнённые монстры, то писать своё - вполне адекватное решение. И сам научишься, и другим будет простой пример для изучения (пока ты его не развил до состояния такого же монстра, как и другие).
Так что есть минимум три веские причины пытаться разрабатывать свою "простую" систему: обучение; увеличение конкуренции и разнообразия таких систем (от которых выигрывают все, и в первую очередь те кто любят рассказать что свои фреймворки писать вредно и бессмысленно); ну и небольшой шанс действительно получить более простую и элегантную систему.
Я все-таки хочу внести еще небольшое разъяснение. WebOb пишет Йен Бикинг, которому в авторитете и уме не откажешь. Однако мне кажется, что и эта штука, и сам Paste для него — скорее эксперименты в духе "посмотрим, как сыграет такая концепция в целом". И все это действительно очень интересно — нащупать тот баланс между фичами и их отсутствием, который бы был как раз. Но пока, на мой скромный взгляд, равновато говорить о том, что это полноценный боевой инструмент.
Отвлекаясь от темы (со статьёй я согласен полностью), а чем Вас так рассердило упоминание Zope и Django в одном ряду? Если смотреть на Zope3, как на веб-фреймворк (как его в основном и используют), то он даже похож на django, хотя, конечно, принципы немного другие (компонентная архитектура, траверсинг объектов, вместо подключения правил разбора URL и т.п.).
Особо ценный комментарий
По теме велосипедостроения. :-)
+\1 подписываюсь :-)
Хух, спасибо за статью. Я как раз увлекся чтением того цикла и что-то у меня в мозгу начало переключаться...
Единственный смысл писать все самому вижу исключительно для образовательных целей (это я имею ввиду себя, бо на написание своего фреймворка при теперешних условиях ума у меня не хватит).
В общем спасибо, что еще раз подтвердили правильность моего увлечения Django.
В пух и прах.
А еще:
Других отзывов не стоило ожидать;) наверно 90% посетителей- джангисты, которые ничего кроме джанги не видят...
Себя к вебдевелоперам не отношу, но всеже... Джанга имхо нужна там, где она нужна) Есть ниша, в которую прекрасно вписываются антифреймворки аля web.py (другие глубоко не копал). По поводу отсутствия MVC как такового, что мешает самому создать такую архитектуру? я например привык создавать приложения со скелетоном типа (code.py, settings.py, templates/, app/model/, app/controllers/).А вот в джанге его (mvc) можно ли убрать ? по-моему будет проблемно;)
В нормальный антифреймворках диспатчеры таки есть, и никакая if логика там не нужна, более того там и шаблоны+db orm (простейший) есть, этого имхо вполне достаточно для выполнения ряда задач.
Взять тотже pylons/tg - набор кучи библиотек "склеенных" воедино (практически набор библиотек, а не фреймворк) + добавлены всякие paste/tg-admin и тп вещи, упрощающие работу с моделью и созданием скелетона, но там в отличии от джанги не так проблемно прикрутить сторонний модуль (стальная архитектурность опять же не всегда есть гуд)
Я уже молчу о скорости django (наверно и тут из-за мега архитектурности ;)), разница по сравнению с "недофреймвокрами" 50-100% не в пользу первой;)
ps: каждому свою, но как-то скучно читать камменты о том как всё хорошо в джанге и другие не имеют права на существование. И поменьше фанатизма, он иногда мешает здравой критике ;)
хотя webob - фигня, согласен В)
Гораздо более правильно про WebOb и сделай-сам-себе-фрейморк читать у Яна Бикинга: http://pythonpaste.org/webob/do-it-yourself.html
Я такого не писал, это strawman.
Может, это вам стоит отвлечься от отрицательной реакции на Джанго? Я, конечно, привожу ее в качестве примера, потому что лучше всего с ней знаком. Но это только пример, а аргументы свои я, кажется, обосновал.
2slav0nic
А то Вы хотели, все-таки Иван знатный it-евангелист в индустрии вообще и в django в частности. Поэтому здесь в основном тусуются те, кто хочет больше узнать о джанго или посмотреть отзывы людей, которые на нем уже писали.
А что касается того, что из джанго нельзя чего-то выдрать или трудно добавить стороннюю библиотеку, то это все конечно же так, но джангу я допустим не за это уважаю. Ведь с точки зрения управленца проектами, к которым относится в частности Иван и немного я, какой фреймворк использовать - это не важно, в прочем не важно и какой язык программирования использовать. Важно другое - за отведенное время (как правило небольшое) необходимо создать продукт удовлетворяющий требованиям клиента. И здесь на первое место выходит тулсет как таковой, который включает в себя и язык программирования, и фреймворк, и легкость освоения языка и фреймворка теми участниками команды, которые их не знают, и много чего еще.
И вот с этой точки зрения указанные Вами недостатки джанги волшебным образом превращаются в огромные достоинства - инетграция, продуманность и вылизанность компонентов системы, универсальность, легкая обучаемость, предсказуемость и т.д.
К тому же джанго имеет достаточно большое и дружелюбное сообщество, что является несомненным плюсом любого проекта из Public Domain.
Так что джанго - это не выбор джедаев и фанатиков, это выбор прагматиков и менеджеров проектов, ПМСМ.
Нет, ну вот с такой постановкой я не сголасен :-). Причем с точностью до наоборот:
Интегрированность ≠ жесткость. Люди реально путаются с этим, и я думаю, что долго еще не перестану объяснять ошибочность мнения о том, что Джанго это "негибко".
И язык, и фреймворк критически важны. Просто, и Питон, и Джанго — реально хорошие вещи.
"The Web framework for perfectionists with deadline". Перфекционисты — тоже своего рода фанатики. Но и у нас есть дедлайны :-)
Всегда есть люди, которых посещают мысли вроде "блин ну что это за фигня, почему тут ошибка?! Напишу-ка я всё сам, тут же всё просто!!". Пишут, и это даже работает (собственно, почему бы и нет?). Процентов 90 из таких штучек через какое-то время покрываются пылью и забрасываются. А в начальной стадии, когда пыли ещё нет - вот оттуда и вылезают гордые статьи "джанго - монстр, у меня вон - wsgi "чистый"".
На самом деле тут даже обсуждать нечего. WSGI это же WebServerGatewayInterface и ничего более. Интерфейс архиудобный, кстати. И можно (!) делать сайты при помощи чистого wsgi+python, но при этом не всегда понимают ЧТО придётся писать. Одни только POST запросы уже могут надавать по заднице тем, кто не понимает, что это fuckin' huge amount of work.
А так как (как ни крути) - будет создаваться набор функционала для абстракции - вот он и будет новый самописный фреймворк, так что "чистым" wsgi это назвать уже будет попросту невозможно.
Я вот уже тоже попробовал, но мне хватает ума чтобы понять бессмысленность многих высказываний. Пробовал (впрочем, успешно) написать крохотную wsgi-app вообще без фреймворка для реализации четкого прогрессбара загрузки post данных (читай - файлов). Пока писал мне пришлось отрефакторить всё раз пять, лишь чтобы вообще дописать до конца. Результат мне нравится - всё четко, аккуратно, без ошибочек и очень лёгкое решение. Но писал я это по одной-единственной причине - в тот момент на django это реализовывалось совсем невнятным и далеким от "чистоты" методом.
Вместо таких вот извращений я рекомендую всем - уж лучше возьмите и меняйте django. Как минимум для меня идеология этой системы поразительно близка настолько, что у меня даже не возникает желания переписывать процентов 80% функционала. Он и так логичен, я бы и сам так написал. А вот если в django закопаться с головой - понимаешь, что менять его легко. Это открытый код, довольно модульный, который (если мозгов хватит) можно заставить делать всё. Если мозгов не хватит - то тем более создать свою систему с нуля не получится никоим образом.
Кто-то там выше писал в комментарих про "хочу убрать MVC скелет из проекта". Так вот - в джанго (хотя здесь 99% заслуг - питон) вы можете вообще всё нафик переделать. Конечно, есть несколько хуков которые придётся менять (ну например способ как django выискивает USE-тесты). Для больших проектов я всегда отхожу от традиционного способа организации django кода в сторону усложнения. При этом мне вообще не приходится патчить фреймворк - просто на питоне ведь можно с кодом делать все что захочется прямо в рантайме. Для кого-то это новость? ;)
Джанго-джанго, танго-танго...
Немного похоже на музыку священного ритуала танца с бубном вокруг тотема. Я не хочу и не буду никого критиковать, но джанго (как и любой фреймворк) далеко не всегда пригоден. Если девелопер создает один большой проект, то пожалуй ему джанго полезен. Но если проектов у него множество (т.е. не 2-3, а 200-300), и все они весьма разные, то использование фреймворков затрудняет работу, в отличии от работы с набором библиотек и даже в отличии от raw-кодинга.
Возьму пример из другой области. Есть WordPress. Идеальный движок блога для "сферического блоггера в вакууме". Предусмотрено все, что только можно предусмотреть и, одновременно, упущено множество специфичных деталей. А "монстроузность" WP, в свое время вынудила нас к разработке собственного движка (написанного изначально на Python и под связку с Nginx). В результате, мы установили это приложение без лишнего геморроя на сотнях блогов, существенно снизив нагрузки на сервер и избавившись от 85% ддосов (проксированием + снижением затрат CPU &