Задать вопрос

Есть ли реальный профит от использования актуальных фронтенд-технологий?

Вопрос несколько философский, заключается в - "Зачем мы напрудили столько технологий, и не мешают ли они нам?"

Предыстория:
В 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 по итогу?
Вот от фронтовых фреймворков верстки - профит заметен был (тот же фаундейшн, бутстрап и тд) - действительно ускоряло и упрощало жизнь.
  • Вопрос задан
  • 696 просмотров
Подписаться 1 Простой 12 комментариев
Решения вопроса 3
yarkov
@yarkov
Помог ответ? Отметь решением.
Простите, но кто вас сейчас заставляет использовать всё это? Пишите без сборки на чистом js и будет то же самое что вы описали.
Ответ написан
Mike_Ro
@Mike_Ro
Python, JS, WordPress, SEO, Bots, Adversting
В 2016-м году, делали нечто, что потом начали люди называть SPA - но за счёт аяксов, которые грузят что нужно. При этом сохраняется структура страниц на сервере, и нет и не было проблем с индексацией.

Проблемы с индексацией есть и сейчас, чтобы там не заявляли ПС, а в древние 2016 года они были выражены в несколько раз сильнее. То, что Вы проблемы не замечали - не значит, что их не было.
Вот от фронтовых фреймворков верстки - профит заметен был (тот же фаундейшн, бутстрап и тд) - действительно ускоряло и упрощало жизнь.

Ускоряет жизнь тем, кто не умеет в вёрстку, остальным - замедляет.
1. Стильно, модно, молодёжно. Других не могу придумать. Вроде бы как должно работать быстрее, но практика этого не показывает (или настолько незначительно, что конечному пользователю - пофиг, будет работать аякс или вьюшная реактивность).

На определенном этапе разработки, стоимость поддержки проекта на чистом js начнёт обгонять проект на react/vue. Пользователю будет конечно пофиг, т.к. он не найдёт в ПС Ваш SPA сайт.
Собственно, а зачем это всё нужно, если профит, кажется - нулевой

Для ускорения разработки, а ключевое слово здесь "кажется".

P.S. в некоторых ситуациях действительно быстрее и дешевле написать некоторые функции на чистом js и не тащить весь react стек в проект, но это больше исключение, чем правило.
Ответ написан
@Karington
Сайт пишется для того, чтобы закрывать потребности бизнеса.
Сайт из 2014 года закрывал потребности бизнеса в 2014 году, и не закрывает их в 2024 году.

Вам правильно сказали, что вам никто не мешает сейчас за три дня сделать сайт на технологиях 2014 года, но сможете ли вы конкурировать с сайтом на технологиях 2024 года?

Сердцем, я вас полностью поддерживаю, и считаю что бОльшая часть "современных технологий" -- бесполезная ерунда. Но раз бизнесы платят в десятки раз больше, значит им это выгодно. Склонен им верить, потому что у них эти данные получены:
а. От аналитиков, которые собирают статистику и AB тесты
б. Из бухгалтерской отчётности, в которой растут прибыли год от года, а значит, принимаемые ими решения верны.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
Есть. Просто использовать надо с умом, а не забивать микроскопом гвозди.
Ответ написан
Комментировать
@koder_1
Битрикс программист
Полагаю, среднестатистический корпоративный сайт/интернет-магазин имеет скорее интерфейс с элементами js, нежели интерфейс полностью завязанный на js.
Для большинства задач реактивные фреймворки не нужны.

Если разобрать типовой интернет-магазин.
Слайдеры, анимации, эффекты проще всего делаются плагинами на jquery.
Всплывающие формы обратной связи вполне нормально на jquery.
Фильтры подбора продукции - имело бы смысл делать на реактивных фреймворках, но обычно фильтры уже встроены в саму CMS. Тот же умный фильтр в Битриксе на столько умный (выводит только такие наборы значений, по которым можно найти товары, опирается на встроенный в CMS механизм) что его переделывать дорого неоправданно.

