Есть ли реальный профит от использования актуальных фронтенд-технологий?
Вопрос несколько философский, заключается в - "Зачем мы напрудили столько технологий, и не мешают ли они нам?"
Предыстория:
В 2014-м году, мы делали сайтец, все довольно быстро, данные на странице динамические где нужно (аяксы или пуш/пуллы), а сайт сделан за пару недель с нуля. Не требуется никаких билдов, сборок, зависимостей, дорогих разработчиков - два битриксовых "фуллстека" за менее чем 100 рублей. Сайт грузится за 0.9 секунды.
Другой пример. В 2016-м году, делали нечто, что потом начали люди называть SPA - но за счёт аяксов, которые грузят что нужно. При этом сохраняется структура страниц на сервере, и нет и не было проблем с индексацией. Опять же, никаких зависимостей, дорогих разработчиков (делал один человек за 10 дней), сайт грузится за 0.7 секунды, потом "переходы по страницам" происходят за примерно 0.4 секунды.
И вот теперь смотрим на разработку сайта в 2024 году, и что нам это даёт:
Проблемы:
1. Нужны отдельно фронтендеры, отдельно бэкендеры - ибо они обрасли кучей технологий. И в целом невозможно их все знать и использовать достаточно хорошо. Следовательно тут уже стоимость разработки х2.
2. Стоимость самих специалистов выросла. И не только потому что все цены растут, дело в том, что (цены условные): знаешь только ЖС - 50 тысяч, ЖС и вью - 100 тысяч, ЖС, вью, вайт, вьюэкс - 150 тысяч и так далее. Следовательно - стоимость разработки еще выросла, плюс сложнее стало найти специалиста.
3. Разношерстность стэков. Раньше были только ЖС для фронта в общем то. И там уже нужна jquery или нет. А тут: реакт, вью, бб, накст, некст, нюкст... Следовательно, усложнился поиск специалиста с нужным стеком примерно в х3 раза.
4. Чтобы поменять буковку на фронте, нужно запускать сборщики, выкатывать билды и тд. Раньше - поменял в коде - отправил в прод = готово. Следовательно время разработки/правки увеличилось примерно х1.25.
5. Всяческие менеджеры библиотек, сборщики и тд (всяческие вебпаки, бабелы, вайты, композеры) - были призваны упростить работу со сборкой и зависимостями. Вот только в 2014-м году я с ней (проблемой такой) вообще не встречался, за более чем 10-ти летний опыт разработки на разных языках. В итоге тут как Энакин Скайуокер вышел.
Плюсы:
1. Стильно, модно, молодёжно. Других не могу придумать. Вроде бы как должно работать быстрее, но практика этого не показывает (или настолько незначительно, что конечному пользователю - пофиг, будет работать аякс или вьюшная реактивность).
2. Говорят что проще делать связку с данными с бэка. Но пока вижу обратную картину. В лохматых годах - брали и делали интеграции за пару часов. Сейчас постоянные конфликты разработчиков и кода.
Собственно, а зачем это всё нужно, если профит, кажется - нулевой, а расходов - прибавилось раз в 10 по итогу?
Вот от фронтовых фреймворков верстки - профит заметен был (тот же фаундейшн, бутстрап и тд) - действительно ускоряло и упрощало жизнь.
Раньше - поменял в коде - отправил в прод = готово.
А что принципиально поменялось-то?
Внес правки, запушил и все. Дальше
либо автоматика соберет и задеплоит,
либо вы выполните команду npm run build и по старинке зальете по фтп на прод.
были призваны упростить работу со сборкой и зависимостями
раньше вы скачивали необходимые библиотеки, вручную подключали их на страницы и т.п.
сейчас вы просто выполняете npm install super-liba и работаете.
Почему вы не жалуетесь на бэк-фреймы? На композер? Зачем эти усложнения, когда можно писать на ванильном пыхе, а библиотеки реквайрить вручную?
На мой взгляд, необходимо учесть не только интересы бизнеса, но и тех, кто выполняет задачи для этого бизнеса.
Представьте среднестатистического разработчика, который хочет развиваться. Думаете ему интересно писать код в устаревшем "стиле"? Думаете ему нравится тянуть зависимости ручками? Ответ очевиден. Каждый, кто хочет развиваться - будет изучать новые удобные инструменты разработки и с течением времени внедрять их в свою работу.
К тому же, ваш опыт заканчивается на двух небольших проектах, которые, по вашим словам делались по пару недель. Окей, для ваших проектов, скорее всего и не нужны все эти новомодные фреймворки. Берите Битрикс или вордпресс и запускайте. Но если речь идёт о сложных проектах, в которые необходимо заложить масштабируемость, безопасность и самое главное предсказуемость - то конечно обойтись без новомодных технологий просто не получится. И это связано не только с трендом, но и с тем, что если ваш олдскульный разработчик решит покинуть Вас, найти нового под ваш проект с ванильным js или php будет достаточно трудно, потому как мы выяснили - каждый(нет) разработчик стремится развиваться и внедрять новые технологии в свой стек.
Андрей Колесов, спасибо за развернутый ответ) а то в основном тут банальные обиды.
Нет, мой опыт включает и разработку крупных хайлоад-проектов с разными архитектурными решениями, набором ЯП и тд.
Что касается развития - согласен, изучать это и пробовать - зачастую приятно, интересно, увлекательно. Однако для бизнеса, который является конечным выгодополучателем от продукта, и собственно для чего всё и делается, желание "поиграться" разработчика на реальном продукте за деньги бизнеса - не слишком интересно.
Ну, представляете себе например, вам нужно построить дом. Есть технологии, которые работают, они быстры, качественны, удобны. Тут вам ваш строитель говорит - "не будем больше использовать химические анкеры для тяжелых кронштейнов, будем делать кастомные крепления из десятка гвоздей, их переплавлять в полевой печи (которую я буду делать из глины), а затем нужно будет помедитировать, результат будет впрочем такой же, но сейчас это модно. И чтобы я всё правильно сделал (ведь переплавить гвозди в полевой печи - сложно, платите мне зарплату в 3 раза больше.".
Подозреваю, что любой адекватный прораб послал бы такого строителя. Ну зачем ему терять время и деньги, для достижения аналогичного результата, только дольше и дороже? Только чтобы строителю было прикольно делать печь из глины и плавить железяки? Сомнительное решение.
Смотрите, я активно использую контейнеризацию, оркестраторы, пакетные менеджеры, балансировщики, различные виды автотестирований, мониторингов и многое другое из современных технологий. Потому что это быстро, удобно, повышает масштабируемость.
Ну то есть, тот же контейнер - это божество, когда делаешь сложносочиненное приложение, с кучей сервисов. Без него у тебя расходы были бы выше, и надежность ниже. Смотрим дальше, над контейнерами нужен оркестратор, иначе с ума сойдешь и все сломается. Значит снова - расходы снижаются, надежность повышается. Без того же helm'a было бы всё дольше и менее удобно.
А вот конкретно по фронтовым (в основном) модным темам - у меня большие вопросы. Так как ни я в практике, ни кто либо из комментирующих - не наблюдал реального профита.
Так как в основном все комментарии - это, как я уже сказал, вопли "обиженных", типа "вот и работай без них!". Я задал конкретный вопрос, замечал ли кто конкретный профит для бизнеса, судя по всему - его нет. Это грустно.
Иван Веков, А как по вашему строители домов пришли к быстрым, удобным и качественным технологиям? Сразу были? Так вот если бы строители ничего нового не пробовали то так бы и строили дома из глиняных кирпичей, обожжённых на солнце.
Вебу 30+ лет, и если мы не будет пробовать что-то новое, как пробовали строители, то так и будем в глине копаться.
Андрей Колесов, согласен, однако многие вещи, популярные ныне в вебе, выглядят так, что это скорее путь назад, нежели вперёд. То есть если делать аналогии со строительством, то ситуация примерно такая:
Есть технологии строительства домов, они работают, эффективны, относительно качественны - в основном либо монолит, либо панелька. И тут прибегает новый прораб, говорит:
"Сейчас всё будем делать по-новому!"
1. Сначала делаем монолитный дом в одном месте
2. Разрезаем его на панельки
3. Перевозим на место стройки
4. Собираем панельный дом
И вот сначала делают все работы, что предшествовали монолитному строительству. Затем ищут инструменты чтобы разрезать дом на удобные блоки, при этом часть конструкций ломается. При перевозке теряем время, повышаются логистические расходы, некоторые блоки при неаккуратной перевозке опять ломаются. При сборке дома из кусков, они ставятся не правильно и оказывается что на предыдущих пунктах поломалось еще больше чем думали. Приходится всё переделывать несколько раз.
Для чего? Да кто его знает. Просто интересно было попробовать. Профит? Можно из блоков строить дома. Разве панелька не для этого? "Ну, это не современно".
Иван Веков, Какие ныне популярные вещи в вебе кажутся вам ведущими назад? Отвечать на вопрос есть ли профит проще, если разбирать конкретные примеры технологий
Андрей Колесов, в целом - очень многое, от пакетных менеджеров, фреймворков до инструментов сборки и тд.
Ну вот как частный пример, который очень плотно коррелирует с абстракцией про стройку:
Задача:
Отредактировать форму в веб-интерфейсе.
1. Как это было раньше:
Программист (не фронт, а общей направленности, ведь раньше не требовалось разделение) подключился к серверу, поменял файл шаблонизатора, поменял css. Готово
2. Чуть позже:
Программист сделал изменения у себя, запушил в систему контроля версий, сработал деплой (который банально заменяет файлы), готово.
3. Сейчас:
Фронтенд-разработчик выкачивает себе исходники из репозитория, делает всякие yarn/npm install, ловит тысячу ошибок из-за недоступности какой-нибудь зависимости, депрекейтедов, проблем с lock файлами и тд. Допустим, победил. Пошел искать среди роутеров, компонентов, ассетов и тд именно то что ему нужно, нашел, отредактировал. Чтобы проверить - запускает бабели, галпы, вебпаки. Хорошо если не ловит ошибок. Проходит вечность. Проверил, понял что не так немного, поправил. Запускает бабели, галпы, вебпаки. Ждёт. Все ок, отправляет в гит. Запускается деплой - поднимается билдовый контейнер, который опять же запускает yarn/npm, все молятся чтобы ничего не крашнулось. Проходит вечность, образ выкатывается, и тут мы замечаем опечатку... Начинается вечность №2.
То есть в данном примере:
Минусы:
1. Отдельный спец под фронт и бэк, иначе сложно разбираться с ворохом технологий. Хотя можно, не спорю.
2. Зачастую требуется подключение девопс-специалиста, чтобы помочь с ошибками сборки
3. Очень долго ждать всех процессов
4. Даже в случае сверх-факапа, нельзя прибегнуть к очень плохой, но раз в тысячелетие действенной идее "поправить на проде"
5. Новым разработчикам сложнее начать работать. Кто-то не знаком с архитектурой, кто-то не умеет пользоваться именно этим пакетным менеджером, использовал другой сборщик и так далее.
Иван Веков, То есть получается что пакетные менеджеры и те же dev-dependencies вообще не нужны?
Да, я понимаю, что многие разработчики, особенно начинающие, тянут за собой зависимости на каждый "чих". Но я не представляю как можно делать современный фронтенд без автопрефиксера для css. В ручную все вендорные префиксы писать? Как работать без prettier или eslint в команде, хотя бы из 2 человек? Как сжимать css и js при доставке в прод? И так далее.
И при этом мне также не понятно откуда у вас заблуждение о том что при установке зависимостей возникает куча проблем? А уже тем более о какой "недоступности" пакетов вы говорите? npm еще с 2016 года запретил разработчикам опен-сурс проектов удалять их, если они пользуются спросом.
Пошел искать среди роутеров, компонентов, ассетов и тд именно то что ему нужно
А в первом и втором варианте не надо искать то что ему нужно? Если у проекта хорошая архитектура, то что в 1-2, что в 3 вариантах это займёт одинаковое время.
Ну и современный CI/CD работает отлично. И не надо каждый раз молится о том что что-то отвалится.
И давайте закончим вашим примером стройки:
Давайте фундамент и стены будет бэкендом, и это делают одни люди.
А вот ремонт в подъезде, вставка дверей и окно это фронтенд, и это делают другие люди.
И если криворукий бэкендер вместо стандартного дверного проёма сделал его на 5см Уже, решать это будет фронт.
Также и в вебе, если у Вас хорошие специалисты, которые не тянут лишних зависимостей, которые умет настраивать сборщики, докер, CI/CD то никаких проблем, которые у вас возникли в пункте 3 вы никогда не получите.
Я думаю у вас был негативный опыт связанный с не компетентными разработчиками
В 2016-м году, делали нечто, что потом начали люди называть SPA - но за счёт аяксов, которые грузят что нужно. При этом сохраняется структура страниц на сервере, и нет и не было проблем с индексацией.
Проблемы с индексацией есть и сейчас, чтобы там не заявляли ПС, а в древние 2016 года они были выражены в несколько раз сильнее. То, что Вы проблемы не замечали - не значит, что их не было.
Вот от фронтовых фреймворков верстки - профит заметен был (тот же фаундейшн, бутстрап и тд) - действительно ускоряло и упрощало жизнь.
Ускоряет жизнь тем, кто не умеет в вёрстку, остальным - замедляет.
1. Стильно, модно, молодёжно. Других не могу придумать. Вроде бы как должно работать быстрее, но практика этого не показывает (или настолько незначительно, что конечному пользователю - пофиг, будет работать аякс или вьюшная реактивность).
На определенном этапе разработки, стоимость поддержки проекта на чистом js начнёт обгонять проект на react/vue. Пользователю будет конечно пофиг, т.к. он не найдёт в ПС Ваш SPA сайт.
Собственно, а зачем это всё нужно, если профит, кажется - нулевой
Для ускорения разработки, а ключевое слово здесь "кажется".
P.S. в некоторых ситуациях действительно быстрее и дешевле написать некоторые функции на чистом js и не тащить весь react стек в проект, но это больше исключение, чем правило.
Проблемы с индексацией есть и сейчас, чтобы там не заявляли ПС, а в древние 2016 года они были выражены в несколько раз сильнее. То, что Вы проблемы не замечали - не значит, что их не было.
Да нет, проблемы с индексацией, как раз появились с приходом попыток сделать SPA в том виде, в котором он есть сейчас - на базе "реактивных фреймворков", которые потом обросли костылями и велосипедами, чтобы эту дырку закрыть всякими SSR-ами. У нас был другой подход (с перехватыванием запросов, если включен JS), если JS выключен, или юзер=бот, для него сайт работал без режима SPA, и все страницы имели свои эндпоинты. Так что тут мимо, как и часть вашего шутливого потока далее)
Пока что ни от одного комментатора, кроме обиды, не услышал какой-то конкретики, аргументации. Не знаю уж почему всех так обижает предположение, что современные фронтовые фреймворки приводят нас в тупик, и нельзя об этом нормально порассуждать)
P.S. в некоторых ситуациях действительно быстрее и дешевле написать некоторые функции на чистом js и не тащить весь react стек в проект, но это больше исключение, чем правило.
Вот эта мысль уже больше мне нравится, но, складывается ощущение, что скорее - наоборот. Возможно, есть случаи, когда применение Vue/React/Angular - обоснованно, но пока не понятны эти критерии...
Блин, автор все всегда упирается в то, что вы хотите от сайта, если вам простой лендинг, то пилите на чем хотите, можете php+js+html без всяких компиляторов прикрутить - это будет проще и быстрее. Если же вам нужно что-то типа интернет магазина по типу wildberries то вы явно запартитесь только со структурой файлов, а потом с поддержкой. Все зависит от ваших хотелок и назначения.
Сайт пишется для того, чтобы закрывать потребности бизнеса.
Сайт из 2014 года закрывал потребности бизнеса в 2014 году, и не закрывает их в 2024 году.
Вам правильно сказали, что вам никто не мешает сейчас за три дня сделать сайт на технологиях 2014 года, но сможете ли вы конкурировать с сайтом на технологиях 2024 года?
Сердцем, я вас полностью поддерживаю, и считаю что бОльшая часть "современных технологий" -- бесполезная ерунда. Но раз бизнесы платят в десятки раз больше, значит им это выгодно. Склонен им верить, потому что у них эти данные получены:
а. От аналитиков, которые собирают статистику и AB тесты
б. Из бухгалтерской отчётности, в которой растут прибыли год от года, а значит, принимаемые ими решения верны.
Сайт из 2014 года закрывал потребности бизнеса в 2014 году, и не закрывает их в 2024 году.
Это верно, но мне кажется в большей степени из-за развития маркетологов и в целом понимания что такое "сайт" и что он умеет. Конечному пользователю то пофиг, Vue там или Jquery, главное чтобы работало.
Но раз бизнесы платят в десятки раз больше, значит им это выгодно.
1. Бизнесы стараются быть в тренде. Если у тебя в компании есть психолог корпоративный, а у соседа - нет, значит ты лучше. Если у тебя есть печеньки в холле - ты лучше. И так далее. Не всегда это объективно, или про реальные потребности, это больше про имидж.
2. Рынок и тренды диктуют свои правила бизнесу порой. Все фронтенды сейчас изучают вью/реакт, других почти нет. А если находятся - то стоят дешевле и бизнес думает: "хм... значит этот плохой, раз дешевый, еще и каких-то вью не знает, что бы это ни было". И берет более дорогого. Это знаете, как гелик. В городе от него нет смысла, он жесткий, неудобный, много жрет. Но он модный - поэтому в центрах крупных городов - их навалом, но объективно, в 5 раз дешевле можно взять авто лучше по всем параметрам, важным для города - отделка, комфорт, музыка, приблуды.
Вам правильно сказали, что вам никто не мешает сейчас за три дня сделать сайт на технологиях 2014 года, но сможете ли вы конкурировать с сайтом на технологиях 2024 года?
Вот пока что не видел проблем в этом, если честно. У меня сейчас есть несколько проектов, несколько в куберах, с вьюхами и кучей всего. И сейчас мы запускаем новый проект, для него сайт разрабатываем по-старинке, вот прямо всё самое простое, делают простые разработчики (где-то откопали толковых, при этом не ушедших в тренды), и знаете, пока на старте сложно оценить, но расходы по сравнению с другими проектами - мизерные, а посещаемость и профит - по приросту - не меньше. Разработчиков, что удивило, нашли крайне быстро (вопрос занял меньше недели) и за реально 1/3 оплаты от того, что платим на других проектах.
1. Бизнесы стараются быть в тренде. Если у тебя в компании есть психолог корпоративный, а у соседа - нет, значит ты лучше. Если у тебя есть печеньки в холле - ты лучше. И так далее.
Иван Веков, как правило это способ экономить на ФОТ. Гораздо дешевле нанять психолога по корпоративному тарифу, заплатив 1 раз за много сотрудников с большой скидкой или купив печеньки оптом, чем добавить стоимость разового визита к этому же психологу или розничной стоимости печенек к зарплате, а сверху заплатить НДФЛ, ФОМС, ФСС, ПФР и т.д. Можно конечно этого всего совсем не платить, вот только выгоревший к чертям сотрудник имеет производительность на уровне нуля, а з/п ему нужно платить ту же.
Все фронтенды сейчас изучают вью/реакт, других почти нет. А если находятся - то стоят дешевле
Есть фронтенды, которые знают только вью/реакт, а за их пределами толком ничего не могут - такие стоят дешего. Есть фронтендеры которые умеют голый TypeScript/JavaScript, а изучить react/vue/svelte/angular/ember/любую другую новомодную хрень для них дело 1-2 вечеров, такие стоят дорого. Те кто не в состоянии освоить хотя бы 1 фреймворк/либу сегодня не стоят ничего и никому не сдались ибо такое встречается только среди тупых вкатунов, которые пришли в IT за "много платят", вот только изучить что-то они не готовы.
Это знаете, как гелик. В городе от него нет смысла, он жесткий, неудобный, много жрет
Вы не поверете, в городе от гелика гораздо больше пользы чем за городом. Если за городом бездорожье, то там лучше уаз или нива. А вот в городе, там где пузотерки встают во дворе напротив друг друга и спорят, кто должен сдавать назад и пропустить, гелик объезжает их по сугробу и не парится, много раз такое видел в СПб.
Иван Веков, как правило это способ экономить на ФОТ. Гораздо дешевле нанять психолога по корпоративному тарифу, заплатив 1 раз за много сотрудников с большой скидкой или купив печеньки оптом, чем добавить стоимость разового визита к этому же психологу или розничной стоимости печенек к зарплате, а сверху заплатить НДФЛ, ФОМС, ФСС, ПФР и т.д. Можно конечно этого всего совсем не платить, вот только выгоревший к чертям сотрудник имеет производительность на уровне нуля, а з/п ему нужно платить ту же.
Ну, не самый подходящий пример привел, надеялся что читающие поймут суть. Допустим не психолог, а традиция жертвовать деньги в фонды, или поддерживать спорт в РФ, или содержать ягуара в зоопарке. Ну какие-то траты, которые не влияют на прямую прибыль, но якобы показывают что компания трендовая и хорошая. Так и с технологиями зачастую - модно микросервисы, то и бизнес услышав краем уха что это тренд, будет пропихивать это туда, куда не надо вообще. Помню в 2018-м, когда в целом микросервисы были дорого и сложно, одна компания заказала "лендинг на микросервисах". Ну потому что тренд. Также примерно, ощущается и использование вышеупомянутых мной технологий.
Есть фронтенды, которые знают только вью/реакт, а за их пределами толком ничего не могут - такие стоят дешего. Есть фронтендеры которые умеют голый TypeScript/JavaScript, а изучить react/vue/svelte/angular/ember/любую другую новомодную хрень для них дело 1-2 вечеров, такие стоят дорого.
Я не о том, а про то, что фронтендеры, которые знают как раз голый тайп/жс - стоят зачастую дешевле чем ребята, которые уперлись в один вью или реакт. Это к сожалению, диктует получившаяся на рынке "петля". Ну и найти хорошего спеца, без ориентации на фреймворки - становится сложнее.
Вы не поверете, в городе от гелика гораздо больше пользы чем за городом. Если за городом бездорожье, то там лучше уаз или нива. А вот в городе, там где пузотерки встают во дворе напротив друг друга и спорят, кто должен сдавать назад и пропустить, гелик объезжает их по сугробу и не парится, много раз такое видел в СПб.
Можно купить ту же Ниву, в городе, в таком случае) отлично проедет через сугроб. Также впрочем как и Nissan Patrol, TLC, Escalade, QX80, H5, H9, 500, LX и многие другие, в разы более комфортные автомобили, которые стоят в 2-5 раз дешевле) Так что в итоге и сэкономите и больше комфорта получите.
Полагаю, среднестатистический корпоративный сайт/интернет-магазин имеет скорее интерфейс с элементами js, нежели интерфейс полностью завязанный на js.
Для большинства задач реактивные фреймворки не нужны.
Если разобрать типовой интернет-магазин.
Слайдеры, анимации, эффекты проще всего делаются плагинами на jquery.
Всплывающие формы обратной связи вполне нормально на jquery.
Фильтры подбора продукции - имело бы смысл делать на реактивных фреймворках, но обычно фильтры уже встроены в саму CMS. Тот же умный фильтр в Битриксе на столько умный (выводит только такие наборы значений, по которым можно найти товары, опирается на встроенный в CMS механизм) что его переделывать дорого неоправданно.
Пока у меня ощущение такое, собирать сайт целиком на реактивных фреймворках профита мало, а отдельные элементы, к примеру, какой-нибудь нетиповой и нестандартный фильтр подбора со своей логикой - вполне хорошо.
Кривоватое у вас ощущение. Начните с того, что любой современный сайт должен быть адаптивным и отзывчивым. Это уже скрипты.
Потом - перечисленная мелочевка делается на чем угодно, особенной разницы между плагином на jquery и шаблоном на vue, например, в ней и не разглядишь.
А вот фильтр вроде яндекс-маркетовского, например - когда выведены категории, и при выборе одной из них этот самый фильтр оперативно перестраивается под присущие этой категории поля - через Битрикс задергает сайт запросами и перезапросами, будет люто тормозить сам и вообще успешно переложит нагрузку с пользовательской машины на сервер. Умно, чо.
Adamos, У Битрикс есть некий фасетный индекс, это какой-то кэш полей и значений для фильтра, что как-то оптимизирует процесс.
Не думаю, что было бы хорошей идеей передавать все десятки тысяч значений полей фильтра в разнообразных категориях яндекс-маркета на клиент, чтоб разруливать на клиенте без запросов к серверу.
koder_1, результаты поиска не бывают в тысяче разных категорий. Их максимум десяток.
Но при этом они могут быть выбором между техникой, мебелью и продуктами...
Если говорить конкретно про фронтенд, то главные плюсы от использования библиотек и фреймворков:
Разделение на компоненты, которые можно переиспользовать, а значит ускорить последующую разработку и доработку, улучшить масштабируемость
Лучшая работа с перерендергином компонентов (обновлением частей страницы), когда может обновиться не вся страница, а только её часть. Это даёт лучшую скорость реакции на действия пользователя, что улучшает его впечатление от работы с сайтом. И это особенно критично, если идёт работа с какими-то частями со сложными вычислениями на странице.
Плюс-минус схожая архитектура между приложениями, написанными на одном фреймворке. Что упрощает работу команды над проектом и даёт возможность быстрее вкатываться в работу новичкам.
Широкий выбор дополнительных подключаемых библиотек, реализующих практически что угодно по вашему запросу на проекте. Если особая кастомизация решения не нужна, то подключается всё мгновенно и у вас на сайте хоть диаграмммы рисуются, хоть таблицы, хоть формочки. Да, раньше для этого использовался, например, тот же jQuery (хотя что уж раньше, они недавно даже новую версию выпустили), но он тяжелее, содержит много ошибок и не соответствует новым стандартам. А стандарты - это не для моды, это безопасность, скорость работы и кроссбраузерность.
Это возможность использовать централизованные менеджеры состояний, когда у тебя всё хранится в одном месте, а не где-то там, плюс кэшируется, обрабатывается там же и так далее.
Отделение бизнес-логики от UI, что даёт возможность править их независимо, а не переписывать весь модуль, когда модель ответа немного поменялась.
Зачастую лучшая поддержка и обновление фреймворков и библиотек, документация, что является не только вопросом удобства, но и безопасности. Устаревшие технологии могут быть очень уязвимы.
Если говорим про сборщики, то возможность всё кастомизировать настолько, чтобы не приходилось раскладывать руками по папкам и чтобы вся сборка, которая может быть большой, автоматически чистилась, минимизировалась и делилась на части. А это существенное ускорение загрузки у пользователя.
Не говоря уж про совсем "модные" нынче микрофронтенды, когда каждая часть приложения может писаться и поддерживаться независимо друг от друга и, при желании, на любых фреймворках, в том числе и на ванильном JS.
В общем, можно много чего ещё привести, что положительного дало бизнесу развитие фронтенда и переход на фреймворки, модульность, сборщики и автодеплой. Что-то для Вас конкретно будет более существенным, что-то совсем не важным или не понятным. Но главное, что каждая из технологий, каждая часть стека должна выбираться последовательно и мере необходимости бизнесу. Для этого начинать работу над проектом должен высококвалифицированный специалист с пониманием архитектуры и требований к масштабируемости и безопасности.
Вполне возможно, что для визитки хватит простого HTML+JS, для витрины товаров можно использовать Tilda, для простого интернет-магазина или корпоративного портальчика - Bitrix или WordPress. Но часто бывает, что у бизнеса есть или появляются особые требования, аппетит растёт по мере работы сайта, вот тогда выясняется, что необходимы фреймворки, позволяющие гибко реализовать практически любые кастомные решения.
Отличный ответ, благодарю! Хотел бы прояснить пару моментов:
1. "Лучшая работа с перерендергином компонентов (обновлением частей страницы), когда может обновиться не вся страница, а только её часть. Это даёт лучшую скорость реакции на действия пользователя, что улучшает его впечатление от работы с сайтом. И это особенно критично, если идёт работа с какими-то частями со сложными вычислениями на странице."
Чем хуже вариант с аяксом? Мы также обновляем часть страницы, можем её предварительно загрузить, чтобы не ждать полной загрузки по кнопке (если уже есть данные), можем получать их "на лету" и так далее.
2. "Зачастую лучшая поддержка и обновление фреймворков и библиотек, документация, что является не только вопросом удобства, но и безопасности. Устаревшие технологии могут быть очень уязвимы."
Я бы это всё же отнёс к минусам, так как в случае обнаружения уязвимости - надо обновить например и версию какого-нибудь сборщика (или чего-то, что использует фреймворк) и самого фреймворка. В случае с его отсутствием - обновляем только сборщик.
Спасибо за ответ. Но ведь:
1. Для начала разработки, требуется скачать фреймворк, npm'ы, ноджс, все это подготовить.
2. Для сборки - нужно запускать... сборку)
3. Чтобы внести правку - нужно перезапускать сборку (ну банально npm install/run build и тд)
Да используйте что хотите, кто Вам запретит то?
Только не удивляйтесь, если однажды наступит бас-фактор и Ваш разработчик за 50 тыс уволится, уйдёт на пенсию или ещё чего хуже... А нового найти на это легаси будет проблема, мало кто будет готов, а те кто готов запросто могут запросить з/п 500к+.
Я бы может согласился, но просил бы лям... Хотя скорее всего нет, нервы дороже бабла...
Я бы может согласился, но просил бы лям... Хотя скорее всего нет, нервы дороже бабла...
Хм... а в чем нервы? Чистый жс, мне кажется более понятен, нежели путешествия по компонентам и либам какого-нибудь реакта.
Ну и в итоге, как показывает практика, если увольняется разработчик за 50 тысяч, находится другой за 50 тысяч) В комментариях к ответу пользователя Karington описал ситуацию недавнюю.
Ну и легаси на чистом жс, опять же, как я видел - проще к пониманию, нежели легаси на vue. Всё получается нагляднее.
Без TypeScript он непонятен от слова совсем... Нужно долго и упорно копать и выстраивать связи, а если это ещё и самописное поделие - то задача усложняется в разы. Ну и большой вероятностью там лапшекод...
если увольняется разработчик за 50 тысяч, находится другой за 50 тысяч
За 50 тысяч сейчас даже джуны работать не идут, которых много, за эти деньги можно найти разве что стажера совсем без опыта. Есть конечно исключения, но я бы 10 раз задумался, а не рисованый ли там опыт, раз кандидат так мало просит. А если даже не рисованный, то опыт опыту рознь, можно 10 лет одну кнопку красить и ничего больше не уметь, а можно за год-другой в нескольких проектах поучаствовать и кучу граблей разобрать.
Вот только и джуну и тем более стажеру без более опытных коллег делать в компании нечего, только плодить лапшекод продолжать.
Ну и легаси на чистом жс, опять же, как я видел - проще к пониманию, нежели легаси на vue. Всё получается нагляднее.
Любое легаси тяжело к пониманию и требует высокой ментальной нагрузки, на то оно и легаси. Проще к пониманию код становится только если над ним опытный архитектор поработал, от фреймворка это не зависит.
Вы же сами ответили на вопрос.
Вы писали "сайтец".
Если для вашей задачи достаточно взять одного разработчика, который напишет сайтец - пишите как вам угодно.
Главное позаботиться, что если этот разработчик уйдет, вы сможете найти другого, готового поддерживать используемые технологии.
Если же вы пишете сложный продукт, для которого нужно человек 5-10, им нужно согласовывать и стандарты и стек технологий, и чтобы упростить - не пишут велосипеды, а берут какой-то готовый движок.
А если вы сервер хостите где-то в облаке, следует обратить внимание, будет ли этот движок обновляться, или через 5 лет облако скажет "мы едем на новую версию ОС, где ваш движок не работает, переезжайте на другую версию или другой движок"
Совсем другой вопрос что дейсвительно существует море "усложнятелей", но об этом полно и анекдотов и реальных историй. Так что в данном случае нужен архитектор или грамотный менеджер, который понимает и необходимости бизнеса, чтобы работать и адаптировать ТЗ, и понимает риски со стороны технологий, чтобы выбирать или одобрять на чем будет это все написано, где хоститься и так далее.
Ну на самом деле "сайтец" - это образно. По факту это был корпоративный портал, с кучей всяких особенностей, типа согласования бизнес-процессов, динамическая карта офиса с поиском сотрудника и изменением рабочих мест, заявления на отпуска/выдачу расчётных листочков и тд. Ну и многие разделы, как те же бизнес-процессы - были динамические, то есть когда меняются данные на сервере - меняется и отображение на фронте. И там хватило 2-х обычных битриксоидов со средними знаниями в JS/Jquery, PHP и самом Битриксе.
В дальнейшем он обрастал доп функционалом, и команда разработки увеличилась до 10 человек. И уже было разделение на фронт/бэк. Однако кажущимися "лишних" компонентов - node, npm, webpack, vue/react - так и не использовали. Просто бэкендеры писали модули и компоненты, а фронты - верстали css и писали JS/jQuery. Деплой происходил в таком стэке за считанные секунды. Что довольно затруднительно при использовании трендов (встречал компании, где сборка лишь фронтовых компонентов занимала 30 минут).
Ну и как понимаете, найти замену разработчику, который знает немного js и немного php - вообще не сложно. А после разбиения на фронт/бэк (php / js + css) - так вообще плёвое дело. Правда за 6 лет развития проекта, ушел всего один разраб - и то уехал в другую страну.
Еще более сложные продукты - тоже писали, обработки миллионов запросов, терабайтов данных и прочее, обернутое в кубер, сервисмеш, с брокерами очередей, графкуэлями и прочими потребствами. Кстати там использовали на фронте Vue3. И вот с этим были проблемы:
1. Фронт делался непривычно долго, особенно на начальных стадиях.
2. Разработчик ушел, и поняли, что без знаний во vue, не поправить даже мелочей. Хотя с обычным JS таких проблем не бывает - всегда всё очевидно любому человеку, который хоть раз видел код на любом ЯП.
3. Разработчик ушел и найти нового было сложно, потому что кто-то на реакте, кто-то на ангуляре, кто-то на вью, но втором, кто-то еще на чем-то. А потом пришедший вьюшник, сказал что не нравится использованный подход, надо переделывать)
4. Какие-то вещи обновились и сборка перестала собираться. Потратили много времени.
Наверное соглашусь с тем, что сложные с точки зрения фронта очень быстро обновляемые вещи, можно писать на Vue, и развлекаться со всякими вебпаками. Но по факту, таких приложений, где это надо - 1 на миллион. Сложно придумать что-то кроме дашбордов криптобирж например. Там много всяких элементов - курсы, графики, кошелек, ставки и тд. которые должны оперативно обновляться. Тут думаю реактивность себя окупит, и то под вопросом.
В прочих случаях - выглядит будто CSS + JS + наше всё.
Ну я ж тоже образно.
Главное - что это было по силам одному человеку. Сейчас же требования - чтобы сегодня бизнес выкатил хотелку, а через неделю она уже была на проде (ну или две недели если двухнедельный спринт). И при этом прошли ВСЕ виды тестирования, секурити аудита, документация, промежуточные демо...
Раньше приобретение Жигулей было большим событием.
На самом деле объём информации на сайте растёт, его нужно как то структурировать и правильно подать. Раньше достаточно было одной, двух нечётких фоток ботика в магазине, сейчас не только нужны фото в супер HD, но и много сопутствующей информации, дата производства, фамилия шившего китайца, через какие пути доставлен и т.д, и т.п.
Профит в том, что покупатель реже отказывается от покупки в момент доставки, соответственно меньше издержки розничного продавца.
Ну и сам бизнес получает новые возможности. В частности он может формировать отчёты в момент наступления события. Например доставка товара в магазин, водитель сразу фиксирует что и сколько доставлено. Это избавляет от заполнения дополнительных отчётов.
Средний
