paradox81ru

paradox81ru
Просто в нашей организации используются различные информационные системы

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

Но вопрос то был не в этом, я сразу упомянул про слабые машины. Вопрос в том, откуда я взял, что интерфейс генерируемый браузером будет тормозить на слабых компьютерах. Конечно, хорошее железо нужно. Но мой сайт, если он когда-то все таки заработает, рассчитан на обычных людей, для многих из которых, учитываю экономическую ситуацию в стране, экономия на железе нередко вызвано вопросом выживания, проще говоря денег не хватает. И пока таких людей еще предостаточно, я бы предпочел строить свой сайт с учетом и их интересов, и их компьютеров. Конечно, предвидя сразу ваше следующее замечание, что надо тогда учитывать и людей пользующихся еще до сих пор Explorer 6, могу ответить, что у меня, как у практикующего сисадмина есть некая своя статистика по используемому компьютерному железу в нашем городе, что дает мне некоторое понимание о средней мощности компьютеров в провинциальных городах, установленных операционных системах и даже браузерах, и именно на эту информацию я и опираюсь. При все при этом, это конечно же моя личная статистика, и мой Выбор.
FishHook, извините меня за этот спор, конечно же мои знания в WEB разработках еще весь малы, и я разумеется не оставляю Ваши советы без внимания. Я обязательно учту, что будущее за технологиями Angular, React, и вполне допускаю что и мой будущий сайт придется переделывать под них. И, большое спасибо Вам за то, что вы поправили мои понимания о создании фронтенда, вернее напомнили, что нужно максимально разделять разработку бэкенда и фронтенда, подсказали как это сделать, и этим я сейчас и занимаюсь. И если я правильно исправлю логику своего сайта, то думаю в будущем у меня не будет особых проблем перейти на то же Angular, или что-то похожее.
Извините еще раз если был не прав, и спасибо Вам еще раз за помощь!!!

paradox81ru
Вы сначала говорите, что тормозят ваши компьютеры на корпоративном ПО, и тут же говорите, что хотите писать для “простых людей”. Это вообще как бы разное. Корпоративное ПО - это обычно много данных, много запросов, всякие гриды и куча одновременно активных компонентов. “Гражданским” сайтам всего этого не надо. React - это библиотека Фейсбука. Запустите Фейсбук и посмотрите, тормозит он или нет, и подумайте над тем, для какой категории граждан он написан, можно ли их считать “простыми людьми”.

Вы знаете, Вы меня убедили. И с учетом того, что мне все равно надо фронтенд переделывать, наверное и мне есть смысл рассмотреть React в качества фронтенда. У меня еще пока есть такая возможность. Но встает еще один вопрос, на чем это реализовывать? В смысле, что чистая Django все таки создавалась для работы в паре с шаблонизатором, а с React действительно требуется несколько подход другой. Что вы думаете насчет Django Rest Framework, это вроде как надстройка над Django, которая как раз и может помочь в работе Django с React-ором? Или что-нибудь другое можете посоветовать?

Django Rest Framework вполне подойдёт. Но раз уж я начал антиджанговскую кампанию, то не могу остановиться на достигнутом и скажу: ну и зачем вам эта джанга вообще нужна? По сути в ней полезного - только админка. Ну и мигратор еще, правда он ооооооочень тормозной и поэтому тоже в топку его. Посмотрите, например, на связку Flask + Sql alchemy + trafaret.

Ну вообще у меня на Джанге уже написана относительно большая часть бэкенда, и нужен весьма весомый повод, чтобы взяться за переписывание бекенда на другом фреймворке, да к тому же еще перед этим потратив время на изучение этого “нового” фреймворка. Когда я выбирал фреймворк для написания сайта, и интересовался какой выбрать, Flask или Django, то мнение людей разделились примерно поровну, из чего я сделал вывод, что тут уж дело не в фреймворке, а в качестве кода, гвонокод можно написать и там и там. Поэтому я и выбрал наобум Django, да и различных дополнения к Дажнге тогда вроде бы побольше было, хотя опять же все со слов специалистов с форумов. И до сих пор я как то не слышал о каких-то весомых преимуществах Flask по сравнению с Django, что бы перейти на него. Если подскажете, в чем преимущества Flask, то может и этот вариант рассмотрю, и перенесу открытие своего сайта еще на год…

paradox81ru
Если подскажете, в чем преимущества Flask

