Нужен ли мне vue, react, angular?

Я просто не понимаю для чего нужен vue

Значит, что ты ещё не готов.

Меньше пробовал react, уже не стал эксперементировать, посмотрел, такое же vue собственно

Да, не совсем.

Тебе - нет. Твоему потенциальному работодателю - может быть. Так что выбирай React. За что ничьтяки будут давать, за то и берись, а все остальное от лукавого. А если работодатель не нужен, используй да хоть JQuery, абы удобно и привычно.

Для того, чтобы была одна страница на весь сайт. И в ней через JavaScript всё перерисовывалось. Работает так быстрей.

Вся html разметка в бесконечных v-if v-html
использую устаревшую концерцию генерации шаблонов на сервере

С Vue не работал, но по опыту с React, ты делаешь какое-то слишком сильное колдунство.

Зачем вообще jQuery в 2019 году? 88 килобайт чистого ненужно. CSS-селекторы и fetch давно в браузерах искаропки. Тот же preact весит 3 КБ, для сравнения. Кто из них тяжёлый фреймворк?

Значит вам не нужны эти трое, раз вы не понимаете зачем они вообще нужны.

тем более ангуляр не то чтобы упрощают разработку, а наоборот тормозят ее, отбирая время на бесконечное гугление и написание костылей

А разве в ЯП-ах бывает по другому первое время? Вот так само и с этими тремя.

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

я привык навешивать события не в тегах, а сразу на множество элементов по селекторам в jquery

Удалять-то хоть листенеры не забываешь после того, как элемент пропал из DOM? Или jquery сам удаляет?

Из перечисленных тобою либ, кажется ни одна не работает с настоящими DOM листенрами. Всё через обертки. А вот в preact реальные листенеры

Меньше пробовал react, уже не стал эксперементировать, посмотрел, такое же vue собственно, реактивность, шаблонны

Хуже. Реактивность в реакт отсутствует. Шаблоны считай тоже. Всё ручками. JQuery нормального человека) А preact, соответственно, Zepto нормального человека

Нужен ли мне vue, react, angular?

Тебе - нет.

Нужен ли мне vue, react, angular?

если у тебя возникают подобные вопросы, значит они тебе не нужны

Наверное я просто не вник в эти инструменты достаточно и у меня ничего не выходитс ними

rtfm, курсы там попроходи

Не очень тебя понял, поясни, пожалуйста. Почему шаблоны отсутствуют в реакте - это я примерно понял: тебе jsx не понравился. Но почему нет реактивность? И почему реакт - jq нормального человека? И что значит " Zepto нормального человека"?

Интересное мнение, но jquery пока все еще удобный слой абстракции, и кроме чисто селекторов там еще возвращается еще кое-что + удобные обвязки вокруг событий и ajax.

Очевидно, что много уже есть решений, но полноценная замена еще видимо в процессе становления. Да, с jquery надо потихоньку уходить (хотя уровень легаси довольно приличный) ибо первая загрузка страницы должна весить как можно меньше (5-12 kb)

Больше разбираешься в устройстве молотка, чем забиваешь гвозди

Лучше все-таки разобраться, чем забивать гвозди кулаком, не? %)

Почему шаблоны отсутствуют в реакте - это я примерно понял: тебе jsx не понравился

Напротив. Я последнее время много пишу на JSX (точнее на TSX). И я не сказал отсутствуют, а «считай отсутствуют». Т.к. являются скорее необычной йзаписью вызова функции в js-файле, нежели шаблоном

Но почему нет реактивность?

Потомучто реактивность это полне конкретная технология (покури mobx или rxjs). И в реакте эта штука отсутствует — в нем обновляешь стейт ручками. Впрочем, хуками и immer-ом это делать вполне удобно

И почему реакт - jq нормального человека?

«jq» потому, что в рамках компонента тебе частенько придется работать напрямую с DOM-элементами и их обработчиками. «Нормального человека», потому что снимает проблему точечного обновления DOM и дает удобную абстракцию «компонент» (который просто функция или класс)

И что значит " Zepto нормального человека"?

Раньше была популярная альтернатива jquery — Zepto. Облегченная, без лишней херни. Чем preact и является по отношению к React

