динамические web приложения на python без «npm run ...»

Куда-то тебя не туда понесло) Я про Джангу написал лишь в контексте различий между React и Angular/Vue. Нужна она или нет, это вообще дело десятое. Но если ты считаешь, что не нужна, то, стало быть, React тебе больше зайдёт, чем Angular или Vue.

virtual dom - производительность

Если я буду каждый запрос к серверу писать на диск (e.g. localStorage) — у меня повысится производительность от этого?

frp - проще понимать, что происходит с состоянием

API к Redux уже освоили? И как оно, легко понимать, что там с состоянием прооисходит?

С технической стороны React — это сырая поделка

Можешь подробнее рассказать? Сейчас надо писать проект небольшой с фронтендом, предположительно беру vue. Что с реактом не так?

Люди из Facebook сделали на коленке решение для внутреннего пользования, потому что фичи Angular того времени их не устраивали. Основные особенности их системы: много фич, фичи меняются, при этом контент достаточно банален, то есть, статейка, картиночка, панелька с инфой, видео, комменты, отправить сообщение. Это не интерактивные 3D графики, не мультиплеерные стратегии-шутаны-RPG, не симуляторы аэродинамики, и даже не карты — Facebook использует Mapbox вместо собственной разработки. Писать такое кол-во тупой функциональности на ангуларе или на чистом TypeScript — значит привлекать много высококвалифицированных кодеров. А в фейсбуке их не так много.

Например, Microsoft смог набрать как минимум десяток-другой хороших JS кодеров и сделать VS Code. Но VS Code — это порядка миллиона строк кода. Достаточно скромный размер. У сайта же фейсбука 60 миллионов строк! Шестьдесят миллионов. Чтобы написать такое лет за пять, нужны сотни JS кодеров. А где их найти? Как ни странно, именно поэтому фейсбук продвигает свою внутреннюю поделку в массы — чтобы больше людей ее осваивали и у фейсбука расширялся выбор кадров.

Фейсбук под свои нужды спроектировал систему, в которой полнейший дебил может написать превращение модель=>вид и написать простенькие алгоритмы работы с моделью. Фейсбук не опередил при этом своё время — они просто брали те инструменты и методы, которые были приняты в то время. В частности, они по минимуму применяли возможности транспиляции, ограничивая ее до обработки шаблонов и запаковывании большого числа модулей (написанных сотнями программистов) в большие блоки для упрощения загрузки пользователем через интернет. Даже в более раннем Angular компоненты перемалывались до неузнаваемости при компиляции, а в React компилировался только JSX.

Уже со временем стало очевидно, что:

 — такая примитивная организация работы с состоянием не способна адекватно описывать сложные сценарии работы с состоянием. Под это дело насоздавали Redux/MobyX/etc;
 — на большом дереве интенсивно изменяемых компонентов Virtual DOM адово тормозит (привет интерактивным картам);
 — использование классов (уподобляясь Angular, к слову) было провальным решением, которое привело к трудности расширения и переиспользования готового кода.

В одно время они попытались было решить проблему классов миксинами, но быстро опомнились и поняли, что в FRP лучший способ наращивать абстракции — это функции высшего порядка. В конце-концов это вылилось в механизм хуков, который молод, умен, здоров, но тема еще не вскрыта, и работает он медленнее своих старых товарищей.

Вот в таком последнем своем образе React чуть более актуален и не настолько сыр. Правда, мне интересно посмотреть, сколько кодеров на React умеют писать компоненты высшего порядка и пользоваться хуками.

Vue здесь решает первую проблему работы со сложным состоянием, и частично решает проблему работы с интенсивным обновлением, потому что умеет из коробки обновлять только часть SPA, а не строить и сравнивать полное дерево. В остальном проблема медленного обновления поддерева через Virtual DOM унаследована с React, а классы до безобразности слизаны с реакта со всеми недостатками, вплоть до наличия функциональных компонентов с функций render().

Сравнивать React с Angular/Vue - бредовая затея. React - это библиотека для отрисовки компонентов, а Angular/Vue - это фреймворки

К сожалению, я на этом пишу, потому не согласен. Vue может существовать полностью без времени компиляции, компилируя шаблоны в рантайме. А тем временем дистрибутив React на NPM вообще не содержит компилятора JSX в рантайме, так что особо озабоченным нужно применять какой-нибудь парсер htm или писать создание элементов руками на функциях. А помимо работы состояние=>отображение ни React, ни Vue толком ничего не делают.

Angular — да, ближе к законченному фреймворку, но Vue намного ближе к React, чем к Angular.

