>>2362625>простые морды, если я бэкендерПРостые морды для бэкендера это jquery + bootstrap, как показывает моя личная практика, лучше уж так чем говнокод на SPA.
>>2362628Почему обязательно говнокод с vue? Пишу чисто, функционально на vue 3 как на реакте. С jquery у тебя в 99% случаев на проектах встретится говнокод. На жиквери можно компоненты писать в виде плагинов, но все любители жиквери предпочитают лапшу.мимо
>>2362637>функционально на vue 3>как на реактеТы насрал в штаны, дружище. Во vue нет функциональных компонентов, а те, что там называются "функциональными" представляют из себя ничего более, чем статичную рендер-функцию без ветвлений внутри.>С jquery у тебя в 99% случаев на проектах встретится говнокод.У тебя и с реактом/вью 99% встретится говнокод, но в отличии от жиквары - он еще и будет с горой бойлерплейта, который без траты огромного количества времени не разберешь.
>>2362642Извини, но я в твои в штаны не срал. Это ты сам наделал. cоmposition api позволяет функциональный код писать насколько это возможно в жс и даже использовать this не дает.
>>2362645Потому что код полностью на функциях, без использования контекста. Тебе никто не мешает его использовать вместе с какой-нибудь ramdajs
>>2362648В JS даже контекст можно реализовать на замыканиях. Отсутствие контекста и преобладание функций - не гарантирует использования парадигмы ФП. Тот же composition api функционален только в момент инициализации, потом у тебя все равно появляется тобой ненавистный контекст, в отличии от реакта - где весь жизненный цикл компонента выполнен в виде функций. Исключение в виде ErrorBoundary не рассматриваем
>>2362655И шо? Я против реакта ничего не говорил. Я же не шизик чтобы искать чистые идеальные формы, в практических приземленных вещах как веб фреймверки
>>2362655Кстати раз ты такой спец покажи мне где этот контекст появляется? setup() {const = reactive({test: 'hello world'});provide('HEHE', () => {//})onMounted(() => {//...})watchEffect(() => {...})}
>>2362667Кстати в вуе 3 не принято писать defineComponent({setup() {а принято вообще чисто на функциях и макросах<script lang="ts" setup>defineProps({propName: {...}})watchEffect(() => {//})</script>
>>2362667Прямиком после выполнения метода setup, когда неожиданно все, что возвращалось из него становится полями объекта внутри прокси, доступ к которым из метода render осуществляется через with(this){}
>>2362683А разве если в реакте мы залезем в метод render или shouldComponentUpdate нам this не нужен будет?render() { ... this.props...}не писал не когда?
>>2362687В реакте в 2022 методы используются только в единичных случаях, все остальное уже на функциях.function Example(props){return <div>{props.value}</div>}
>>2362696Ну так вуе заставляет тебя в метод render лезть в 2022? Кстате необходимость shouldComponentUpdate тебя сейчас может заставить класс написать
>>2362698>вуе заставляет тебя в метод render лезть в 2022?Не заставляет, если ты используешь вуй для генерации статичного HTML. Во всех остальных случаях - заставляет, просто через костыль with, потому что иначе код на вуе побил бы все рекорды по размеру бойлерплейта.
>>2362698> необходимость shouldComponentUpdate тебя сейчас может заставить класс написатьНе заставит. useMemo и useCallback
>>2362700расшифруй пожалуйста. я писал разные многоуровневые меню и, таблицы с динамически подгужаемым контентом в ячейках и всякую другую SPA муру и нигде не использовал render
>>2362708>я писал разные многоуровневые меню и, таблицы с динамически подгужаемым контентом в ячейках и всякую другую SPA муру и нигде не использовал render<template> в твоем вуй файле это ничто иное, как render()
>>2362717Гешефт в том, как туда данные попадают. В рякте - через область видимости, а в вуе/классовом рякте - через контекст.
>>2362655> В JS даже контекст можно реализовать на замыканиях. Можно, и я даже когда-то так делал, когда в JS не было классов, но это плохая идея в сравнении с классами, так как получается код в стиле "функция возвращает функцию", который тяжело читать. Классы читать гораздо проще.> в отличии от реакта - где весь жизненный цикл компонента выполнен в виде функций.Ты случайно не намекаешь на использование хуков вроде useState()? Я видел много хвалебных постов про эти хуки, но когда решил прочесть документацию и разобраться, то ужаснулся. То, что подают как лучшее решение, на самом деле превращает код в лапшу в стиле "функция возвращает функцию, которая возвращает функцию".Вот, например, кусочек из Реакта (отсюда https://reactjs.org/docs/hooks-intro.html ): function Example() {[count, setCount] = useState(0);...А вот, как это выглядит с использованием ООП: class Example {counter = new Counter();render() {...Плюсы кода с ООП: - объект счетчика создается один раз при создании компонента. С хуками же мы пытаемся создать счетчик при каждом рендеринге. Это просто нелогично. - с ООП класс устроен просто и понятно: есть состояние и есть методы для его изменения. С хуками же у нас функции возвращают функции и это просто сложно читать и, как следствие, легко сломать при редактировании.- функции вроде useState используют костыли (порядковый номер вызова), чтобы понять, к какой переменной мы обращаемся. В ООП таких костылей нету.Такое ощущение, что люди готовы усложнять код, лишь бы не использовать ненавистные классы. То, что делается на хуках, ,можно сделать аналогично на ООП, только без костылей.
>>2363329Ой, там в примере кода наверно надо писатьcounter = new Counter(this);а то counter не сможет пнуть компонент, чтобы он обновился.
>>2363329>Классы читать гораздо проще.Когда у тебя в классе есть конструктор и пара методов - несомненно. А вот когда у тебя компонент переваливает за сотню строк все значительно хуже. В функциональщине в таких случаях ты точно знаешь что у тебя за состояние и что за метод его мутировал, а вот в классах...Когда у тебя в состоянии больше одного поля код превращается в лапшу. Попробуй сделать компонент с 3 считчиками и 3 кнопками, которые увеличивают соответствующий ей счетчик и потом посмотри на количество бойлерплейта. Аналогичная проблема происходит, когда ты пытаешься расширить логику компонента, в функциональном компоненте тебе просто надо один раз написать useState, в классовом тебе надо менять единственное состояние компонента, возможно далеко не в одном месте. Аналогичная проблема в компонентах вуя, которые не используют композишн.Ну и на последок: классы из-за своей специфики в JS работают медленно.
>>2363431>>Классы читать гораздо проще.> Когда у тебя в классе есть конструктор и пара методов - несомненно. А вот когда у тебя компонент переваливает за сотню строк все значительно хуже. В функциональщине в таких случаях ты точно знаешь что у тебя за состояние и что за метод его мутировал, а вот в классах...Я ничего не понял. Если ты напишешь компонент на 1000 строк, используя useState, он вряд ли будет легче для понимания, чем ООП-компонент на 1000 строк. Решение тут состоит в том, чтобы не писать слишком большие компоненты, а не заменить ООП на его имитацию через костыли.> Попробуй сделать компонент с 3 считчиками и 3 кнопками, которые увеличивают соответствующий ей счетчик и потом посмотри на количество бойлерплейтаВ ООП мы можем вынести логику подсчета в класс Counter и создать три экземпляра класса:class DemoComponent {#counter1 = new Counter(this);#counter2 = new Counter(this);#counter3 = new Counter(this);render() {...}}Не вижу, чтобы этот код был бы сложнее чем код с использованием useEffect/useState. По моему, он даже проще.Про расширение компонента я не очень понял, где это надо и как тут хуки могут помочь.> классы из-за своей специфики в JS работают медленно. Это же просто неправда. Я буквально вчера читал вот это вот описание, как работа с объектами оптимизируется в вебките: https://webkit.org/blog/10308/speculation-in-javascriptcore/Классы и объекты в JS очень хорошо оптимизируются, если ты не пытаешься на лету создавать или удалять свойства и методы, а определяешь их один раз заранее.ООП наоборот логичнее, так как ты в нем создаешь все поля и методы один раз при создании объекта, а с хуками ты объявляешь поля заново при каждом вызове функции рендеринга. Это просто противоречит здравому смыслу.
>>2374480>навигацию без перезагрузки без многомегабайтного SPA и API не реализовать?SPA это и есть навигация без перезагркузки.