Этот вопрос меня преследует уже год.

Полностью поддерживаю твой пост. Я так задолбался, что плюнул и ушёл писать под винду на шарпике и WPF :)

Тогда понял, спасибо!

Что из перечисленного посоветуете изучать - vue, react, angular?

Зачем через жс все перерисовывать?

CSS-селекторы и fetch давно в браузерах искаропки

А ну ка, через коробку найди .foo > .bar

Я vue знаю больше года. Не понимаю зачем зачем на клиенте генерить html, если данные все равно дергать с сервера

Бесят эти v-onclick, я привык навешивать события не в тегах, а сразу на множество элементов по селекторам в jquery

Так это же одно и то же. Если ты для навешивания событий используешь отдельный селектор, на котором навешено только событие jquery, то какая разница - это .js-click или v-onclick? Тебя именно последовательность букв смущает?

Ну а если этот же класс используется и для оформления, то как ты потом отменяешь или изменяешь события для отдельно взятого элемента?

Удалять-то хоть листенеры не забываешь после того, как элемент пропал из DOM

Зачем?

Зачем вообще jQuery в 2019 году? 88 килобайт чистого ненужно. CSS-селекторы и fetch давно в браузерах искаропки. Тот же preact весит 3 КБ, для сравнения. Кто из них тяжёлый фреймворк?

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

Тебе нужен Elm.

Очень легко жить вообще без рантайм ошибок, получать очень маленький js bundle и самую высокую скорость обновления DOM среди аналогов. Простой как топор. Фронтенд приложения превращаются из постоянно отваливающейся лапши в жёсткую машину состояний, в которой определены все логические ветви.

И как бы тебе не показалось с самного начала, нет, это не Haskell. Typeclasses нету, а с ними зигоморфизмов и приcеданий со штангой. Это Go от функциональщины, просто, практично, ничего лишнего, никакой заумной теории

Почему шаблоны отсутствуют в реакте

Я не говорил что их там нет

Возможно, поэтому хочу понять зачем нужен vue