Насчёт того, что «с технической стороны React - это сырая поделка» - это голословное утверждение, потому что это достаточно зрелая библиотека

Хорошо, не сырая, а примитивная. Я неточно выразился. Ну типа если я напишу либу из одной строчки:

window.$$ = (q, e = document) => [...e.querySelectorAll(q)]

И назову это фреймворком jVanilla — ты поведешь пальцем у виска. Однако, React не сильно больше этого, а тем временем люди на полном серьезе поклоняются реакту. React — это скорее способ организации JS фронтенда в виде компонентов, а не какая-то конкретная реализация. Вроде «мойте руки с мылом, не переходите дорогу на красный». Причем, Vue по этому критерию — это скорее вариант React-а.

Но я уже много раз писал в этом и соседнем треде: вас что, кто-то заставляет говнокодить, не мыть руки, переходить дорогу на красный? Не обязательно же принимать христианство, чтобы перестать колоться героином, но некоторые думают: «вот, причащусь, покаюсь, и заброшу наркоту». Причина и следствие: вам нужен реакт, потому что вы — индус, вам нужна церковь, потому что вы — безнадежный торчок, вам нужна смирительная рубашка и/или галоперидол, потому что вы бегаете через дорогу сломя голову, ковыряетесь пальцем в попе, а потом этими же руками кушаете. Я не имею никого конкретно в виду, если что.

Это как для разработки бэкенда взять Flask вместо Django или Slim вместо Laravel - будет то же самое, потому что потребуется обвешиваться кучей библиотек. А возьмёшь Django или Laravel - будет куча всего «из коробки». Кому-то нравится один подход, кому-то другой

Django писали ООП-анутые наркоманы, у них в иерархии классов черт ногу сломит. Это абсолютно неоправданная сложность.

И как это противоречит тому, что я написал выше?

И как это противоречит тому, что я написал выше?

Противоречит как минимум по тезису: «Angular/Vue - это фреймворки».

Далее я уточнил по поводу допущенной мной неточности.

Далее с твоей стороны шло достаточно размытое рассуждение, потому говорить про противоречие мне сложно. С моей позиции есть два разных фактора для того, «чтобы на %frameworkname% писать нормальный поддерживаемый код»: общая грамотность организации создаваемого кода, независимо от фреймворка и языка; и наличие готовых решений, которые поддерживаются не тобой. Проблема в том, что сами готовые решения могут быть безграмотно организованы, что свойственно тому же Django и делает его таким нерасширяемым. Я вот подключал стороннюю либу, а она оказалась такой кривой, что теперь поддержка ее оказалась на мне — я получил геморрой. К сожалению, с Laravel не знаком, так что прокомментировать не смогу. Моя позиция такова: юзайся фреймворк большой и маленький, лишь бы не кривой и не падающий ярмом на шею.

virtual dom - производительность

Если я буду каждый запрос к серверу писать на диск (e.g. localStorage) — у меня повысится производительность от этого?

Какое отношение это имеет к virual dom?

frp - проще понимать, что происходит с состоянием

API к Redux уже освоили? И как оно, легко понимать, что там с состоянием прооисходит?

Я не настоящий сварщик, у меня почти нет опыта во фроненде - кроме серверных шаблонов аля django-templates и подобное.

Это не интерактивные 3D графики, не мультиплеерные стратегии-шутаны-RPG, не симуляторы аэродинамики, и даже не карты

Потому что такой задачи и не стояло перед библиотекой? Зачем делать монстра?

Писать такое кол-во тупой функциональности на ангуларе или на чистом TypeScript — значит привлекать много высококвалифицированных кодеров.

Сам подход «такое кол-во тупой функциональности» уже не здравый сам по себе. Тем более, если подходы и паттерны одни и те же по сути.

Например, Microsoft смог набрать как минимум десяток-другой хороших JS кодеров и сделать VS Code.

Внутри vscode наверняка отличные юзкейсы от того, когда и зачем нужен react и сотоварищи.

Как ни странно, именно поэтому фейсбук продвигает свою внутреннюю поделку в массы — чтобы больше людей ее осваивали и у фейсбука расширялся выбор кадров.

react используется на 99,9% вне фейсбука.

Фейсбук не опередил при этом своё время — они просто брали те инструменты и методы, которые были приняты в то время

Но существовали в виде наколенных поделок или вариантов, при которых юзабельность была сильно ниже + не было стандартизации.

такая примитивная организация работы с состоянием не способна адекватно описывать сложные сценарии работы с состоянием. Под это дело насоздавали Redux/MobyX/etc;

