А зачем вы на них вставали? Теперь надеюсь будем свое делать, да сложно, да дорого, да не быстро, но надо. Кто считает, что мы не сможем пусть идет в известное эротическое путешествие, с ними мы конечно ничего не сможем, а без них все сделаем.
Вы видимо очень плохо знакомы с python и PyQt в особенности, иначе я ваш коментарий объяснить не могу. Ненужно основываться в своих суждениях на вышеприведенный код, это всего лишь пример, а логику вы можете писать где угодно и как угодно не говоря уже о тестах. Вам никто не мешает разбить код на нужные вам архитектурные паттерны типа MVC самостоятельно, это займет минуту времени и придерживаться этой структуры своего приложения без строгого следования структуры приложения навязанного разработчиками библиотеки, python это не java в нем все делается быстро и просто, а QT очень мощная библиотека, которую используют крупные компании для своего софта например Autodesk, да даже KDE на нем написано. Для Java тоже есть обертка этой билиотеки Qt Jambi. Ну а для python PyQt это невероятно удобная и хорошая вещь по крайней мере гораздо лучше встроенной библиотеки Tkinter хотя и он для простых вещей очень даже ничего.
Без Redux будет очень сложно следить и управлять State если проект становится большим. Раньше я тоже считал, что Redux не нужен но увы в крупных проектах он упрощает жизнь.
Я участвовал в нескольких войнах и мы задавались этим вопросом, это самый простой способ спас одеяло очень быстро нагревается и охлаждается, лучше всего скрывает тепловой контур костюм типа "леший" его скажем так "волосяной" покров не нагревается от тела.
Простая плащ-палатка и спасательное одеяло под ней все что нужно что бы скрыть тепловое излучение, палатка будет прогрета или охлаждена окружающей средой, а спас одеяло исключит воздействие тепла на палатку от бойца. Но это и то, что там изобретают в Израиле никогда не даст 100% гарантии скрытности, любая современная оптическая автоматизированная система обнаружения реагирует не только на тепловое излучение но и на движение, так что незаметно выдвинутся на позицию будет очень сложно.
я конечно не спец в 3й джанге (давно сменил стек), но небольшой эксперимент все же проводил. и производительность джанго под asgi у меня проседала на 30% относительно wsgi варианта. а где обещанные бонусы ?))
А вы уверены, что ваши тесты верны и в них использовалась реальная работа веб приложения, а не простое измерение пропускной способности? Бонусы от асинхронности вы получите в любом современном веб приложении, за исключением простых лендингов и отдельных статичных страницах или даже динамичных но простых. Нужно понимать где применять асинхронность, а где нет. Я уже не буду говорить что при длительном синхронном запросе вы его можете просто потерять и при высокой нагрузке на сервер он у вас просто упадет при синхронных запросах. Плюс к этому, чем вам не бонус еще и сокеты. При этом ASGI обратно совместим с синхронными запросами.
А зачем вы на них вставали? Теперь надеюсь будем свое делать, да сложно, да дорого, да не быстро, но надо. Кто считает, что мы не сможем пусть идет в известное эротическое путешествие, с ними мы конечно ничего не сможем, а без них все сделаем.
Вы видимо очень плохо знакомы с python и PyQt в особенности, иначе я ваш коментарий объяснить не могу. Ненужно основываться в своих суждениях на вышеприведенный код, это всего лишь пример, а логику вы можете писать где угодно и как угодно не говоря уже о тестах. Вам никто не мешает разбить код на нужные вам архитектурные паттерны типа MVC самостоятельно, это займет минуту времени и придерживаться этой структуры своего приложения без строгого следования структуры приложения навязанного разработчиками библиотеки, python это не java в нем все делается быстро и просто, а QT очень мощная библиотека, которую используют крупные компании для своего софта например Autodesk, да даже KDE на нем написано. Для Java тоже есть обертка этой билиотеки Qt Jambi. Ну а для python PyQt это невероятно удобная и хорошая вещь по крайней мере гораздо лучше встроенной библиотеки Tkinter хотя и он для простых вещей очень даже ничего.
Без Redux будет очень сложно следить и управлять State если проект становится большим. Раньше я тоже считал, что Redux не нужен но увы в крупных проектах он упрощает жизнь.
Я участвовал в нескольких войнах и мы задавались этим вопросом, это самый простой способ спас одеяло очень быстро нагревается и охлаждается, лучше всего скрывает тепловой контур костюм типа "леший" его скажем так "волосяной" покров не нагревается от тела.
Вывод: Работайте на перспективу и делайте сразу API и фронт JS (разумеется при условии наличия возможностей и правильной оценки необходимости в этом)
Простая плащ-палатка и спасательное одеяло под ней все что нужно что бы скрыть тепловое излучение, палатка будет прогрета или охлаждена окружающей средой, а спас одеяло исключит воздействие тепла на палатку от бойца. Но это и то, что там изобретают в Израиле никогда не даст 100% гарантии скрытности, любая современная оптическая автоматизированная система обнаружения реагирует не только на тепловое излучение но и на движение, так что незаметно выдвинутся на позицию будет очень сложно.
А вы уверены, что ваши тесты верны и в них использовалась реальная работа веб приложения, а не простое измерение пропускной способности? Бонусы от асинхронности вы получите в любом современном веб приложении, за исключением простых лендингов и отдельных статичных страницах или даже динамичных но простых. Нужно понимать где применять асинхронность, а где нет. Я уже не буду говорить что при длительном синхронном запросе вы его можете просто потерять и при высокой нагрузке на сервер он у вас просто упадет при синхронных запросах. Плюс к этому, чем вам не бонус еще и сокеты. При этом ASGI обратно совместим с синхронными запросами.