Ну типа `document.querySelectorAll(‘.foo > .bar’). Чё ещё не можешь найти, мамкину титьку?

Тебя именно последовательность букв смущает?

Да, смущает именно сто v-if, вместо одного

.class(function())

Тебе нужен Elm.

Охота чего то более модного, попсового

Ну-ну. Вообще-то под десктоп уже давно никто не пишет, даже если какие-то дикари где-то и пишут, то точно не на этих уродливых динозаврах вроде Microsoft WPF. Скорее уж на электрон. Десктоп-приложения это каменный век какой-то. Жабу бы еще вспомнили, инсталляторы. Сейчас всё под веб, можно открыть с любого компьютера, с любой точки мира. Бизнес это давно уже понял. Лет 10 уже ни про какой десктоп не вспоминают (и это отлично). Да и средства разработки под веб есть нормальные, это гораздо удобнее и быстрее (как прототипирование так и разработка и поддержка).

Чтобы не размазывать логику между сервером и клиентом, не нагружать бекегд сделанный из говна и палок (питона) лишней фигнёй, отделять API от приложение, снизить latency, не делать богомерзкие перезагрузки страницы, подсасывать новые данные на лету.

Но вообще, иногда ради скорости приходится делать частичный пререндеринг на сервере. А иногда и модифицировать DOM без использования фреймворка.

постоянно отваливающейся лапши

Ничего там не отваливается. У неосиляторов реальных веб-фреймворков вечно кто-то виноват.

Elm

Хрень без задач и спроса. От неосиляторов полноценных Angular/Ract/Vue.

иногда ради скорости приходится делать частичный пререндеринг на сервере

Быдлокодинг такой быдлокодинг...

Учись:

У тебя на 1 твой сервер 1000+ посетителей. Зачем делать на сервере то, что тысяча клиентских компов сделает себе сама? Правильно, не нужно этого делать.

Анонимус дело говорит. Я ещё и бетховены на клиентах молочу. Пока никто не жаловался.

Ну-ну. Вообще-то под десктоп уже давно никто не пишет, даже если какие-то дикари где-то и пишут, то точно не на этих уродливых динозаврах вроде Microsoft WPF. Скорее уж на электрон. Десктоп-приложения это каменный век какой-то. Жабу бы еще вспомнили, инсталляторы. Сейчас всё под веб, можно открыть с любого компьютера, с любой точки мира. Бизнес это давно уже понял. Лет 10 уже ни про какой десктоп не вспоминают (и это отлично). Да и средства разработки под веб есть нормальные, это гораздо удобнее и быстрее (как прототипирование так и разработка и поддержка).

Все правильно сказал. Все до предпоследнего слова... Нет никакой разработки под веб. Дальше прототипирования дело не заходит. Ведь веб это один сплошной прототип в бета версии.

Быдлокодинг такой быдлокодинг…

Оптимизация требует жертв.

Это именно оптимизация, причём с двух сторон. Например: есть у тебя какой-то ресурс, относительно лёгкий и недалеко лежит, если ты его врендеришь на сервере, то пользователь увидит его гораздо раньше, к тому же ты ещё и лишний запрос сэкономишь.

Ещё бывают строгие требования ко времени начала отрисовки контента. Хочешь, не хочешь, а давай сервера докидывай.

Оооо, да у нас тут оказывается непонимание базовых основ веба?

Из чего складывается время начала отрисовки? Правильно из суммы всех задержек. И сколько времени нужно посетителю чтобы заполнить HTML-шаблон информацией из JSON-объекта на современном компьютере? Хотя о чем я - у тебя даже квалификации не хватит замерить это. Не говоря о том, чтобы сравнить с общим временем.

Чего это ты так возбудился, квалифицированный мартышонок ты наш?

Садись за парту, буду тебя учить.

Разберём несколько кейсов:

Генерируем страницу на сервере, отдаём целиком

1. Сервер получает нужные данные и генерирует страницу.
2. Сервер отдаёт страницу.
3. Клиент отрисовывает.

Генерируем страницу на сервере, отдаём потоком

1. Сервер начинает получать данные -> начинает генерировать страницу, сразу отдавая -> клиент уже отрисовывает.

Делаем всё на клиенте

1. Клиент получает страницу.
2. Клиент получает JS.
3. Клиент разбирает JS.
4. Клиент идёт в API за данными.
5. Клиент отрисовывает.

Внимание, вопрос — в каком случае клиент увидит данные раньше?

Ну насчет попсового не знаю, но моднее некуда. Заходишь на сходку в фронтендщиков, сказал что кодишь на Elm, у них прямо смузи от уважения из рук выпадет, а ты как думал

Браузеры ещё и парсят-рендерят HTML по мере его поступления, не дожидаясь полной загрузки. А жабоскрипту надо сначала скачать целиком весь JSON, и только потом начнётся рендеринг.

И вообще по теме: https://carter.sande.duodecima.technology/javascript-page-navigation/

С первым кейсом все понятно.

Кейс два - это чо у тебя за сервер такой, который может отдавать данные кусками? Gatling что ли?

Кейс три - так происходит только при первой загрузке проекта с плохой архитектурой. К чему ты это вообще написал?

это чо у тебя за сервер такой

Сферический в вакууме, просто для контраста добавил. Но, вообще, где-то я такое встречал, не помню где. Длинный лог отдавался или что-то в этом роде.

так происходит только при первой загрузке проекта с плохой архитектурой

А как происходит в проекте с хорошей архитектурой?

К чему ты это вообще написал?

Либо я не уловил твою мысль, либо ты не читал тред.

Хрень без задач и спроса.

У тебя в штанах

Сервер начинает получать данные -> начинает генерировать страницу, сразу отдавая -> клиент уже отрисовывает.

Ну короче ты вопросом не владеешь.

Во-первых, частичный HTML браузер не видит. На практике абсолютное большинство ресурсов не отдают ответ, пока его не построят. Во-многих технологиях/фреймворках начать сгружать частичный ответ - это вообще нетривильная задача. Это даже если бы у тебя существовал «потоковый шаблонизатор», но развитой шаблонизатор потоковым не будет никогда, это понятно. HTML ответ пойдет только когда он будет готов. Кстати далее полностью отстроенный HTML всё равно не начнет уходить мелкими кусочками типа по 100 байт. Это бред, то, что ты говоришь. При желании это можно сделать (правда ты конечно не будешь этим заниматься ты же кукареку просто). Но результат будет хуже чем если дать этим 50кб HTML пройти по сети естественным путем, т.е. в полностью готовом виде и минимальным числом пакетов. Это тупо быстрее будет. И из-за того как сеть вообще работает, и - это другая причина - из-за скорости сети и процессоров.

Во-вторых, без получения CSS ничего никуда не отрисовывается всё равно.

В-третьих, частичный HTML на практике никогда не рендерится из-за структуры современной верстки, ее геометрически нельзя разрешить не закрыв все блоки. Даже когда такие попытки происходят, из-за корректирующих перерисовок (обновлений) это суммарно становится гораздо хуже чем если бы не пытались. Перерисовка частичного html - это эффект пенальти.

А все остальные там твои пункты. Это просто петушиное курам на смех.

Клиент идёт в API за данными.

Ну да, а там видит что-то и с этим уже идет еще раз, а там видит еще что-то и с этим идет опять... Ты чушь пишешь. Кого ты пыташься обмануть? Поставь в равные условия оба варианта.

Клиент получает JS.

Да он уже сразу всё получил, что ты размазываешь.

Клиент разбирает JS. JSON с запонениями для шаблонизации разберется за неизмеримое инструментами время. То есть ноль наносекунд.

Короче, эникейщик, не умничай.

А как происходит в проекте с хорошей архитектурой?

HTTP 2 Server Push / prefetch. Заружаешь страницу, в ответ сразу прилетает страница и сразу ответы на первые запросы которые оно знает ты сделаешь. Потом когда ты делаешь реальный запрос, оно отвечает локально из памяти.

Это на первом визите. А потом просто Etag и HTML/JS/CSS даже не отправляются.

С Service Worker и PWA даже Etag не летит. Он лениво, потом проверит, нету ли апдейтов часом и ещё подумает когда лучше потереть кеш. В самых джедайских вариантах он только на WiFi себя обновит, чтобы тебе траффик в твоём Бангалоре экономить

Кейс два - это чо у тебя за сервер такой, который может отдавать данные кусками? Gatling что ли?

Многие фреймворки/серверы при желании можно заставить. Но он во-первых не будет этого делать, он просто теоретик балабол. Во-вторых ответ у тебя всё равно формируется целиком если это HTML. В-третьих на реальной интернет tcp/ip сети сгружать по чайной ложке будет в итоге гораздо хуже. В-четвертых, в случае с HTML браузеру всё равно этот частичный документ бесполезен. Я очень давно этой темой не занимаюсь, но насколько я помню, какие-то версии IE вообще на некоторых Content-Type частичные ответы только буферизировали и никак не обрабатывали до полного получения. То есть можно в теории всё. Можно стриминг по одной букве сделать даже, можно даже вебсокет без вебсокета изобразить. Но тут у нас о другом разговор. Мы же о шаблонизации изначально.

частичный HTML браузер не видит

Лолшто.

Ты столько распинался над сферическим примером из 2000-х, добавленным по фану, что мне даже смешно на это отвечать.

Поставь в равные условия оба варианта

Они в равных условиях, я говорил изначально о частичном пререндеринге.

Да он уже сразу всё получил, что ты размазываешь

Да, да каждый первый сайт всё бандлит в кучу. Не игнорируй реальность. Но даже если так, за данными всё равно ещё нужно сбегать.

JSON с запонениями для шаблонизации разберется за неизмеримое инструментами время. То есть ноль наносекунд

Ага, то-то современный веб люто-бешено тормозит у всех.

Короче, эникейщик, не умничай

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

HTTP 2

А давай ты не будешь игнорировтаь десяток существования практики клиентского рендеринга до HTTP/2. Было норм, а тут, внезапно, архитектура плохая.

Я, конечно, понимаю, что 2019 и все дела, но до сих пор и куча легаси жива, ты, вроде бы, взрослый дяд, должен понимать.