А что вам фактически нужно для построения сайта? “я выбирал фреймворк для написания сайта”, ок, а что фреймворк должен делать? Давайте разберемся.
В “классическом” веб-приложении, нужен:
1) Рендеринг HTML. Вы сами выяснили, что стандартный шаблонизатор Джанго вам не подошел, и вы используете jinja из flask. Далее мы решили, что это нам вообще не надо.
2) ОРМ. Если вам очень нравится ОРМ из Джанги, то есть проект peewee, но вообще говоря, Джанговский ОРМ слабый и тормозной. Да и вообще, если выбирать между Active Record и Unit of Work, то последний подход не спроста реализован в таких монстрах как JPA/Hibernate и Entity Framework, он дает больше контроля.
3) MVC. Джанго заточен под MTV, М - смотри пункт 2, Т - смотри пункт 1. Ничего не осталось, кроме контроллера/представления, и у Джанги тут есть дженерики и CBV, но

а) а зачем они нужны без шаблонов? Достаточно одного базового View чтобы отдавать JSON.
б) это легко реализуется самостоятельно и более того чаще всего базовые контроллеры или миксины для них вы все равно пишите свои.

4) Формы. В контексте рендеринга форм есть несколько проектов, например. Обёртки под фласк тоже есть. Ну а для валидации AJAX-запросов все равно нужно что-то стороннее.
5) Роутинг. Джанговский роутинг меня бесит.
6) Middleware. Есть в любом более-менее серьезном решении.
7) Админка. Хорошо, но не обязательно. То, что нельзя править клиентам, администратор может поправить через какой-нибудь phpmyadmin.
8) Локализация. Джанга делает это с помощью стандартного модуля gettext. Берем gettext и не паримся.

Что я забыл?

Ну Вы в общем-то так и не указали каких либо достоинств Flask, вы скорее попытались указать на недостатки Джанги. Но тут тоже все не однозначно. Да, стандартные шаблоны Джанги далеки от совершенство, но это уже похоже давно поняли и сами разработчики Джанги, и поэтому сделали интеграцию Django с Jinja максимально простой, можно сказать даже из коробки. Что касается ОРМ у Джанги, то он действительно довольно удобный. Я не пробовал создавать проект под Flask, но читал что там изначано подход к работе с БД несколько другой, более правильный с точки зрения ООП но менее удобный. Что лучше, единого мнения нет, но все таки я привык уже к Джанговскому ОРМ, и не вижу пока смысла менять этот подход. Роутинг, это очевидно диспетчер URL, это весьма индивидуально. Если честно, то я могу сравнивать только с Yii2, с которого я когда-то начинал изучение WEB разработки. Но с учетом того, что в Yii2, насколько я помню, у меня многое было завязано на апачевском модуле mod_rewrite, то тут вообще получается несколько разный подход, и в Джанге вроде бы удобнее получается с URL-ами.
Я вообще планировал как-нибудь сделать какой-нибудь ознакомительный проект на Flask, чтобы оценить разницу в Фремворках, но как-то все время найти не могу. Но я не думаю что все таки буду перестраивать на него мой, уже больше чем на половину готовый проект. Да и с React оказалось все не так хорошо. Уж больно заморочены оказались первоначальные настройки, чтобы переделать фронтенд на него, с ходу сразу не получилось настроить. А ведь после этого еще надо изучить всю эту технологию. И в некоторых статьях к тому же пишут, что не стоит везде и всюду использовать React. Да, это очень хорошая технология, замечательный быстрый фреймворк, и за ними будущее, но стоит ли сайт того, чтобы его писать с использованием React? Классический подход, когда клиенту передается сформированная страница, еще долго будет актуален, а скорее всего этот подходу всегда будет иметь свою нишу, всякую технологию надо использовать по своему назначению, а стрелять из пушки по воробьям никогда актуально не было. Поэтому и я, несколько получше ознакомившись с технологией React, и с тем какие затраты мне придется затратить (извиняюсь за тавтологию), чтобы переделать свой сайт на него, сейчас уже призадумался, а стоит ли мой сайт того… На Jinja кстати действительно оказалось довольно просто и удобно создавать интерфейс, то что я делал раньше с помощью собственных тегов в шаблонах Django, с помощью include и макросов в Jinja оказалось сделать гораздо быстрее и проще. Думаю я довольно быстро смогу переделать весь фронтенд. Поэтому я наверное все таки буду доделывать свой проект на Jinja, а после того как его запущу, уже подумаю насчет перевода его на React. И если я далее буду использовать Django-Rest, то там наверное и с переделыванием бекенда особых проблем быть не должно. Кстати это можно назвать плюсом к Джанге.