>>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Гешефт в том, как туда данные попадают. В рякте - через область видимости, а в вуе/классовом рякте - через контекст.
>>2362648Позвольте вмешаться. Не могу пройти мимо.Вы почему-то ограничиваете выбор "хорошим" SPA на Vue и "ужасным" древним jQuery. Как будто нет других вариантов.Но, на мой взгляд, реализация произвольного проекта как SPA имеет множество недостатков: - очень медленная начальная загрузка, требующая передачи огромного объема данных- при этом у разработчиков почему-то не хватает ума впечь нужные данные прямо в страницу, и они делают ajax-запросы- разработчики не умеют правильно проектировать API, чтобы при переходах между страницами отправлялся бы единственный запрос, а не много- страница не отображается при единственной ошибке в любом компоненте, в то время как при использовании HTML ошибка загрузки одного CSS/JS файла или картинки не препятствует отображению страницы- с реактивным стилем написания кода легко сделать так, что приложение будет потреблять много CPU- написание SPA требует по сути написать два приложения: серверное и клиентское. Значительно увеличивается объем работы.- мне не нравится идея делать каждую кнопку отдельным файлом. Это выглядит красиво в концепции, но с таким кодом тяжело работать, прыгая по файлам на 10 строчек. Вы в коде тоже каждую функцию в отдельный файл выносите? - необходимость возиться со сборщиками и упаковщиками кода. На большом проекте, конечно, они все равно понадобятся, но на маленьком можно обойтись и без них.- проблемы с поисковой оптимизациейНаконец, вы предполагаете, что использование реактивных фреймворков обеспечивает лучшую архитектуру. Но я открываю случайный блог и вижу, как автор пишет fetch() прямо в компоненте. Для тех, кто не понимает - это как если бы в PHP вы писали SQL-запросы и всю логику в HTML-шаблоне. Это вы называете лучшей архитектурой? Это же даже протестировать нормально не получится.Или возьмите тот же Redux. Они предлагают сделать гигантский switch на 100 опций и на нажатие любой кнопки клонировать все состояние.То есть, не надо все писать как SPA. Если вы пишете интернет-магазин или развлекательный ресурс с постами и лайками, вам даром не нужен SPA. Если вы хотите отправлять и валидировать форму аяксом, то вам не нужен SPA. Если вы хотите сделать переход между страницами сайта без перезагрузки, то вам не нужен SPA. Если же вы пишете высокоинтерактивное приложение, например, редактор электрических схем или мобильную версию Инстаграма, то вам пригодится SPA.Лично мне из клиентских библиотек понравился preact (это не реакт). Его идея в том, что у него мало возможностей, но зато он весит всего несколько килобайт и позволяет при желании писать компоненты без компиляции и сборщиков. Если у вас есть простая интерактивная форма, то вполне возможно, что реализация одной формы на preact подойдет гораздо лучше, чем переделка всего приложения на SPA на популярном фреймворке, с весом бандлов под мегабайт и сложным процессом сборки.
>>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 не сможет пнуть компонент, чтобы он обновился.
>>2363289>- очень медленная начальная загрузка, требующая передачи огромного объема данныхРешается SSR>- при этом у разработчиков почему-то не хватает ума впечь нужные данные прямо в страницу, и они делают ajax-запросыРешается фреймворками вроде next и nuxt>разработчики не умеют правильно проектировать API, чтобы при переходах между страницами отправлялся бы единственный запрос, а не многоРешается http/2>- страница не отображается при единственной ошибке в любом компоненте, в то время как при использовании HTML ошибка загрузки одного CSS/JS файла или картинки не препятствует отображению страницыВо первых, нужно писать код таким образом, что бы он не выкидывал ошибки. Во вторых, в любом фреймворке есть возможность отлавливать ошибки аналогично try/catch и выводить юзеру соответствующую инфу/производить другое действие/etc. >- написание SPA требует по сути написать два приложения: серверное и клиентское. Значительно увеличивается объем работы.Не согласен. Ты в любом случае будешь писать клиентское приложение (html + js+css) и бэк (любой язык на твой выбор).>- мне не нравится идея делать каждую кнопку отдельным файлом. Это выглядит красиво в концепции, но с таким кодом тяжело работать, прыгая по файлам на 10 строчек. Вы в коде тоже каждую функцию в отдельный файл выносите?Ну так не делай, сделай в одном файле 20 кнопок и экспортируй. Кто тебе запрещает?>- необходимость возиться со сборщиками и упаковщиками кода. На большом проекте, конечно, они все равно понадобятся, но на маленьком можно обойтись и без них.Тут согласен, да. Я так с cmake не заморачивался как с вебпаком.>- проблемы с поисковой оптимизациейРешается SSR>Это вы называете лучшей архитектурой?Нет, выводить отдельную функцию для AJAX запроса и передавать данные из неё в компонент через контекст/провайдИнжекты накмного практичнее.> Это же даже протестировать нормально не получится.То, что fetch можно мокать ты не слышал?>Они предлагают сделать гигантский switch на 100 опций и на нажатие любой кнопки клонировать все состояние.Что ты понимаешь под "всем состоянием"? Тебе никто не мешает вывести в отдельное хранилище логику работы с кнопкой и мутировать только его.>Если вы хотите сделать переход между страницами сайта без перезагрузки, то вам не нужен SPA.Проиграл. Если вы хотите сделать Single Page Application вам не нужен SPA. Сам свои высеры читаешь?> Если вы пишете интернет-магазин или развлекательный ресурс с постами и лайками, вам даром не нужен SPA>Если же вы пишете высокоинтерактивное приложение, например, редактор электрических схем или мобильную версию Инстаграма, то вам пригодится SPA.Тут даже без комментариев.
>>2363329>Классы читать гораздо проще.Когда у тебя в классе есть конструктор и пара методов - несомненно. А вот когда у тебя компонент переваливает за сотню строк все значительно хуже. В функциональщине в таких случаях ты точно знаешь что у тебя за состояние и что за метод его мутировал, а вот в классах...Когда у тебя в состоянии больше одного поля код превращается в лапшу. Попробуй сделать компонент с 3 считчиками и 3 кнопками, которые увеличивают соответствующий ей счетчик и потом посмотри на количество бойлерплейта. Аналогичная проблема происходит, когда ты пытаешься расширить логику компонента, в функциональном компоненте тебе просто надо один раз написать useState, в классовом тебе надо менять единственное состояние компонента, возможно далеко не в одном месте. Аналогичная проблема в компонентах вуя, которые не используют композишн.Ну и на последок: классы из-за своей специфики в JS работают медленно.
>>2363414> Я так с cmake не заморачивался как с вебпаком.Почему бы не использовать cmake вместо вебпака? Нахуя все жрут кактус?мимо
>>2363567Потому что в таком случае cmake будет использовать webpack. cmake - это замена gulp или grunt, а не вебпака.
>>2363725С SSR у него отлично, даже получше чем у рякта с вуем. А вот с изоморфным роутингом дела обстоят не очень...
>>2363567У вебпака лучше интеграция со всякими фронтовыми штуками, вроде SCSS, JSX/Vue, SVG, транспиляции под старые браузеры.
>>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 очень хорошо оптимизируются, если ты не пытаешься на лету создавать или удалять свойства и методы, а определяешь их один раз заранее.ООП наоборот логичнее, так как ты в нем создаешь все поля и методы один раз при создании объекта, а с хуками ты объявляешь поля заново при каждом вызове функции рендеринга. Это просто противоречит здравому смыслу.
>>2363414>>Если вы хотите сделать переход между страницами сайта без перезагрузки, то вам не нужен SPA.> Проиграл. Если вы хотите сделать Single Page Application вам не нужен SPA. Сам свои высеры читаешь?Для перехода между страницами без перезагрузки достаточно добавить известную библиотеку на десяток килобайт, которая перехватывает клики по ссылкам и грузит страницы аяксом. Мы получаем переходы без перезагрузки, отличную поисковую оптимизацию, не написав ни строчки клиентского кода. Вконтакте, если мне не изменяет память, когда-то работал по такой схеме.А ты, судя по ответу, думал, что навигацию без перезагрузки без многомегабайтного SPA и API не реализовать? Можно только пожалеть тех, кто тратит деньги и время там, где это не требуется.>>- очень медленная начальная загрузка, требующая передачи огромного объема данных>Решается SSRМы придумали себе проблему и героически ее решаем.>>разработчики не умеют правильно проектировать API, чтобы при переходах между страницами отправлялся бы единственный запрос, а не много> Решается http/2Это не поможет, если следующий запрос зависит от предыдущего.> Не согласен. Ты в любом случае будешь писать клиентское приложение (html + js+css) и бэк (любой язык на твой выбор).Да, только вывод данных на стороне сервера проще, так как нам не надо делать никаких аякс-запросов, нам не нужно никакое хранилище, не нужно поддерживать его в корректном состоянии ит.д. То есть, вывести профиль пользователя на сервере в разы проще, чем на клиенте.
>>2374485А если тебе нужно вывести профиль пользователя, чат и проводки из бухучета, а на другой странице чат, баланс и интерактивные видоуроки по системе, а если нажимаешь на кружочек сверху, то чат уезжает в угол и счезает , а вместо чата открывается профиль пользователя, а если в проводках нажмешь на символ человечка, то открывается модальное окно с исхдящим звонком к коллеге, а если коллега начнет редактировать провоки у себя, то ты будешь видеть у себя изменения... абырвалг ... абырвалг ...
>>2374480>навигацию без перезагрузки без многомегабайтного SPA и API не реализовать?SPA это и есть навигация без перезагркузки.
>>2374485>достаточно добавить известную библиотеку на десяток килобайт, которая перехватывает клики по ссылкам и грузит страницы аяксом. Мы получаем переходы без перезагрузки, отличную поисковую оптимизацию, не написав ни строчки клиентского кода.что за библиотека?
>>2386160Тебе браузер пишет - слишком много редиректов. Скорее всего твой сайт редиректит сам на себя.Открой инструменты разработчика в браузере (F12) на вкладке Network, перезагрузи страницу и посмотри, что там выведется.>>2386389Пиджакс, на vanilla js, 6 Кб в сжатом виде. https://github.com/MoOx/pjaxМеня удивляет, что люди не знают про такую библиотеку и начинают изобретать велосипеды на реакте.
