Да, admin в Django очень хороший, не спорю. Только это классическое приложение не REST и не AJAX. node.js позволяет использовать один язык на серверной стороне и клиентской, в случае AJAX / REST должно быть достаточно.
inline formsets вообще одна из самых ценных фич Django, автоматический маппинг отношений один ко многим с уровня моделей на уровень форм. Вроде бы что-то похожее появилось в последних версиях Angular, массивы форм: https://angular.io/docs/ts/latest/api/forms/index/FormArray-class.html
Поддержка множественных форм с отношениями до сих пор большая редкость во фреймворках.
А я до сих пор не могу понять зачем использовать Django как ORM + DRF без inline formsets, admin и прочего что так ценно в Django. Если нужно только серверное API для клиента на react / angular, не лучше ли использовать на сервере node.js?
Я использую AJAX в своих модулях (у меня knockout.js) но подход смешанный — часть кода обычный серверный html, часть AJAX виджеты. Не SPA. Мне кажется что для SPA лучше next.js или что-то подобное.
Чтобы не было слишком много миксинов, нужно базовые CBV делать достаточно мощными. Может быть в них будет несколько редко используемых методов, но этот компромисс лучше чем попытка загнать абсолютно все в миксины.
Использую и CBV и миксины для них, за счет того что базовые CBV большие и многофункциональные, миксинов немного, чаще используется обычное наследование с переопределением нескольких методов:
Тем не менее в случае knockout / angular мы имеем самый минимум логики в шаблонах (конечно можно запихнуть в data-bind JS-код на несколько строк, только это даже человеку не любящему красоту кода будет очевидно выглядеть плохо), а react как-бы поощряет запихивать побольше кода в шаблон. Понятно что хороший программист будет сдерживать себя.
И еще момент с наследованием этого дела. В ES5 и тем более в ES6 можно прототип метода у потомка заменить и пожалуйста — тот же шаблон knockout.js с другим кодом. В то же время в популярном Vue.js с наследованием оказались огромные проблемы вообще не рекомендуют использовать. Хотя на мой взгляд UI без наследования это нон-сенс.
es5 хорош тем что быстрее проект разворачивать (node.js и прочее не нужны) а также сторонний код можно на лету править.
На react может конечно и надо переходить так как спрос на него огромен, хотя идеологически коробит меня от него, привыкнуть ко всему можно. Куча уже существующего кода на Knockout.js работает и вроде как непонятно зачем. Разве что из-за денег.
Советую изучить Python вместо PHP. Не смотря на то что PHP в последних версиях взял очень много из Питона, по легкочитаемости кода и красоте синтаксиса уступает последнему. Python по сути это тот же PHP, но лучше. Особенно если 3.x и с использованием Jinja2.
Мне не нравится JSX из-за смешивания логики (кода) и шаблона. В Knockout.js, который я использую, логика отдельно, шаблон data-bind отдельно. Это позволяет использовать общий шаблон с разными JS классами, что очень удобно. Никаких транспилеров и кучи node.js приложений не нужно, все работает на ES5 без какой-либо прекомпиляции. Сам Knockout.js очень небольшой и содержит все что нужно.
SPA плохи двумя вещами — слабой индексацией в поисковиках и глюками старых браузеров. Я больше использую AJAX компоненты чем чистое SPA. Хотя для админки SPA действительно хорош — там не нужна индексация и вряд ли кто зайдет старым браузером.
Именно такая организация проекта когда views / models и прочее каждого модуля находится в отдельном поддереве (подкаталоге) и принята по-умолчанию в Django. Там правда это еще вытекает из самой организации модулей для Python, которые есть подкаталог с файлом __init__.py.
До этого работал с Laravel, там по-умолчанию группировалось все controller в одном подкаталоге, все model в другом — приходилось чаще скакать по папкам. Так как все-таки в пределах одного модуля модель / контроллер / представление больше взаимосвязанны чем разные модели и контроллеры между собою.
Есть binding: if, foreach, template. Это и есть шаблоны. В последних версиях еще есть компоненты.
http://knockoutjs.com/documentation/if-binding.html
http://knockoutjs.com/documentation/foreach-binding.html
http://knockoutjs.com/documentation/component-overview.html
http://knockoutjs.com/documentation/template-binding.html
Сандерсон умнейший человек что весь синтаксис сделал на html без семантически чуждых вставок. Жаль что их теперь добавили.
Да, на react сейчас спрос большой. Может быть на него и надо перейти, только очень много кода переписывать. И лишь бы к тому времени не придумали что-то новое вместо него.
А теперь поместите это в серверный шаблон к примеру jinja2, и вы увидите зачем нужно не использовать двойные фигурные скобки. Заменить так просто не получится потому что это сломает сторонние компоненты, использующие двойные фигурные скобки. Компактность кода — не самоцель.
Есть еще одна важная фича knockout — в его шаблонах не используются двойные фигурные скобки, в отличие от большинства других js-фреймворков. По этой прините шаблоны и bindings для knockout можно вставлять без экранизации в серверные шаблоны jinja / twig / blade и многие другие.
Почему авторам других фреймворков не приходит в голову что двойные фигурные скобки конфликтуют с серверными шаблонами — не понятно. Видимо думают только о SPA, забывая что зачастую полезнее гибрид обычного серверного приложения и клиентских компонентов, так сказать «полу-SPA».
Использую knockout несколько лет, в том числе binding на классы с возможностью расширения (псевдонаследования прототипами). Очень удобно. Посмотрел расхваливаемый Vue.js, там вместо обычного объекта предлагается делать binding на сам Vue и расширение функциональности очень неудобно сделано из-за этого.
При этом о Vue кричат все кому не лень, а knockout как будто-бы и нет.
Причем на knockout запросто пишутся большие приложения на es5, без всяких ужасных транспилеров.
Такое ощущение что мода и тренды затмевают здравый смысл.
Точно также на серверной стороне — предлагают мини-фреймворки на node вместо мощнейших Django / Rails / Spring, в которых функционала много больше.
Дело в том, что редактирование JSON без Object.observe() это некая магия — не всегда понятно как и когда произойдет обновление данных. В Knockout все очевидно — observable является функцией, когда мы вызываем ф-цию с новым значением в качестве аргумента, выполняется код, который обновляет DOM (хотя в современных версиях Knockout отдельная очередь обновлений, не всегда сразу).
Да, я соглашусь что глубоковложенные структуры в Knockout редактировать неудобно, даже с mapping плагинами. Поэтому стараюсь не допускать большой вложенности, чаще всего это не нужно.
Также можно было бы рассмотреть очень компактные альтернативы для Angular это Knockout.js, для React это riotjs.
Очень печально что массово побеждает «монструозность» и большие размеры библиотеки без существенных явных преимуществ.
На клиентской стороне также чрезмерное увлечение препроцессорами, что на самом деле большая дикость и по сути является «костылями».
Любой человек, которому приходится заниматься как серверной так и клиентской частью, замечал насколько более глюкава и странна клиентская часть на Javascript. В этом смысле Knockout / Riotjs максимально прозрачны, ближе к чистому Javascript, что является плюсом.
Да, admin в Django очень хороший, не спорю. Только это классическое приложение не REST и не AJAX. node.js позволяет использовать один язык на серверной стороне и клиентской, в случае AJAX / REST должно быть достаточно.
inline formsets вообще одна из самых ценных фич Django, автоматический маппинг отношений один ко многим с уровня моделей на уровень форм. Вроде бы что-то похожее появилось в последних версиях Angular, массивы форм: https://angular.io/docs/ts/latest/api/forms/index/FormArray-class.html
Поддержка множественных форм с отношениями до сих пор большая редкость во фреймворках.
А я до сих пор не могу понять зачем использовать Django как ORM + DRF без inline formsets, admin и прочего что так ценно в Django. Если нужно только серверное API для клиента на react / angular, не лучше ли использовать на сервере node.js?
Я использую AJAX в своих модулях (у меня knockout.js) но подход смешанный — часть кода обычный серверный html, часть AJAX виджеты. Не SPA. Мне кажется что для SPA лучше next.js или что-то подобное.
Чтобы не было слишком много миксинов, нужно базовые CBV делать достаточно мощными. Может быть в них будет несколько редко используемых методов, но этот компромисс лучше чем попытка загнать абсолютно все в миксины.
Использую и CBV и миксины для них, за счет того что базовые CBV большие и многофункциональные, миксинов немного, чаще используется обычное наследование с переопределением нескольких методов:
https://github.com/Dmitri-Sintsov/django-jinja-knockout/tree/master/django_jinja_knockout/views
Переползайте на Ubuntu LTS. Очень редко глюки, в том числе software updater.
И еще момент с наследованием этого дела. В ES5 и тем более в ES6 можно прототип метода у потомка заменить и пожалуйста — тот же шаблон knockout.js с другим кодом. В то же время в популярном Vue.js с наследованием оказались огромные проблемы вообще не рекомендуют использовать. Хотя на мой взгляд UI без наследования это нон-сенс.
es5 хорош тем что быстрее проект разворачивать (node.js и прочее не нужны) а также сторонний код можно на лету править.
На react может конечно и надо переходить так как спрос на него огромен, хотя идеологически коробит меня от него, привыкнуть ко всему можно. Куча уже существующего кода на Knockout.js работает и вроде как непонятно зачем. Разве что из-за денег.
SPA плохи двумя вещами — слабой индексацией в поисковиках и глюками старых браузеров. Я больше использую AJAX компоненты чем чистое SPA. Хотя для админки SPA действительно хорош — там не нужна индексация и вряд ли кто зайдет старым браузером.
До этого работал с Laravel, там по-умолчанию группировалось все controller в одном подкаталоге, все model в другом — приходилось чаще скакать по папкам. Так как все-таки в пределах одного модуля модель / контроллер / представление больше взаимосвязанны чем разные модели и контроллеры между собою.
http://knockoutjs.com/documentation/if-binding.html
http://knockoutjs.com/documentation/foreach-binding.html
http://knockoutjs.com/documentation/component-overview.html
http://knockoutjs.com/documentation/template-binding.html
Сандерсон умнейший человек что весь синтаксис сделал на html без семантически чуждых вставок. Жаль что их теперь добавили.
Да, на react сейчас спрос большой. Может быть на него и надо перейти, только очень много кода переписывать. И лишь бы к тому времени не придумали что-то новое вместо него.
https://github.com/ansible/ansible/issues/4638
Почему авторам других фреймворков не приходит в голову что двойные фигурные скобки конфликтуют с серверными шаблонами — не понятно. Видимо думают только о SPA, забывая что зачастую полезнее гибрид обычного серверного приложения и клиентских компонентов, так сказать «полу-SPA».
При этом о Vue кричат все кому не лень, а knockout как будто-бы и нет.
Причем на knockout запросто пишутся большие приложения на es5, без всяких ужасных транспилеров.
Такое ощущение что мода и тренды затмевают здравый смысл.
Точно также на серверной стороне — предлагают мини-фреймворки на node вместо мощнейших Django / Rails / Spring, в которых функционала много больше.
Да, я соглашусь что глубоковложенные структуры в Knockout редактировать неудобно, даже с mapping плагинами. Поэтому стараюсь не допускать большой вложенности, чаще всего это не нужно.
Очень печально что массово побеждает «монструозность» и большие размеры библиотеки без существенных явных преимуществ.
На клиентской стороне также чрезмерное увлечение препроцессорами, что на самом деле большая дикость и по сути является «костылями».
Любой человек, которому приходится заниматься как серверной так и клиентской частью, замечал насколько более глюкава и странна клиентская часть на Javascript. В этом смысле Knockout / Riotjs максимально прозрачны, ближе к чистому Javascript, что является плюсом.