Пока у меня ощущение такое, собирать сайт целиком на реактивных фреймворках профита мало, а отдельные элементы, к примеру, какой-нибудь нетиповой и нестандартный фильтр подбора со своей логикой - вполне хорошо.
Ответ написан
DeoZ
@DeoZ
Веб-разработка и Реклама
Если говорить конкретно про фронтенд, то главные плюсы от использования библиотек и фреймворков:
  • Разделение на компоненты, которые можно переиспользовать, а значит ускорить последующую разработку и доработку, улучшить масштабируемость
  • Лучшая работа с перерендергином компонентов (обновлением частей страницы), когда может обновиться не вся страница, а только её часть. Это даёт лучшую скорость реакции на действия пользователя, что улучшает его впечатление от работы с сайтом. И это особенно критично, если идёт работа с какими-то частями со сложными вычислениями на странице.
  • Плюс-минус схожая архитектура между приложениями, написанными на одном фреймворке. Что упрощает работу команды над проектом и даёт возможность быстрее вкатываться в работу новичкам.
  • Широкий выбор дополнительных подключаемых библиотек, реализующих практически что угодно по вашему запросу на проекте. Если особая кастомизация решения не нужна, то подключается всё мгновенно и у вас на сайте хоть диаграмммы рисуются, хоть таблицы, хоть формочки. Да, раньше для этого использовался, например, тот же jQuery (хотя что уж раньше, они недавно даже новую версию выпустили), но он тяжелее, содержит много ошибок и не соответствует новым стандартам. А стандарты - это не для моды, это безопасность, скорость работы и кроссбраузерность.
  • Это возможность использовать централизованные менеджеры состояний, когда у тебя всё хранится в одном месте, а не где-то там, плюс кэшируется, обрабатывается там же и так далее.
  • Отделение бизнес-логики от UI, что даёт возможность править их независимо, а не переписывать весь модуль, когда модель ответа немного поменялась.
  • Зачастую лучшая поддержка и обновление фреймворков и библиотек, документация, что является не только вопросом удобства, но и безопасности. Устаревшие технологии могут быть очень уязвимы.
  • Если говорим про сборщики, то возможность всё кастомизировать настолько, чтобы не приходилось раскладывать руками по папкам и чтобы вся сборка, которая может быть большой, автоматически чистилась, минимизировалась и делилась на части. А это существенное ускорение загрузки у пользователя.
  • Не говоря уж про совсем "модные" нынче микрофронтенды, когда каждая часть приложения может писаться и поддерживаться независимо друг от друга и, при желании, на любых фреймворках, в том числе и на ванильном JS.

В общем, можно много чего ещё привести, что положительного дало бизнесу развитие фронтенда и переход на фреймворки, модульность, сборщики и автодеплой. Что-то для Вас конкретно будет более существенным, что-то совсем не важным или не понятным. Но главное, что каждая из технологий, каждая часть стека должна выбираться последовательно и мере необходимости бизнесу. Для этого начинать работу над проектом должен высококвалифицированный специалист с пониманием архитектуры и требований к масштабируемости и безопасности.
Вполне возможно, что для визитки хватит простого HTML+JS, для витрины товаров можно использовать Tilda, для простого интернет-магазина или корпоративного портальчика - Bitrix или WordPress. Но часто бывает, что у бизнеса есть или появляются особые требования, аппетит растёт по мере работы сайта, вот тогда выясняется, что необходимы фреймворки, позволяющие гибко реализовать практически любые кастомные решения.
Ответ написан
@Rerurk
Из моего скромно опыта. Скорость разработки, скорость правки
Ответ написан
bingo347
@bingo347
Crazy on performance...
Да используйте что хотите, кто Вам запретит то?
Только не удивляйтесь, если однажды наступит бас-фактор и Ваш разработчик за 50 тыс уволится, уйдёт на пенсию или ещё чего хуже... А нового найти на это легаси будет проблема, мало кто будет готов, а те кто готов запросто могут запросить з/п 500к+.
Я бы может согласился, но просил бы лям... Хотя скорее всего нет, нервы дороже бабла...
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега Веб-разработка
software engineer
Вы же сами ответили на вопрос.
Вы писали "сайтец".
Если для вашей задачи достаточно взять одного разработчика, который напишет сайтец - пишите как вам угодно.

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

Если же вы пишете сложный продукт, для которого нужно человек 5-10, им нужно согласовывать и стандарты и стек технологий, и чтобы упростить - не пишут велосипеды, а берут какой-то готовый движок.
А если вы сервер хостите где-то в облаке, следует обратить внимание, будет ли этот движок обновляться, или через 5 лет облако скажет "мы едем на новую версию ОС, где ваш движок не работает, переезжайте на другую версию или другой движок"

Совсем другой вопрос что дейсвительно существует море "усложнятелей", но об этом полно и анекдотов и реальных историй. Так что в данном случае нужен архитектор или грамотный менеджер, который понимает и необходимости бизнеса, чтобы работать и адаптировать ТЗ, и понимает риски со стороны технологий, чтобы выбирать или одобрять на чем будет это все написано, где хоститься и так далее.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы