Если речь идет об относительно свежих Chrome / Firefox и даже Edge, то значительная часть ES6 и большая часть CSS3 там поддерживается нативно. Так что под них вполне можно программировать без зоопарка утилит на node.js. Другое дело что IE11 продолжает поддерживаться до 2020 года, а в нем даже arrow functions нет.
При этом удивительно что достаточно полного es6 до сих пор нет даже в Firefox / Chrome. В IE нет даже arrow functions! Это при всей продвинутости их виртуальных машин, большом количестве ресурсов, контрибьюторов — казалось бы дело нескольких месяцев. Такое ощущение что Javascript специально искусственно загоняют в рамки убогой кросс-трансляции, вынуждая программиста использвать огромный tool chain.
Скажи какому разработчику Python / Java / PHP что для использования последней версии языка ему нужны кросс-трансляторы вместо нормального интерпретатора с байт-кодом, удивятся. А в мире Javascript это "норма" и даже пишутся статьи в защиту такого подхода.
Слава Богу можно разрабатывать большие приложения в обычном ES5 без кросс-трансляции, используя Knockout.js или Backbone, да и в React тоже (хоть и сложнее).
Вот это самое страшное в современной экономике — везде зарплаты «подбиваются» рынком (точнее сговором предпринимателей) таким образом, чтобы человеку хватало только на жилье и еду и чтобы очень мало оставалось помимо этого. Причем это есть даже в США, где некоторые живут в вагончиках чтобы избежать высокой стоимости жилья.
Делается это по двум основным причинам — первая чтобы боялись потерять работу, ведь когда у человека нет накоплений средств, 1-2 месяца без работы и все — нет денег на еду и на жилье, можно бомжом стать. Такое современное скрытое рабство — можешь менять работодателя, но по сути остаешься рабом (их рабов тоже кормили). Вторая причина — чтобы лишить надежды на будущее, сделать жизнь бессмысленной. Не случайно есть высказывание «работаю за еду» — именно про беспросветность жизни.
Конечно базовый доход не нужен. Нужны две вещи — продуктовые карточки (всем получающим меньше 50 тыс, не только безработным), и очень нужно дешевое жилье. На западе макроэкономистами был анализ причин роста неравенства и оказалось что мощный рост цен на ипотеку и аренду (а у нас и коммуналка) — главный фактор роста неравенства. Лично слышал от англичан что в 80-е годы аренда жилья пожирала меньшую часть зарплаты.
Вы в курсе что в high-tech Калифорнии, где штаб-квартиры крупнейших фирм по железу и софту, на первом месте по вложениям и по доходности не high-tech а недвижимость? Вот это по-настоящему страшно.
А с жильем проблема будет побольше чем с едой. Теоретически нужна полная национализация жилья, только понятно что это невозможно и никто на это не пойдет.
Разбивайте на миксины (если это классы). У меня например по генерации и отправке email нотификаций миксины и классы в emails.py. Затем миксин или класс импортируется в models.py / views.py. Ну и tasks.py для celery.
Вы зря противостовляете ценность детей и мужчин. На самом деле они взаимосвязаны. Без отца ребенок не получает нормального воспитания, так как матерям и бабушкам свойственно излишне баловать ребенка. Также социализация получается неполноценная. Это и происходит сейчас из-за массовых разводов. Ультра-либерализм и феминизм поощряет разрыв отношений, разрушает семьи.
Сверхценность детей проистекает из растущего влияния женщины в обществе. Детоцентризм очень выгоден женщине. В случае конфликтов мать-отец дети гораздо чаще занимают позицию матери, поддерживают ее. Да и вообще отношение к женщине-матери много более уважительное и статусное, чем к нерожавшей женщине.
Конечно и низкая рождаемость, как результат ультра-либерализма, сказывается на ценности детей. Потерять единственного ребенка — больший удар чем одного из многих. Только в конечном итоге все равно приводит к нарушению баланса полов в обществе. Установка на борьбу полов на разрыв отношений вместо сотрудничества, кооперации и прощения.
Судя по тому что в Javascript (как и в PHP) добавляют все больше фич из Python, в том числе генераторы и variadic args, у них планы совсем другие.
Особенно преуспевают разработчики PHP, они вообще похоже изучают PEP и детали CPython. Только при этом основа языка остается кривой: из-за совместимости не поправить.
Ну а в Javascript так и нет нормального наследования, по сравнению с Python особенно бросается в глаза. Нет автоматических нормальных миксинов, нет нормальных метаклассов. Делают extend и миксины вручную, это конечно работает но уступает по изяществу нормальному множественному наследованию в Python.
Да, 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, что является плюсом.