Они решили какой-то сегмент задач, а не все задачи в этой вселенной в одной либе. Абсолютно нормальных подход.

на большом дереве интенсивно изменяемых компонентов Virtual DOM адово тормозит (привет интерактивным картам);

Значит, не надо его использовать в таких задачах или использовать только как часть более общего и полного решения. Why not?

использование классов (уподобляясь Angular, к слову) было провальным решением, которое привело к трудности расширения и переиспользования готового кода.

Не могу прокомментировать, недостаточно скилухи в этом направлении. Но на пальцах можешь объяснить, в чем суть проблемы?

Вот в таком последнем своем образе React чуть более актуален и не настолько сыр

Выходит, все не так плохо - обычный эволюционный процесс.

частично решает проблему работы с интенсивным обновлением, потому что умеет из коробки обновлять только часть SPA, а не строить и сравнивать полное дерево.

vue сейчас наиболее адекватный фреймворк из аналогов?

virtual dom - производительность

Если я буду каждый запрос к серверу писать на диск (e.g. localStorage) — у меня повысится производительность от этого?

Какое отношение это имеет к virual dom?

Если ты делаешь любое действие помимо основного, то программа работает медленее. Если ты делаешь GC — программа тормозит на время сборки, если ты делаешь Virtual DOM — тебе нужно выделять память под него, строить его, и потом убирать после него память. Это накладные расходы, который убивают производительность.

API к Redux уже освоили? И как оно, легко понимать, что там с состоянием прооисходит?

Я не настоящий сварщик, у меня почти нет опыта во фроненде - кроме серверных шаблонов аля django-templates и подобное.

https://habr.com/post/439104/ — желательно смотреть примеры ближе к концу. Я подчеркиваю, что примеры простейшие, уровня «изменить состояние» и «прослушать изменения состояния».

Потому что такой задачи и не стояло перед библиотекой? Зачем делать монстра?

Редакторы текста, просмотрщики видео, карты — это более близкие к фейсбуку примеры.

Сам подход «такое кол-во тупой функциональности» уже не здравый сам по себе. Тем более, если подходы и паттерны одни и те же по сути

Тут вопросы не ко мне, а к фейсубуку и тем людям, кто фейсбуком пользуется. Им надо — вот им и пишут.

Внутри vscode наверняка отличные юзкейсы от того, когда и зачем нужен react и сотоварищи

Я уже назвал, чем юзкейс отличен — динамичным контентом. У фейсбука по большей части статичный контент, который разок отрисовывается, и потом раз в несколько секунд меняется.

react используется на 99,9% вне фейсбука

А если по строкам кода мерить?

такая примитивная организация работы с состоянием не способна адекватно описывать сложные сценарии работы с состоянием. Под это дело насоздавали Redux/MobyX/etc

Они решили какой-то сегмент задач, а не все задачи в этой вселенной в одной либе. Абсолютно нормальных подход

Я надеюсь, к этому моменту ты почитал статью про Redux. Либа для написания SPA, которая толком не умеет работать с состоянием — это забавное зрелище.

использование классов (уподобляясь Angular, к слову) было провальным решением, которое привело к трудности расширения и переиспользования готового кода.

Не могу прокомментировать, недостаточно скилухи в этом направлении. Но на пальцах можешь объяснить, в чем суть проблемы?

Ты бы хоть уточнил какой проблемы. а то их там много. Если в общем, то JS не предполагал вообще наличия классов в языке, this работает криво и приходится применять всякие bind и apply для правильного назначения this в передаваемой функции. Помимо того, наследование вообще можно считать антипаттерном, и в самом фейсбуке наследование тщательно искореняется. Отстается проблема переиспользуемых абстракций, и классы здесь не помогают никак, поскольку у нас FPR и всё строиться вокруг вызова одной функции render, а классы дают какие-то дополнительные методы и атрибуты, которые из другой сказки. Тут-то фейсбук и додумался использовать хуки, передавая состояние в render, что таким образом позвоялет выкинуть классы целиком, оставив только чистое FRP, а заодно получив возможность сочетать функции render, вызывая из одного render другой render.

vue сейчас наиболее адекватный фреймворк из аналогов?

Не знаю, что такое «адекватный».

Можно настроить webpack чтобы он компилял куда-нибудь в staticdir а html которую выплевывает цеплялась как шаблон твоего фласка. В django так удобно делать. Ну и management command сделать для сборки этого всего.

Но при разработке не удобно компилять каждый раз и медленно приходится dev сервер ноды поднимать и трахаться с cors и т.п.