Ну начинается, эта мне оппозиция, вечно растекаются по кандидатам. Суть же в протестном голосовании, чтобы джанго не ушла на второй проект. А Flask выбран как единый кандидат :)
Этот прием использовали девочки в годы школьные — ну пацаны, ну шо вы как мальчишки, вам же по 14 лет уже!!! Где вы таки детектировали пену? В комменте про «я пишу на джанге 10 лет, и за 10 лет не освоил ни одной новой технологии»?
Ну тут можно сделать register декоратором, и классы прям во views загонять в smartersite, вешая на них декоратор. Потом в urls мы импортируем site, подключаем. Но в общем да, разницы особой нет, если не учитывать необходимость импорта вьюх и два места для изменения.
Sqlalchemy и разработка на django orm под sqlite — использование возможностей хорошей БД типа postgres это спички? Django ORM даже куцый sqlite не покрывает.
Невозможность использовать gevent в django спички?
Классическое приложение это выборка данных из базы и форматирование их в страницу — все эти вещи во flask будут сильно быстрее и проще в использовании. Это экономит время на разработку, это экономит затраты на функционирование сервиса в облаке — use less to do more.
Но все это фигня, в сравнении с тем, насколько у фласка более умное API, насколько обезжиренный contrib, насколько каждый компонент гибче, и насколько просто любой из них выкинуть и вкрутить другой.
Это источник другого взгляда на разработку. Но в общем что-то опять пост получается, закруглим.
Я не про админку в принципе, а просто код с generic часто пролазит в urls.py, что плохо. Как-то нелогично, модуль urls, а в нем вьюхи описаны и тп. Вот вы говорите, что у вас больше 10 моделей — вот будут в urls.py 10 строк с регистрацией этих моделек.
А если там прям чуточку чего-то поменять захочется в одной из вьюх?
С другой стороны urls.py мне вообще не кажется хорошим решением.
Экономия это приятный бонус, разработка на flask проще. Компрессор есть, какая-то админка есть. Есть альтернативный ORM pewee некий — там с админкой и тп, комплектом, но сам я не смотрел, ибо не понял в чем преимущество перед sqla.
В общем Flask он не пустынен, requirements там вполне себе обширный выходит. Так что Виллабаджо замучается пыль глотать.
Продолжим ревью
— urlpatterns непонятно зачем property
— class based View все таки рассчитан на один view, а не на пачку, хотя конечно HTTP-методы, но все же.
Я бы рекомендовал построить решение без использования View — от него мусору больше чем пользы.
Хороший пример базиса, который вы здесь хотите сделать, это Bundle из Svarga.
Я бы подумал все же, как убрать из urls.py мясо. Я как считаю — или у нас там урлы, или давайте съедем полностью уж во views как во flask-е, вместе с урлами.
Но шутки в сторону. Скажите мне замшелые троглодиты из реально нереально серьезной веб разработки, что, экономия на рендере шаблонов это лишнее для проектов с посещаемостью >1000? Более быстрая разработка с более гибким ORM это лишнее? Да вы вообще БД используете, или планируете проект на sqlite запускать в продакшн? Даже обработка URL в Werkzeug быстрее. Можно говорить что где-то это копейки, но когда все копейки собираются во Flask, это уже становится серьезно, мимо проходить уже как-то непрофессионально, и даже как-то стыдно.
Повторять сейчас не буду расчеты, но мы тестировали — если сишные спидапсы под джинджу поставить, то разница есть. Углубились вместе после того, как ребята провели свои тесты и не ощутили разницы.
В итоге ребята приняли решение взять таки джинджу и потратить время на ее внедрение.
Плюс эти спидапсы даже в GAE запилены, специально под джинджу.
Невозможность использовать gevent в django спички?
Классическое приложение это выборка данных из базы и форматирование их в страницу — все эти вещи во flask будут сильно быстрее и проще в использовании. Это экономит время на разработку, это экономит затраты на функционирование сервиса в облаке — use less to do more.
Но все это фигня, в сравнении с тем, насколько у фласка более умное API, насколько обезжиренный contrib, насколько каждый компонент гибче, и насколько просто любой из них выкинуть и вкрутить другой.
Это источник другого взгляда на разработку. Но в общем что-то опять пост получается, закруглим.
А если там прям чуточку чего-то поменять захочется в одной из вьюх?
С другой стороны urls.py мне вообще не кажется хорошим решением.
В общем Flask он не пустынен, requirements там вполне себе обширный выходит. Так что Виллабаджо замучается пыль глотать.
— urlpatterns непонятно зачем property
— class based View все таки рассчитан на один view, а не на пачку, хотя конечно HTTP-методы, но все же.
Я бы рекомендовал построить решение без использования View — от него мусору больше чем пользы.
Хороший пример базиса, который вы здесь хотите сделать, это Bundle из Svarga.
Ну или вот та идея под Flask:
github.com/Deepwalker/flask_bundle
Полная версия ответа:
deepwalker.blogspot.com/2012/03/django-web.html
В итоге ребята приняли решение взять таки джинджу и потратить время на ее внедрение.
Плюс эти спидапсы даже в GAE запилены, специально под джинджу.