Недавно Макс Ищенко попросил меня добавить публичности циклу статей Сергея Щетинина на 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)

  1. mike

    Покойся с миром, Turbogears...

  2. mike

    это я про вот это :-)

    изучать концептуально целостную структуру всегда проще,
    чем множество ничем непохожих.

  3. Alex Lebedev

    +\1

    ИМХО, вдумчивое чтение кода существующих фрэймворков хорошо лечит от иллюзий "да это все так просто, я за один вечер сделаю". Достаточно увидеть, как много тонкостей и особых случаев нужно учесть и обработать, и сразу понимаешь, насколько велик объем работы требуемой для воспроизведения всего этого даже в урезанном формате.

  4. Александр Кошелев

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

    Как правильно ты заметил, даже умные люди используют фреймворки, а значит польза и удобство в них есть.

  5. http://kpot.myopenid.com/

    Иван, в самой первой статье про Django вы уже писали

    Такое ощущение, что каждый веб-разработчик считает своим святым предназначением выдрать куски кода из какого-то своего очередного сайта и объявить их тулкитом, фреймворком, CMS или чем там еще… Документация не прилагается, рефакторинг — “планируется”.

    По-моему, лучше и не скажешь! Я понимаю, когда люди пишут всё это, мучаются, осознают рано или поздно, что зря потратили время, создав ещё один велосипед, но куда худшего качества... так бывает со многими разработчиками. И со мной бывало. Но писать статьи, и учить остальных делать то же самое - неправильно. Спасибо за вашу критику! К ней, я уверен, прислушиваются :)

  6. Powerman

    Особо ценный комментарий

    Ох, что-то соскучился я по дешёвой популярности... пора, пора сходить против ветра! :) Иван пишет всё правильно. Спорить здесь не с чем. Но можно дополнить.

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

    • Что касается "Посмотрите на … можно все сделать гораздо проще". Люди вообще, и программисты в частности, к сожалению, обожают всё переусложнять. Поэтому в большинстве случаев действительно можно сделать проще. И нужно! Но, к сожалению, в большинстве случаев проще сделать не получается... а получается полная фигня, описанная в статье. Зато в остальных случаях получаются конфетки вроде OS Inferno. Так что в самом подходе ничего плохого или неправильного нет. Просто за эту работу зачастую хватаются те, кто не в состоянии её сделать - отсюда и сложившееся отрицательное отношение к таким попыткам.

    • Без глубинного понимания системы хорошим программистом стать невозможно. А это понимание проще всего получить в процессе написания своей системы/фреймворка либо вычитывания чужого кода, при условии что этого кода вменяемое количество и он простой. А поскольку найти такой чужой код допольно непросто, чаще встречаются как раз переусложнённые монстры, то писать своё - вполне адекватное решение. И сам научишься, и другим будет простой пример для изучения (пока ты его не развил до состояния такого же монстра, как и другие).

    Так что есть минимум три веские причины пытаться разрабатывать свою "простую" систему: обучение; увеличение конкуренции и разнообразия таких систем (от которых выигрывают все, и в первую очередь те кто любят рассказать что свои фреймворки писать вредно и бессмысленно); ну и небольшой шанс действительно получить более простую и элегантную систему.

  7. Иван Сагалаев

    Я все-таки хочу внести еще небольшое разъяснение. WebOb пишет Йен Бикинг, которому в авторитете и уме не откажешь. Однако мне кажется, что и эта штука, и сам Paste для него — скорее эксперименты в духе "посмотрим, как сыграет такая концепция в целом". И все это действительно очень интересно — нащупать тот баланс между фичами и их отсутствием, который бы был как раз. Но пока, на мой скромный взгляд, равновато говорить о том, что это полноценный боевой инструмент.

  8. Dan Korostelev

    Отвлекаясь от темы (со статьёй я согласен полностью), а чем Вас так рассердило упоминание Zope и Django в одном ряду? Если смотреть на Zope3, как на веб-фреймворк (как его в основном и используют), то он даже похож на django, хотя, конечно, принципы немного другие (компонентная архитектура, траверсинг объектов, вместо подключения правил разбора URL и т.п.).

  9. Александр Соловьёв

    Особо ценный комментарий

  10. dobrych

    +\1 подписываюсь :-)

  11. Zada

    Хух, спасибо за статью. Я как раз увлекся чтением того цикла и что-то у меня в мозгу начало переключаться...
    Единственный смысл писать все самому вижу исключительно для образовательных целей (это я имею ввиду себя, бо на написание своего фреймворка при теперешних условиях ума у меня не хватит).

    В общем спасибо, что еще раз подтвердили правильность моего увлечения Django.

  12. Алексей Гусев

    В пух и прах.

    А еще:

    Нпаример, в третьей статье Сергей сетует...

  13. slav0nic

    Других отзывов не стоило ожидать;) наверно 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 - фигня, согласен В)

  14. Юревич Юрий

    Гораздо более правильно про WebOb и сделай-сам-себе-фрейморк читать у Яна Бикинга: http://pythonpaste.org/webob/do-it-yourself.html

  15. Иван Сагалаев

    как всё хорошо в джанге и другие не имеют права на существование

    Я такого не писал, это strawman.

    Может, это вам стоит отвлечься от отрицательной реакции на Джанго? Я, конечно, привожу ее в качестве примера, потому что лучше всего с ней знаком. Но это только пример, а аргументы свои я, кажется, обосновал.

  16. ziro

    2slav0nic

    Других отзывов не стоило ожидать;) наверно 90% посетителей- джангисты

    А то Вы хотели, все-таки Иван знатный it-евангелист в индустрии вообще и в django в частности. Поэтому здесь в основном тусуются те, кто хочет больше узнать о джанго или посмотреть отзывы людей, которые на нем уже писали.

    А что касается того, что из джанго нельзя чего-то выдрать или трудно добавить стороннюю библиотеку, то это все конечно же так, но джангу я допустим не за это уважаю. Ведь с точки зрения управленца проектами, к которым относится в частности Иван и немного я, какой фреймворк использовать - это не важно, в прочем не важно и какой язык программирования использовать. Важно другое - за отведенное время (как правило небольшое) необходимо создать продукт удовлетворяющий требованиям клиента. И здесь на первое место выходит тулсет как таковой, который включает в себя и язык программирования, и фреймворк, и легкость освоения языка и фреймворка теми участниками команды, которые их не знают, и много чего еще.

    И вот с этой точки зрения указанные Вами недостатки джанги волшебным образом превращаются в огромные достоинства - инетграция, продуманность и вылизанность компонентов системы, универсальность, легкая обучаемость, предсказуемость и т.д.

    К тому же джанго имеет достаточно большое и дружелюбное сообщество, что является несомненным плюсом любого проекта из Public Domain.

    Так что джанго - это не выбор джедаев и фанатиков, это выбор прагматиков и менеджеров проектов, ПМСМ.

  17. Иван Сагалаев

    Нет, ну вот с такой постановкой я не сголасен :-). Причем с точностью до наоборот:

    А что касается того, что из джанго нельзя чего-то выдрать или трудно добавить стороннюю библиотеку, то это все конечно же так

    Интегрированность ≠ жесткость. Люди реально путаются с этим, и я думаю, что долго еще не перестану объяснять ошибочность мнения о том, что Джанго это "негибко".

    какой фреймворк использовать - это не важно, в прочем не важно и какой язык программирования использовать

    И язык, и фреймворк критически важны. Просто, и Питон, и Джанго — реально хорошие вещи.

    Так что джанго - это не выбор джедаев и фанатиков, это выбор прагматиков и менеджеров проектов

    "The Web framework for perfectionists with deadline". Перфекционисты — тоже своего рода фанатики. Но и у нас есть дедлайны :-)

  18. MockSoul

    Всегда есть люди, которых посещают мысли вроде "блин ну что это за фигня, почему тут ошибка?! Напишу-ка я всё сам, тут же всё просто!!". Пишут, и это даже работает (собственно, почему бы и нет?). Процентов 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 кода в сторону усложнения. При этом мне вообще не приходится патчить фреймворк - просто на питоне ведь можно с кодом делать все что захочется прямо в рантайме. Для кого-то это новость? ;)

  19. Вацлав

    Джанго-джанго, танго-танго...

    Немного похоже на музыку священного ритуала танца с бубном вокруг тотема. Я не хочу и не буду никого критиковать, но джанго (как и любой фреймворк) далеко не всегда пригоден. Если девелопер создает один большой проект, то пожалуй ему джанго полезен. Но если проектов у него множество (т.е. не 2-3, а 200-300), и все они весьма разные, то использование фреймворков затрудняет работу, в отличии от работы с набором библиотек и даже в отличии от raw-кодинга.

    Возьму пример из другой области. Есть WordPress. Идеальный движок блога для "сферического блоггера в вакууме". Предусмотрено все, что только можно предусмотреть и, одновременно, упущено множество специфичных деталей. А "монстроузность" WP, в свое время вынудила нас к разработке собственного движка (написанного изначально на Python и под связку с Nginx). В результате, мы установили это приложение без лишнего геморроя на сотнях блогов, существенно снизив нагрузки на сервер и избавившись от 85% ддосов (проксированием + снижением затрат CPU & RAM). При этом, объем устанавливаемого софта, в килобайтах, снизился до неприличных 450Кб, которые делали ровно то же, что и многомегабайтный WP. Да, я программист старой школы, привыкший экономить каждый байт и оптимизировать всё, что можно оптимизировать. Будь исключительно моя воля, всё бы было вообще переписано и скомпилировано на C++.

    В результате, во многом благодаря (хотя во многом и вопреки) автору критикуемого цикла статей, мы имеем чрезвычайно гибкую реализацию своих проектов, не сдавленные требованиями Django или другого любого фреймворка. И внесение "специфических" изменений делается существенно быстрее.

    К чему всё это я? Да, джанго хорош. Очень хорош. Для индивидуальных, отдельно взятых проектов. Но для промышленных масштабов, больше пригоден действительно свой специализированный фреймворк или вообще код from scratch.

    Помните древний анекдот, про изобретателя автоматического устройства для стрижки? Ему говорят: "Ну у людей же разные формы головы!". На что он отвечает: "ДО первой стрижки - да".
    Так и здесь. Задачи разные. И чем больше компании приходится решать разнообразных задач и подстраивать их под нужды каждого конкретного клиента, тем меньше применимы public движки.

  20. Иван Сагалаев

    Но если проектов у него множество (т.е. не 2-3, а 200-300), и все они весьма разные, то использование фреймворков затрудняет работу, в отличии от работы с набором библиотек

    Эта фраза, равно как и сравнение Джанго с WordPress'ом, показывает, что вы, похоже, неверно представляете себе, что это за "фреймворк". С точки зрения свободы разработки кода Джанго — именно библиотека, он не навязывает никакого жесткого каркаса разработки. Лишь рекомендует определенные паттерны.

  21. Dip

    И все же зря Иван так накинулся на Сергея. Одной большой Истины не бывает, истина для каждого своя. Я вот тоже начал присматриваться к джанге, но в текущем проекте ее использовать не буду, а пойду как раз путем, который проповедует Сергей. Главная причина банально проста - запросы к базе должны быть оптимизированы настолько, что придется использовать SQL напрямую, без всякой высокоуровневой обвязки. Насколько я понял, джанга это впринципе позволяет, но тогда автоматически отваливается 50% фич, за которые ее так любят :)

    Да и вообще... Фреймворки - это хорошо. Если их можно допилить напильником - вдвойне хорошо (опираясь на мой достаточно обширный опыт использования Qt). Но иногда действительно стоит пойти другим путем. Возможно для Сергея это "иногда" случалось намного чаще.

  22. BigHo

    Джанго — именно библиотека, он не навязывает никакого жесткого каркаса разработки. Лишь рекомендует определенные паттерны.

    Это с какой стороны посмотреть. Стандарты ISO - тоже рекомендации, но попробуй закрутить метрическую гайку на дюймовую трубу. Когда же все комплектующие выпускаются на одном заводе, то и в соответствии к ISO стандартам можно отнести только внешние характеристики, такие, как форм-фактор и другие основные потребительские качества. Корейские производители, например, заливают внутренность телевизора смолой, чтобы не принимать претензий к внутреннему устройству - ремонтопригодности: деталь то одна, абыдна - да? ;)

    Так и с веб-приложениями. Что мне не нравится в django, так это навязывание своего темплейта, своей orm. Взять по отдельности, то orm предполагает двигать разработку БД от django. Это прежде всего выражается в добавлении еще одного идентификатора к большинству таблиц. Но к черту универсальность, если на кону - производительность, и специфическая адаптация запросов.

    С другой стороны взять встроенный темплейт. Тут наплевав на производительность выбираю XSLT, поскольку требуется генерить полные странички более редко, чем AJAX ответы. Для AJAX-а "рисование" отдельного темплейта у меня вызывает резкий внутренний протест. Здесь, конечно, lxml.builder - незаменимый друг и товарищ.

    Заменив orm и template джанги можно ли считать, что это джанга? Если да, то в какой мере? Осталось изменить парсинг GET строчки на более подобающей данной задаче, как от джанги останется не так уж и много (кстати, что именно?).

    С чем согласен, так это то, что вылизанная документация - повод для восхищения. В этом же можно увидеть сильную сторону php и mysql - с чем в немалой степени связано их развитие. Став попсой, можно будет смириться с тем, что джанго станут ругать не реже, чем php - такова уж цена популярности :)

  23. Dyadya Zed

    @Вацлав:

    Я не знаю зачем писать код с нуля, если уже есть Django.
    Блоги или мультиблоги - вполне стандартная задача для Django.
    У вас есть всё время вселенной для решения уже решенной задачи?
    Его всегда можно форкнуть, выкинутьпереписать всё ненужное. Будет супер вариант, сделанный для себя.

    Не знаю, как глубоко вы в него закапывались, но если рассматривать Django как еще одну питонячью библиотеку - то она решает свои задачи очень успешно. Никто не переписывает urllib только для того, чтобы забрать страничку с удаленного сервера.

    Мне нравится в Джанго, что над кодом работает огромное количество людей по всему миру, код развивается. Такими темпами развивать код могут только крупные корпорации, да и то результат не всегда успешен.

    Соглашусь с Александром Кошелевым, что люди, не использующие фремворки или плохо знают их возможности, или не хотят их изучать. Есть еще психологический аспект: мой код самый суперский код в мире и если я написал это сам и это работает, значит я офигенски крут и не нужны мне никакие фреймворки.

    Ну и что, что это заняло больше времени, кого это волнует?

  24. skru

    От изобретения велосипедов не избавлены и те, кто работает с фреймворками. Просто это откладывается на какой-то срок. Обычно до момента выхода за рамки прототипа или когда понадобилось сильно расширять функционал. Вот тогда-то и возникает вопрос, что лучше: строить свой фреймворк поверх существующего или с нуля.

  25. А вы читали статью (и комментарии к ней) Ивана Сагалаева — WSGI ФРЕЙМВОРК?

Добавить комментарий